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: MSAA: Does each of the n samples of a fragment store the pixel color value?

  1. #1
    Intern Contributor
    Join Date
    Nov 2011
    Posts
    61

    Question 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/spec...ultisample.txt
    https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx
    https://mynameismjp.wordpress.com/20...msaa-overview/

    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,
    a color, 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,
    SAMPLES_ARB color values, 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!
    Last edited by RealtimeSlave; 12-17-2016 at 12:17 PM.
    ++i--;

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,150
    Quote Originally Posted by RealtimeSlave View Post
    But after reading the first page above I am a bit confused because it first says...
    Quote Originally Posted by ARB_multisample
    Each pixel fragment thus consists of integer x and y grid coordinates,
    a color, 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.
    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).
    Last edited by Dark Photon; 12-17-2016 at 01:19 PM.

  3. #3
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,150
    Quote Originally Posted by Dark Photon View Post
    I'll see if I can find a more official diagram lying around.
    From here:

    * OpenGL 4.4 Pipeline Map

  4. #4
    Intern Contributor
    Join Date
    Nov 2011
    Posts
    61
    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.
    ++i--;

  5. #5
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,150
    Right. One frag shader execution per pixel, so one color (per render target, with MRT), but N depth+stencil tests.

Tags for this Thread

Posting Permissions

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