S3TC texture compression performance

[endlosschleife]

Hi,

I understand that there are additional factors that play into this, but is it expected that a shader based volume rendering algorithm performs faster on compressed textures than on uncompressed textures?

I played around with a shader based volume rendering algorithm from VTK and changed it to compress the 3d texture for the volume during the upload to the graphics board. I wanted to see what the tradeoff is between the additional data that I can hold in the texture memory and the performance drop during the rendering. I was surprised to find out that a maximum intensity projection of my sample data set (512 x 512 x 700 voxels) was about 20% faster with compressed textures. My graphics card is a NVidia G210M.

I assumed that the shader that does the actual volume ray casting does not care about whether a texture is compressed or not and that the only difference is that when the tracer asks for the value of the voxel that in one case the result comes directly from the texture buffer and in the other
case it decompresses the value of the requested pixel on the fly (I understand that the algorithm is optimized for random access and on-the-fly decompression speed). Still I assumed at least some performance drop.

Now where I would understand the performance increase would be if the textures (compressed or uncompressed) do internally get copied around while performing ray casting and that the reduced bandwidth requirements of the compressed textures make the difference, but I don't see where - and why -
this should happen.

Or maybe assuming that the texture sampling of the ray casting shader is what takes most of the time, the GPU caches some data (neighboring blocks of pixels?) during decompression to on-chip memory and texture memory is accessed less often?

Any ideas?

Thanks,

Mark

[ZbuffeR]

Indeed S3TC is heavily tuned to be extremely hardware efficient.
Graphic card most probably have special circuitry so the actual decompression does not take more time than uncompressed access. However, the data bandwidth is 4 times smaller with compressed textures, and that makes a difference for texture-heavy shading.

[overlay]

I don't have my "real-time rendering, 3rd edition" book by me right now but I merely remember the chapter about hardware architecture.

I think each texture unit has a really fast cache where it can store a block of the texture. It allows to amortize the cost of reading neighbor texels from the VRAM. This is true for compressed and uncompressed textures.

In addition, by using compressed textures, the loading from VRAM to texture cache is even faster.

Again, it is just on top of my head right now. You'd better check by yourself in the book.

[overlay]

Regarding the use of compressed texture in volume rendering, be aware that S3TC is a lossy compression so you may degrade rendering quality.

It's probably more important to keep accuracy over speed when you dealing with scientific data.

However, you could find lossy compression a good enough LOD (level-of-detail) for quick interaction and switch back to uncompressed texture for a more accurate rendering when you stop interacting.

[The Little Body]

DXT can perhaps to be enhanced for to handle the red, black and blue channels into separates planes/partitions for to be very less lossy (cf. two bits indexing for each R, G and B planes vs only two bits indexing for a RGB triple on only one RGB plane at the actual DXT compression) ?

For example, with a 4:2:2 partition, the intensity of each component (cf. green:blue:red) can to be interpoled by 2 bits each => this give only 12 bits for 4 pixels with a very big gain in quality ...
(but ok, on other side the compression ratio isn't as good as the first DXT version)

[Alfonse Reinheart]

Somehow, I don't think that's going to solve his performance problem. Particularly since this is not supported in hardware and would therefore not be faster.

[The Little Body]

A lot of thing are changed since the first 3dfx card ...
(the fillrate is very more impressive now ...)

We have now for example vertex/fragment[/geometry] shaders that aren't as old as this but already supported in hardware

And like say Zbuffer and Overlay, the DXT compression have very less memory to handle, so less memory access to do (and very less VESA/AGP/PCI/PCI-E tranferts to make for to access external memory ...).

[Alfonse Reinheart]

We have now for example vertex/fragment[/geometry] shaders that aren't as old as this but already supported in hardware

If a simple texture fetch is too slow for this person's needs, manual texture decompression is not going to be faster.

[The Little Body]

Heu ... and if you can have more than only one texel at each fetch ???

A cuboïd of 8x "3D texels" with only one texture fetch for example ...

Note that a RGBA texel can already to be easily handled as 4 texels with only intensity
(cf. R/G/B/A 32 bits => 4x 8 bits intensities)

[Alfonse Reinheart]

Heu ... and if you can have more than only one texel at each fetch ???

You haven't proposed a way for that to happen.

Note that a RGBA texel can already to be easily handled as 4 texels with only intensity

And how does this deal with the problem at hand? He doesn't need 4 intensities; he needs RGB(A) color data.