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.

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
[li]compute which blocks the pixels of the triangle hits[/li][li]for each such block, decompress and render pixels to block[/li][li]for each of those blocks then recompress[/li][/ul]

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…

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

This is addressed in issue #10 of 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…