MSAA: Does each of the n samples of a fragment store the pixel color value?

Hello,

I have read many pages on the web regarding how MSAA works in detail, for example:
https://www.opengl.org/registry/specs/ARB/multisample.txt

I understood that the pixel shader is only executed once per pixel and
that the output (the color value) is stored in each of the subsamples
which pass the coverage/occlusion tests.

Later during the resolve these color values are mixed together and
result in the final pixel color. This is pretty good described in the
3rd of the mentioned pages above.

But after reading the first page above I am a bit confused because it first says…

Each pixel fragment thus consists of integer x and y grid coordinates,
[b]a color[/b], SAMPLES_ARB depth values, texture coordinates, and a
coverage value with a maximum of SAMPLES_ARB bits.

…which sounds as if there are only multiple depths values per fragment
(i.e. SAMPLES_ARB depth values) but only one color value.

Then, on the same page a bit further down, it says…

After all operations have been completed on the multisample buffer,
the color sample values are combined to produce a single color
value, and that value is written into each color buffer that is
currently enabled, based on the DrawBuffers mode.

…which is basically what I understood, that there are indeed multiple color values per fragment,
namely one for each subsample. This also makes sense as it is possible to read back each individual
sample color value via texelFetch(…,sample).

So what is now true, are there multiple color values per fragment or not? I think there is a
mistake in the first quote, no? IMHO it should be corrected in this way:

Each pixel fragment thus consists of integer x and y grid coordinates,
[b]SAMPLES_ARB color values[/b], SAMPLES_ARB depth values, texture coordinates, and a
coverage value with a maximum of SAMPLES_ARB bits.

Or did I completely misunderstood something?

Clarification is really appreciated!

[QUOTE=RealtimeSlave;1285068]But after reading the first page above I am a bit confused because it first says…

…which sounds as if there are only multiple depths values per fragment
(i.e. SAMPLES_ARB depth values) but only one color value.[/QUOTE]

Hi RealtimeSlave. Based on what you’ve said, it sounds like you understand MSAA, and I think your confusion is just a terminology problem.

When you see “fragment”, think “pixel-sized piece of a primitive forging its way down the graphics pipeline”.

This is different than “pixel sample” (or “screen sample”, “window sample”, “framebuffer sample”, …whatever) which denotes buffer values(s) in the target framebuffer.

Ignoring optimizations such as early Z/stencil/etc., here’s my conceptual understanding of how these terms fit into the pipeline:

Rasterization -> Fragments -> Fragment shader -> Framebuffer ops (blending/depth test/stencil/etc.) -> Pixel samples

I’ll see if I can find a more official diagram lying around.

In short, fragments are tiny chunks of primitives hoping to become (or influence) pixel samples in the framebuffer someday. Some get killed (sigh), but some actually make it to the framebuffer.

So what is now true, are there multiple color values per fragment or not?

There’s a single color value in the incoming fragment, but there are multiple color values (one per sample) in the target screen pixel.

And of course, we’re talking specifically about MSAA here, not CSAA nor SSAA (e.g. ARB_sample_shading).

From here:

Many thanks Dark Photon for the clarification!

What you say makes totally sense, I think the distinction between incoming fragment and final storage was really the missing part in my understanding.

Then it makes sense that it has “SAMPLES_ARB depth values” but only one color value because it needs these depth values later when writing into the covered subsamples in the final buffer but it only needs one color value for them.

Right. One frag shader execution per pixel, so one color (per render target, with MRT), but N depth+stencil tests.