On 22 August 2012 12:35, Eric Anholt <e...@anholt.net> wrote: > Paul Berry <stereotype...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
