[Mesa-dev] [RFC PATCH 00/12] Enable GL_AMD_vertex_shader_layer extension

[Jordan Justen]

On Wed, Jul 17, 2013 at 1:09 PM, Paul Berry <stereotype441 at gmail.com> wrote:
> On 15 July 2013 17:14, Jordan Justen <jordan.l.justen at intel.com> wrote:
>>
>> git://people.freedesktop.org/~jljusten/mesa ivb-full-depth-buffer-v1
>>
>> This series converts DEPTH_BUFFER to use the LOD and
>> minimum array element fields and always points the
>> depth, hiz and stencil buffers at the top of the
>> miptree surface.
>>
>> This should allows us to support layered rendering,
>> although testing of this is not completed. Layered
>> rendering will be required for GL 3.2 / GLSL 1.50
>> support, but it can also be exposed via the
>> GL_AMD_vertex_shader_layer extension.
>
>
> I sent out comments on patches 2, 6, and 11.  The remainder are:
>
> Reviewed-by: Paul Berry <stereotype441 at gmail.com>
>
> One question, though:
>
> One of the things I recall us talking about is the problem that Intel
> hardware assumes that we always render to the same level/layer of the depth
> buffer as we do to the stencil buffer.  When the framebuffer is layered,
> that happens automatically, but when the framebuffer isn't layered, there's
> nothing in the GL API to enforce this restriction.
>
> I recall some time ago talking about two possible solutions to that:
>
> (a) If the user tries to create a non-layered framebuffer where the depth
> and stencil attachments use different level/layer settings, mark the
> framebuffer as incomplete using FRAMEBUFFER_UNSUPPORTED (the GL spec allows
> for this in order to accommodate implementation-dependent restrictions, and
> it sounds like this is precisely the situation we find ourselves in)
>
> (b) If the user tries to render to a non-layered framebuffer in which the
> depth and stencil attachments use different level/layer settings, blit into
> a temporary non-layered depth/stencil buffer for the duration of rendering
> (much of the infrastructure behind brw_workaround_depthstencil_alignment()
> could probably be re-used for this purpose).
>
> I don't see your series doing either of these two things.  Am I missing
> something?

No. Sorry, I missed this.

> My preference, incidentally, is to do (a), since it's far easier, and it's
> totally permitted by the GL spec.  If we discover that marking the
> framebuffer as incomplete is causing real-world apps to fail, we can always
> switch to (b) in the future.

I made a quick hack depthstencil-different-lod test here:
git://people.freedesktop.org/~jljusten/piglit depthstencil-different-lod
http://cgit.freedesktop.org/~jljusten/piglit/commit/?h=depthstencil-different-lod&id=2ce6ca61

It tries to attach depth lod 1 and stencil lod 0. This test does not
try to render anything. It just tries to set up the framebuffer.

On Mesa IVB (as expected) this currently succeeds.

On 3.3.0 NVIDIA 304.88 / GeForce GT 240/PCIe/SSE2, I see framebuffer incomplete.

Based on this, it seems likely that this might be an okay candidate
for framebuffer incomplete, but should we check more drivers?

Does my test code look like it is checking properly?

-Jordan