<div dir="ltr"><div>The ARB_geometry_shader4 spec says, in the list of conditions necessary for framebuffer completeness:<br><br>      * If any framebuffer attachment is layered, all attachments must have<br>        the same layer count.  For three-dimensional textures, the layer count<br>

        is the depth of the attached volume.  For cube map textures, the layer<br>        count is always six.  For one- and two-dimensional array textures, the<br>        layer count is simply the number of layers in the array texture.<br>

        { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB }<br><br><br></div><div>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)):<br>
<br>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.<br>
<br></div><div>(note: presumably where the spec says "greater", "greater than equal" is actually intended).<br></div><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br></div><div>However, there are two mitigating factors:<br><br></div><div>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.<br>
<br></div><div>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.<br>
<br><br>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.<br><br>Thanks,<br>
<br></div><div>Paul<br></div></div>