[Piglit] [PATCH 3/3] GL 3.2: Test layered framebuffers clear the depth attachment properly.

[Chad Versace]

On 09/04/2013 12:34 PM, Paul Berry wrote:

> This needs to be:
>
> glClearBufferfv(GL_DEPTH, 0, &clearDepth);
>
>
>
>
> With this fixed, the test passes, which surprised me, because I expected it
> to fail (I've looked at the code in Mesa, and we haven't implemented proper
> handling for layered depth clears yet).
>
> I did a little digging and here's what is happening:
>
> When the buffer is first created, its contents are undefined.  But in a
> typical test run it happens to get allocated using zero-initialized pages,
> and zero in the HiZ buffer means "clear", so the state looks like this:
>
> depth buffer: all layers 0.  hiz buffer: all layers clear.  resolve map:
> all layers need HiZ resolve
>
> So far so good.  When the initial buffer contents get uploaded using
> glTexImage3D, the state becomes:
>
> depth buffer: layers initialized to {.25, .5, .75, 1}.  hiz buffer: all
> layers clear.  resolve map: all layers need HiZ resolve
>
> This is also correct (the HiZ buffer being in the clear state is not a
> problem because all layers are marked as needing a HiZ resolve).
>
> The next thing that happens is glClear().  What glClear() *should* do is
> put all layers of the hiz buffer in the "clear" state, and all layers of
> the resolve map in the "need depth resolve" state.  It does the correct
> thing to the resolve map, but due to a bug it only clears layer 0 of the
> HiZ buffer.
>
> The problem is, all layers of the HiZ buffer are already in the clear
> state, so we wind up in the correct state by accident:
>
> depth buffer: layers initialized to {.25, .5, .75, 1}.  hiz buffer: all
> layers clear.  resolve map: all layers need depth resolve
>
> And so the test passes by dumb luck.
>
> I think what we need to do is modify the test so that rather than
> populating the buffer using glTexImage3D, it populates it by doing drawing
> operations to all layers.  That way the HiZ buffer will be in a more
> realistic state by the time we try to do the clear, so the test will notice
> if the clear fails to have the proper effect on all layers.
>
> But I wouldn't mind a second opinion on that.  Chad (or anyone else
> familiar with HiZ on Intel), care to comment?

Right. The test should instead uniformly fill each layer of the depth buffer with
a distinct value by using glDepthRange followed by glDraw. Since this test is
attempting to verify the behavior of layered clears, not layered rendering,
I think the best way to fill the depth buffer layers is to
successively attach each texture layer to the fb with glFramebufferTexture3D, use
glDepthRange to choose the depth value, then glDraw. I don't want the test
to attach all layers at once with glFramebufferTextureLayer and cleverly
use layered writes from within a shader.

Even with those modifications, though, this test still fails to verify some
important clear-related paths in the Intel driver.

Jacob, in the Intel driver there exist two very different paths, paths in the code *and* hardware,
for clearing a depth buffer: a fastpath and slowpath. Several factors influence which path
is taken: hardware generation, alignment of the buffer dimensions, the attached miplevel,
and the depth workarounds that the driver happens to implement on the given day.

On gen >= 6, this test only verifies fast depth clears.
However, since this test only verifies clearing level0, I don't see a good way
to verify slow depth clears. If this test were to iterate over miplevels and
had a width/height command line argument, then it would be possible to
verify slow and fast clears. However, I don't advocate that we add these features
now to the test. I'd prefer to see the test get committed in its current form plus
fixes before it gets extended.