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). 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
