I’m currently working on a master on Volume-visualization and mixing medical volumes. I use Direct Volume Rendring with a high number of flat, textured polygons (256-390 polygons), to construct the volume. When I switch from 3Dtextures of size 128128128 to 256256256 (eight times the size), I experience large drops in framerate. The Polygons keep the SAME SIZE even though the texture size changes, so there is not a larger amount of fragments to work on in the framebuffer (therefore the reason can not be Pixel-fillrate).
I am using a geforce4 (ti4600 series) card with 128 Mb, so I should have enough memory (256256256=32Mb) to avoid RAM swapping with the main memory.
I experience this problem with Multipassing and Multitexturing (with two volumes), but when I Use only one volume (I still use 256 textured polygons), the difference is not that great…
Is there anybody that could help explaining me what part of the texturepipeline is actually causing this drop?
Thank you.
[This message has been edited by Hrymr (edited 05-16-2003).]
[This message has been edited by Hrymr (edited 05-16-2003).]
[This message has been edited by Hrymr (edited 05-16-2003).]
I’m no expert on 3d hardware, but your problem might be explained by increased number of cache misses in the texture cache, especially if the size of a texel becomes smaller then a pixel. If this is the case, mipmapping might help, but with those amounts of data, I’m not sure.
Thanks, that might have an influence, but I guess it wouldn’t cause a worst case scenario of 1/8 till 1/10 of the speed.
Ok, let me simplify my question:
-What specific part of the whole graphics or texture pipeline is causing a drop in framerate when you increase the size of the texture, but NOT the size of the polygon(You would still have to texture or interpolate just as much polygon surface) presuming you have enough texture memory?
[This message has been edited by Hrymr (edited 05-16-2003).]
[This message has been edited by Hrymr (edited 05-16-2003).]
Originally posted by Hrymr: -What specific part of the whole graphics or texture pipeline is causing a drop in framerate when you increase the size of the texture, but NOT the size of the polygon(You would still have to texture or interpolate just as much polygon surface) presuming you have enough texture memory?
What JustHanging said. What filtering mode are you using now? If you’re not mipmapping, try that before anything else.
What is the texture cache that JustHanging is refering to? Is it the graphics memory, specialiced texture memory…? What is the difference between texture memory and texture cache?
I’m not trying to be nosy here, just need to see if it is something I didn’t quite get!
I’m using Linear filters.
[This message has been edited by Hrymr (edited 05-16-2003).]
[This message has been edited by Hrymr (edited 05-16-2003).]
It is just that I didn’t know standard graphic accelerator cards like the geforce4 had a specialised texture cache, I thought they only had shared memory and cache for all operations. Not that it matters, it just confused me.
I know workstation cards like 3Dlabs’ Wildcat have it though.
[This message has been edited by Hrymr (edited 05-16-2003).]
Are you sure of the internal format of your textures? You mentioned multitexturing, so I assume you’re loading more than one of these 3d textures at once. If you are loading 2 256x256x256 textures and they’re stored internally in 32-bit RGBA format, that’s exactly 128 Mb right there, which leaves no room for the framebuffer, etc. Also, remember that turning on AA takes up more memory too.
You might be right Aaron, maybe I need another math course… I have to check this out. I started of with LUMINANCE_ALPHA textures and changed to RGBA later…hm… maybe all of this is due to my reklesnes. Well, one of the textures need to stay in RGBA format, so I’ll try to change back to LUMINANCE_ALPHA with the other.
If both texture do not fit into the local graphics memory, the AGP bandwidth (4x == 1GB/sec, 8x==2GB/sec) becomes the bottleneck, as the 3D textures are swapped in and out for each frame.
You probably want to use a INDEXED or LUMINANCE texture together with a lookup table (paletted or dependent texture) for the first volume. So the first volume will only consume 1 byte/voxel, 16MB for 256^3.
The second volume is probably a gradient volume, so you will have to use a RGBA texture, 4 byte/voxel, 64 MB for 256^3.
