PDA

View Full Version : 3D texture-size, framerate drop



Hrymr
05-16-2003, 03:00 AM
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 128*128*128 to 256*256*256 (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 (256*256*256=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).]

JustHanging
05-16-2003, 05:02 AM
Hi,

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.

-Ilkka

Hrymr
05-16-2003, 05:16 AM
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).]

Ysaneya
05-16-2003, 05:39 AM
What about filtering ? Try NEAREST, NEAREST to see if texture sampling is the bottleneck.

Y.

Hrymr
05-16-2003, 05:51 AM
Good thought, but I've tried that before, it only lowers the quality of the volume, no speed increase.

Tom Nuydens
05-16-2003, 05:55 AM
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.

-- Tom

Hrymr
05-16-2003, 06:04 AM
Ok, I will. Thanks for quick replies!

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! http://www.opengl.org/discussion_boards/ubb/smile.gif

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).]

V-man
05-16-2003, 06:24 AM
The texture cache is not very different from any other processor's cache.

It's integrated into the GPU's silicon (I haven't seen any cards that have an external cache).

It's definitly faster than reading from slower VRAM (DDR or whatever)

Mipmaping reduces misses (think of a small array and a loop in your program that processes the array, and you use tricks such as cache warmup).

Does that give you a better idea?

Hrymr
05-16-2003, 06:31 AM
jup, it does. Thanks V-man!

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).]

*Aaron*
05-16-2003, 06:46 AM
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.

Hrymr
05-16-2003, 07:02 AM
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.

Thanks!

KlausE
05-16-2003, 08:56 AM
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.

Both should fit into 128 MB.