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

[Roland Scheidegger]

It is however illegal in d3d10 to have multiple render targets with
different dimensions (including array size):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb205131%28v=vs.85%29.aspx
I don't know what happens if you try to bind such rendertargets.
FWIW when I implemented layered rendering in llvmpipe, I simply clamped
rendering to the minimum max layer of all attachments. My reading of the
GL spec was that just about anything is allowed to happen if you write
to such a layer, so clamping to the minimum max layer (and thus write to
the "wrong" layer even for adjustments which do have that layer) looked
alright to me.
It would be quite unpractical if that weren't allowed (well other
options such as dropping rendering completely on the floor would be
doable too, but something like writing the correct layers for
attachments which have them and drop rendering or clamp layer for the
others would be HIGHLY unpractical).

Roland


Am 23.11.2013 00:24, schrieb Marek Olšák:
> The number of layers can be specified for each framebuffer attachment
> independently in Gallium, Direct3D, and also our hardware. OpenGL
> seems to be the only weirdo here. ;) I think our hardware handles
> writes to non-existent layers independently of other attachments. It
> either clamps the layer index or throws the fragments going to
> non-existent layers away.
> 
> I would silently allow mismatched layer counts and pass them to the
> hardware. It must be able to deal with it in its own way, otherwise it
> wouldn't support it in the first place.
> 
> Marek
> 
> On Sat, Nov 23, 2013 at 12:08 AM, Paul Berry <stereotype441 at gmail.com> 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.
>>
>> 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
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>