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

[Ian Romanick]

On 11/22/2013 03:08 PM, Paul Berry 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.

Principle of least surprise suggests that we should do whatever we
already do for mismatches in other dimensions.  I seem to recall there
being a fairly recent Khronos bug about that very issue.  I'll try to
track down the resoultion.

> 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.

That is surprising.  If you have a test case, maybe Ken could try it on AMD.

> 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.

Looking at the spec, I think the change was intentional, but I don't
recall why.  I'd have to do some archaeology to find the reason.  If we
poke at some other implementations and they all generate
FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB, then we should try to get the
spec changed.  If some implementations don't generate the error, then
the next step is not as clear to me.

As for what to do now (i.e., for 10.0), I think we're safe generating
the error.  Since another major implementation incorrectly generates the
erorr, the probably that any application depends on mis-matched layer
counts is very low.  This means that our spec deviation is unlikely to
break anything or cause developers to create more buggy apps (since this
is more strict rather than more lax).

> Thanks,
> 
> Paul
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev