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

[Kenneth Graunke]

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.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).

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.