[Mesa-dev] [PATCH 2/3] intel: Eliminate unneeded hiz resolves

[Chad Versace]

On 08/17/2012 02:07 PM, Paul Berry wrote:
> On 14 August 2012 16:58, Chad Versace <chad.versace at linux.intel.com
> <mailto:chad.versace at 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).


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.