I have just been running some tests to see the difference in rendering speed between a 2D texture and 3D texture mapped approach for volumetric rendering.
What I did is took a 256x256x256 volume (approx 40% full) and allowed it to rotate around the X axis 360 degrees at 5 degrees intervals. I then kept track of the rendering time for each frame.
Basically I wanted to see the effect of orientation on rendering speed for each approach.
What I found is that the 2D texture approach seemed to generate pretty constant framerates, whilst with the 3D approach the framerate was very dependent on the orientation of the volume. IE: if alot of the volume was present in the current view framerates fell.
This seems percular, and I cant understand why…
Should I be seing this? or is something wrong with my rendering code
If this is what should happen why is it pretty constant for one and not for the other?
As memory access does not come for free (in fact, it’s very expensive) and memory access patterns for a 3D texture can be pretty bad, this effect is to be expected. It’s always bad to access memory in a non-linear fashion. As 2D textures are quite small compared to 3D textures, texture caches inside the GPU are used much more effectively for 2D textures than for 3D textures.
There are ways to get around those view-dependent frame rates. In fact, NVIDIA does have pretty view-independent performance, ATI does not.
UT666, some people say that ATI’s 3D-textures do have an orientation dependent performance. As Klaus says, this can be explained by varying memory access patterns. Rasterization basically goes line by line through your triangles. Now imagine you render a volume that produces linear access patterns in each slice line by line. If you now rotate your triangle by 180 degrees the line-by-line rasterization produces 3d-texture-lookups that go backwards through the graphics memory which is not optimal for the memory controller of your graphics processor.
In general, memory access producing a cache hit has best performance. Good caching can only be found if your program has spatial and/or temporal access-locality, that means that a program often accesses neighboring addresses after each other or accesses the same address twice in a short period of time.
For graphics hardware, this topic is not really easy. In general, 2D-textures use less memory, so it is more likely that subsequent texture lookups can be a cache hit. The best way to improve caching behaviour of an application would be to know the size of the cache, so that your working set (size of your texture) can be chosen in order to be smaller than the cache. This allows to produce a maximum amount of cache hits. But unfortunately, nothing is known about the size of caches for any graphics processor. And more important, lots of cache hits will only occur during texturing if you use the same texel for lots of pixels – which is only the case if you have a large magnification.
In my exerience, the theory that 2D-textures are fast due to cache hits or linear access patterns is only a partial explanation to better 2D-texture speed. 2D-lookups are cheaper then 3D-lookups, needless to say, since you need trilinear instead of bilinear interpolation. In addition, for example, you could easily find out the cache size by some benchmarks and then use 3D-texture-blocks that could fit completely in the cache. But you’ll probably see that 2D-textures will win nevertheless. 2D-textures are the most optimized part of every graphics driver and graphics processor. In my opinion, that’s the main reason for their speed advantage.