On 25 November 2013 11:08, Ian Romanick <i...@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?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
