   Is tex2D extremely slow?
  Hi,I'm currently working on a terrain renderer using opacity maps, lightmaps and 4 ground textures.The shader is a follows:float4 color = 0;float4 lightmapcolor = tex2D(LightmapSampler, TexCoordsAlphamap);float4 weights = tex2D(AlphaMapSampler, TexCoordsAlphamap);weights /= 255;weights /= (weights.r + weights.g + weights.b + weights.a);if(weights.r > 0)   color += tex2D(SnowTextureSampler, TexCoordsTexture) * weights.r;if(weights.g > 0)color += tex2D(RockTextureSampler, TexCoordsTexture) * weights.g;if(weights.b > 0)color += tex2D(GrassTextureSampler, TexCoordsTexture) * weights.b;if(weights.a > 0)color += tex2D(SandTextureSampler, TexCoordsTexture) * weights.a;color *= lightmapcolor;color *= saturate(dot(lightPos, Normal));return color;These are the results from some tests I made:one tex2D instruction:    380fps (simple texture)two tex2D instructions:   360fps (texture + lightmap)six tex2D instructions:   170fps (opacity map + lightmap + ground textures)I already use if(weight.(r|g|b|a) > 0) to do the texture lookup only when there is a need for, but it doesn't seem to make any difference at all.I have a GF6800GT and the newest drivers, if that matters.regards   
  Texture lookups aren't slow. Branches are. What happens if you get rid of the if statements?   ;  Texture (memory) access is slow for "bad" access patterns, in your case it should be fine though, unless you have very large textures and forgot to enable mimaps...   ;  with    if-statements: 170fpswithout if-statements: 190fpsOkay, helps a bit indeed, but perfomance still drastically decreases with each tex2D call.Right now I'm using 128x128 jpg files for testing purposes, but I plan on using 512x512 textures later. Should I save them as DXT files with mipmaps enabled?/edit: wow, I saved those JPG files as DXT1 (4bpp, no alpha) with mimaps and frames increased from 190 to 350! I couldn't imagine using DDS would make such a huge difference[Edited by - FoxHunter2 on September 3, 2007 6:39:25 AM];  On a shader that reads 6 textures and doesn't do much else you're likely to be texture read bandwidth limited. Compression and mipmaps will both help reduce that bandwidth significantly. It'll also mean that the texture cache is more effective.For a bit more of a speedup drop the "weights /= 255" statement. The results will be identical with or without it and texture read results are also already in the 0-1 range anyway.You could also preprocess your texture on the CPU to avoid the need for the "weights /= (weights.r + weights.g + weights.b + weights.a)", but it will introduce some minor differences due to the texture filtering.   ;  Thanks. I planned on preprocessing the texture at load/compile time for use with render targets (water reflections etc), but performance is pretty good now. I just thought the GF6 would be able to handle 6 texture lookups more easily.   ;Quote:Original post by FoxHunter2one tex2D instruction:    380fps (simple texture)two tex2D instructions:   360fps (texture + lightmap)six tex2D instructions:   170fps (opacity map + lightmap + ground textures)Probably you know, but perhaps other thread readers don't - You're measuring the wrong thing! You're not measuring the time it takes to process your data, you're measuring the velocity at which it is being done. You're interested in how long it takes for your Draw() call to finish, so I suggest you measure exactly that. A frame consists of so much more than that single call.Now, look at it this way:one tex2D: 1/380fps ~ 2.63 msecs/frametwo tex2D: 1/360fps ~ 2.78 msecs/framesix tex2D: 1/170fps ~ 5.89 msecs/frameYou can see that tripling the number of texture reads only doubled the time to perform the processing. That's sub-linear increase, doesn't sound that bad.Quote:... frames increased from 190 to 350! I couldn't imagine using DDS would make such a huge difference1/190fps ~ 5.26 msecs/frame1/350fps ~ 2.86 msecs/frameThat's a good sign that your performance was texture bandwidth-limited. This doesn't mean that texture performance is bad on your card. It just means that it was the most limiting process in your application. If you add some calculations (bump mapping perhaps?) into your shader, you might notice the that you'll be back in something like 5msecs/frame; only that the calculations will be the bottleneck then. Again it would be tempting to draw the conclusion that "this GPU is slow at doing arithmetic" and wonder why everything is so slow. Instead, you might notice that you could put all your textures back into uncompressed versions and that you'll still be in that 5msecs/frame. Performance with GPUs is about finding a balance.A program that does only a single texture lookup (or none at all) and only projects simple geometry might very well run at 500-1000fps. Comparing anything against that will make the performance of any GPU look bad.   ;  Thanks, that was a very helpful post. I'm just wondering what will happen when I add other "frame-droppers" like render targets, normal/parallax-mapping, vegetation etc, I guess my framerate will then drop relatively fast below the rate of high quality commercial productions which have way more detail/objects etc.I guess you have to know lots of little tricks to squeeze the most performance out of a GPU.   