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

[Paul Berry]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131122/50b47c73/attachment.html>