[Mesa-dev] [PATCH 2/2] i965: don't clear resolve map when doing fast depth clears.

[Paul Berry]

On 22 August 2012 12:35, Eric Anholt <eric at anholt.net> wrote:

> Paul Berry <stereotype441 at gmail.com> writes:
>
> > Previously, when performing a fast depth clear, we would also clear
> > the miptree's resolve map.  This destroyed important information,
> > since the resolve map contains information about needed resolves for
> > all levels and layers of the miptree, whereas a depth clear only
> > applies to a single level/layer combination at a time.  As a result,
> > resolves would sometimes fail to occur, leading to incorrect
> > rendering.
> >
> > Fixes rendering artifacts with shadow maps in Unigine Heaven and
> > Unigine Sanctuary.
>
> Nice catch!
>
> However, isn't the issue really that we're incorrectly setting
> needs_depth_resolve on layers/levels of the referenced mt that we're not
> actually changing hiz state for, since they didn't get cleared?  It
> seems like this fixes the current issue, but leaves that bug in place.
>

No, those other layers of the miptree really did need a depth resolve,
because they were previously cleared and then rendered to.  The complete
sequence of operations performed by the Unigine engine in the bug looks
like this:

1. Clear layer 0
2. Render to layer 0
3. Clear layer 1
4. Render to layer 1
  ...
11. Clear layer 5
12. Render to layer 5
13. Use the texture as a cube map.

After step 1, layer 0 needs a depth resolve before we can use it for
texturing, since the fast clear only updated the HiZ buffer, not the depth
buffer.  After step 2, layer 0 still needs a depth resolve, because
rendering stores depth data in a combination of the HiZ and depth buffers.
After step 3, layer 0 still needs a depth resolve, because clearing layer 1
doesn't affect layer 0.  By the time we reach step 13, all layers 0-5 need
a depth resolve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120822/f98db0ae/attachment.html>