From the API point of view the number of samples per pixel is fixed. The hardware may use some kind of sample compression though. That information would have to be sampled as well, and how do you present it to the shader?
That's my point: if you're processing every sample per-pixel even if they are all the same, then you're doing just as much work as supersampling, although the hardware can potentially save BW where all of the samples are equal.
Presumably this is in some kind of "post-processing" shader, after the heavy lifting of the primary pixel-shading has already been performed.
Not if you're doing deferred shading, which is arguably one of the most important uses of this functionality!
Again, even that can be pretty expensive if you have to read *all* of the G-buffer elements and compare them. Really there should be a low-cost way to check if all samples are equal, correct? I guess maybe not, but it seems like there should be a cheaper way... Otherwise it looks like I'm sticking to my SSAA guns for deferred shading
If the hardware is capable of using a compressed MSAA surface as a texture then the TMU would need access to compression flags, obviously. So returning a boolean flag indicating whether the texel position is in a fully compressed tile should be possible in theory. Such a flag would be conservative of course, i.e. if it's false the samples could still be identical.
But the MSAA render target(s) has to be "copied" to make the "MSAA texture" doesn't it? So wouldn't the on-chip compression flags be lost? The surface can't be bound for reading and writing at the same time, so as soon as a new surface is bound for writing these flags are kaput...
Not if you do jittered super-sampling by offsetting the projection matrix (Humus had a demo that did this - we also discussed it a fair bit in a recent thread).
True, but in exchange you gain shader AA, potentially some temporal AA (also discussed in the recent thread), and better texture filtering.
A little misunderstanding, I'm perfectly aware that such a thing is possible in theory (reading back a compression flag), but I took for granted is not with current APIs/HW since I could not find any reference to it.
I suppose I should have called it a "swap" in terms of the render target (or MRTs) - when new render targets are defined the existing ones "lose focus", some kind of pointer swapping takes place and the compression flags are reset for the new render targets.
Pardon me if this is a stupid question (I don't really understand how the hardware works), but might the compression flags be associated with the multisampled depth buffer rather than there just existing one set globally? It seems to me that if you can get access to the "pre-resolved" fragments, they're not going to decompress the MSAA buffers when one goes to read from them.
My understanding is that these compression flags are held in on-die memory - in a similar way to hierarchical-Z.
The problem is the granularity of the flags, i.e. how big are the tiles if the hardware uses a tiled compression scheme?
The fact that hardware uses framebuffer compression should indicate that there is enough to be gained from it, even in complex scenes. Of course for a simple downsample filter in a shader you don't save much, but reading the flag plus an if clause wouldn't cost much either.
