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

Roland Scheidegger sroland at vmware.com
Tue Aug 21 08:19:41 PDT 2012


Am 21.08.2012 03:51, schrieb 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...)
Can't you just force that alignment?
(Not that I know if it would be worth it.)

Roland



More information about the mesa-dev mailing list