Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: S3TC texture compression performance

  1. #1
    Junior Member Newbie
    Join Date
    Nov 2010
    Posts
    7

    S3TC texture compression performance

    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

  2. #2
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,574

    Re: S3TC texture compression performance

    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.

  3. #3
    Senior Member Regular Contributor
    Join Date
    Apr 2007
    Posts
    268

    Re: S3TC texture compression performance

    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.

  4. #4
    Senior Member Regular Contributor
    Join Date
    Apr 2007
    Posts
    268

    Re: S3TC texture compression performance

    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.

  5. #5
    Senior Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    281

    Re: S3TC texture compression performance

    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)
    @+
    Yannoo

  6. #6
    Senior Member OpenGL Lord
    Join Date
    Mar 2015
    Posts
    6,671

    Re: S3TC texture compression performance

    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.

  7. #7
    Senior Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    281

    Re: S3TC texture compression performance

    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 ...).
    @+
    Yannoo

  8. #8
    Senior Member OpenGL Lord
    Join Date
    Mar 2015
    Posts
    6,671

    Re: S3TC texture compression performance

    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.

  9. #9
    Senior Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    281

    Re: S3TC texture compression performance

    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)
    @+
    Yannoo

  10. #10
    Senior Member OpenGL Lord
    Join Date
    Mar 2015
    Posts
    6,671

    Re: S3TC texture compression performance

    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.

Page 1 of 2 12 LastLast

Similar Threads

  1. about s3tc and texture compression
    By dvm in forum OpenGL: Advanced Coding
    Replies: 7
    Last Post: 09-05-2006, 11:08 PM
  2. S3TC / DXTC texture compression
    By surgptr in forum OpenGL: Advanced Coding
    Replies: 2
    Last Post: 11-29-2004, 05:57 PM
  3. S3TC or FXT1 texture compression ?
    By deadalive in forum OpenGL: Basic Coding
    Replies: 4
    Last Post: 06-27-2003, 08:54 AM
  4. Replies: 6
    Last Post: 12-15-2001, 03:10 AM
  5. s3tc compression
    By 4j4x in forum OpenGL: Advanced Coding
    Replies: 1
    Last Post: 01-15-2001, 03:09 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean