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

[Paul Berry]

On 25 November 2013 11:08, Ian Romanick <idr at freedesktop.org> wrote:

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

Ok, I just tried it on AMD, and what I found was:

- Unlike Nvidia, AMD allows a framebuffer to have different layer counts in
different attachments.

- Calling glClear() on such a framebuffer causes all layers of all
attachments to be cleared, even those layers which aren't present in all
attachments.


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

Here's my current plan:

- Change fbo_incomplete() to allow different layer counts in different
attachments.

- Replace gl_framebuffer::NumLayers with MinNumLayers and MaxNumLayers.

- In meta clears, loop from 0 to MaxNumbLayers-1, so that all layers of all
attachments get cleared, even if not all attachments have the same layer
count.*

*Note: strictly speaking, this makes Meta depend on some undefined
behaviour--it depends on the hardware handling writes to undefined layers
independently on different attachments.  But I believe that's what i965
does, and since i965 is the only user of Meta that supports layered
attachments, we should be fine.

Does that seem good to you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131202/a811c075/attachment.html>