Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 5 of 5

Thread: Rendering into an image of a compressed texture

Hybrid View

  1. #1
    Newbie Newbie
    Join Date
    Sep 2013
    Posts
    2

    Rendering into an image of a compressed texture

    Currently transcoding and dynamic texture compression looks like this (assuming compression in fragment shader):
    -you should create storage stg1 for compressed texture
    -you should create same-size storage stg2 with some uncompressed format that compatible with stg1 for copying (table 18.4 in glspec44)
    -your fragment shader is responsible for assembling correct compressed blocks and will output them into stg2
    -you should copy data from stg2 to stg1
    After that you can read from stg1 and enjoy hw decompression.

    But for fast algorithms (like in article "Real-Time DXT Compression" by J.M.P. van Waveren) compressing time is comparable with copying time or could be even less. So it would be awesome for some apps to eliminate that unnecessary copying step.

    One way to achieve this is to allow creating renderable views for compressed textures. For example RGBA16UI view for COMPRESSED_RGB_S3TC_DXT1_EXT texture. It would allow us this path:
    -creating compressed stg1
    -creating view vw1 with uncompressed renderable format
    -bind vw1 to framebuffer and run our shader
    Now read from stg1 and be happy.

    Of course there is some issues like different resolution for stg1 and vw1. But I don't see any insoluble problems.

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    591
    Lets take for granted that compression is as fast as a copy (or faster since it writes less). However, there is an a quite big elephant in the room: most, if not all, of the compression schemes employed are block compression schemes. So in order to render to a compressed image directly, what happens is as follows when a triangle gets drawn
    • compute which blocks the pixels of the triangle hits
    • for each such block, decompress and render pixels to block
    • for each of those blocks then recompress


    one can get some optimizing naturally in waiting to recompress the block until later, but it will get quite icky. Overall, I strongly suspect that the noise of recompressing will get quite expensive.

    However, for a tiled based renderer the idea of rendering to a compressed texture makes perfect sense since the tiles could be on block boundaries and the copy out to the renderbuffer would then do the compression, possibly saving bandwidth even.

    But for immediate based renderers, I think this won't work out so well..

  3. #3
    Newbie Newbie
    Join Date
    Sep 2013
    Posts
    2
    The topic title is a little bit ambiguous. The better title would be "Writing compressed blocks directly into an compressed image". Normal rendering into compressed surface is a big problem, but it is not a case for my suggestion. When the fragment shader has all necessary information to produce a compressed block we can save some time by throwing away copy step. Such a cases:
    -transcoding textures on the fly (remember Id tech 5 virtual textures)
    -compressing dynamic and procedural textures

  4. #4
    Junior Member Regular Contributor
    Join Date
    Dec 2009
    Posts
    211
    This is addressed in issue #10 of http://www.opengl.org/registry/specs...xture_view.txt. You have to be careful because a compressed texture and a matching integer texture will have different resolution and consequently different mipmap chains.

  5. #5
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by mbentrup View Post
    This is addressed in issue #10 of http://www.opengl.org/registry/specs...xture_view.txt. You have to be careful because a compressed texture and a matching integer texture will have different resolution and consequently different mipmap chains.
    No, it is not. ARB_texture_view does not allow you to "cast" an uncompressed texture to a compressed texture, only ARB_copy_image does allow it implicitly by allowing to copy between certain compressed and uncompressed format combinations..
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •