On 22 August 2012 12:35, Eric Anholt <<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> 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. </div>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. </blockquote></div> 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.