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.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...) Can't you just force that alignment? (Not that I know if it would be worth it.)
Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
