[Mesa-dev] Spec interpretation question: layered framebuffers with mismatched layer counts

[Marek Olšák]

The number of layers can be specified for each framebuffer attachment
independently in Gallium, Direct3D, and also our hardware. OpenGL
seems to be the only weirdo here. ;) I think our hardware handles
writes to non-existent layers independently of other attachments. It
either clamps the layer index or throws the fragments going to
non-existent layers away.

I would silently allow mismatched layer counts and pass them to the
hardware. It must be able to deal with it in its own way, otherwise it
wouldn't support it in the first place.

Marek

On Sat, Nov 23, 2013 at 12:08 AM, Paul Berry <stereotype441 at gmail.com> wrote:
> The ARB_geometry_shader4 spec says, in the list of conditions necessary for
> framebuffer completeness:
>
>       * If any framebuffer attachment is layered, all attachments must have
>         the same layer count.  For three-dimensional textures, the layer
> count
>         is the depth of the attached volume.  For cube map textures, the
> layer
>         count is always six.  For one- and two-dimensional array textures,
> the
>         layer count is simply the number of layers in the array texture.
>         { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB }
>
>
> When geometry shaders were adopted into desktop GL, this condition was
> dropped.  The constant FRAMEBUFFER_INCOMPLETE_LAYER_COUNT doesn't appear at
> all in the desktop GL spec.  Instead, GL 3.2 says (in section 4.4.7 (Layered
> Framebuffers)):
>
> When fragments are written to a layered framebuffer, the fragment’s layer
> number selects an image from the array of images at each attachment point to
> use for the stencil test (see section 4.1.5), depth buffer test (see section
> 4.1.6), and for blending and color buffer writes (see section 4.1.8). If the
> fragment’s layer number is negative, or greater than the minimum number of
> layers of any attachment, the effects of the fragment on the framebuffer
> contents are undefined.
>
> (note: presumably where the spec says "greater", "greater than equal" is
> actually intended).
>
> In other words, a framebuffer is allowed to have layers with mismatched
> layer counts, but if so then the client may only reliably render to layer
> numbers that are present in all attachments.
>
> Mesa currently implements the rule in ARB_geometry_shader4.  Technically,
> this is a bug, since Mesa is trying to implement geometry shaders as
> specified in GL 3.2, not as specified in ARB_geometry_shader4.
>
> However, there are two mitigating factors:
>
> 1. If we follow the GL 3.2 spec, then it's not clear what should happen if
> the client calls glClear() on a framebuffer with mismatched layer counts.
> For example, if I have a color attachment with 4 layers and a color
> attachment with 2 layers, should all 4 layers of the color attachment with 4
> layers be cleared, or just the first 2?  Or is it undefined?  If we're
> required to clear all 4 layers, that's going to make the Meta implementation
> of glClear() a lot more clumsy.
>
> 2. The Nvidia proprietary drivers for Linux (version 313.18) follows the
> ARB_geometry_shader4 rule (returning FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB
> from glCheckFramebufferStatus()), even when an OpenGL 3.2+ context is used.
>
>
> Currently, I'm inclined to leave Mesa as is, and file a spec bug with
> Khronos encouraging them to adopt the ARB_geometry_shader4 text into OpenGL.
> I'm curious to hear other people's opinions.
>
> Thanks,
>
> Paul
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>