On 08/20/2012 04:10 PM, Chad Versace wrote:
On 08/17/2012 02:07 PM, Paul Berry wrote:
On 14 August 2012 16:58, Chad Versace <chad.vers...@linux.intel.com
<mailto:chad.vers...@linux.intel.com>> wrote:

     On creating a hiz miptree, we conservatively marked that each miptree
     slice needed a hiz resolve. But the resolves are unneeded when creating
     a non-texture miptree, so this patch removes them.

     This eliminates one hiz resolve per each creation of a non-texture depth
     miptree.  Hence, this eliminates many resolves when resizing a window.


So, with this change, are the contents of the HiZ buffer uninitialized for a
newly created (or resized) non-texture miptree?  The HW docs don't specify the
exact format of the HiZ buffer, so it's possible that there may be some possible
states of the HiZ buffer that are invalid.  If there are, and the hardware
doesn't deal with those invalid states well, then we run the risk of sporadic
incorrect results (if subsequent rendering fails to bring the HiZ buffer into a
valid state) or possibly sporadic GPU hangs (if the hardware is unable to cope
with the invalid states).

Alternatively, perhaps we could initialize non-texture HiZ buffers to a state
that indicates that they need a fast depth clear rather than a HiZ resolve.
Clears are likely to be much faster than HiZ resolves, because they don't
require reading from the depth buffer.  So we would still get most of the
benefit of avoiding the HiZ resolve, and no risk of undefined behaviour.  In
fact, we might conceivably get even more benefit, since after a fast depth
clear, the HiZ buffer is in a state where future rendering is very efficient
(since the depth buffer doesn't need to be read).

It's not always possible to do a fast depth clear due to size restrictions (the
renderbuffer dimensions must be aligned to 8x4).

Yeah, sadly. (And seriously, whoever invented 1366x768 resolution panels clearly didn't talk the guys that required 8x4 alignment...)

You make a strong point. I don't wish to risk GPU hangs or incorrect rendering
for the sake of improving the performance of resizing windows. So I'll just drop
this patch.

To play devil's advocate here, no one has presented any concrete evidence that the GPU actually does have a problem with this. What if it did turn out to just be paranoia? I'd hate to leave a bunch of overhead and needlessly lower performance or power.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to