[Mesa-dev] [PATCH 00/12] i965/gen7+: Implement fast color clears.

[Eric Anholt]

Ian Romanick <idr at freedesktop.org> writes:

> On 05/21/2013 04:52 PM, Paul Berry wrote:
>> This series implements fast color clears, a Gen7+ feature which
>> reduces memory bandwidth by deferring the memory writes involved in a
>> glClear() until the same memory is later touched during rendering.
>>
>>  From a broad overview point of view, fast color clears work in a
>> similar way to HiZ: an auxiliary "MCS" buffer keeps track of which
>> parts of the buffer have been cleared but haven't yet had the
>> necessary memory writes performed.  Whenever a color buffer needs to
>> be accessed by the CPU, or by a part of the GPU that is not
>> fast-color-aware, we have to perform a "resolve operation" to force
>> any pending memory writes to occur.
>>
>> This patch series adopts a slightly different strategy (compared to
>> HiZ) for making sure the resolves happen when needed.  Instead of
>> modifying each code path that might need to do a resolve so that it
>> does one if needed, we create an accessor function that does the
>> resolve if needed and then provides the caller with access to the
>> miptree's underlying memory region.  This lets us have a lot more
>> confidence that we didn't miss any code paths, which is important
>> since color buffers are accessed by a large number of code paths.  To
>> discourage future maintainers from trying to bypass the accessor
>> function, it is inline (so that overhead is negligible), and the field
>> it provides access to has been renamed to region_private.
>>
>> Patch 01 ifdefs out some code so that it does not appear in the i915
>> (pre-Gen4) driver--this makes it easier to be confident that these
>> changes won't regress i915.  Patch 02 introduces the aforementioned
>> accessor function.  Patches 03-11 are the guts of the implementation,
>> and patch 12 enables the new feature.
>>
>> No piglit regressions.  I have additional piglit tests which validate
>> specific important corner cases--I hope to get those out to the list
>> later this week.
>
> I sent some comments and review for the tests, and I've sent some other 
> comments about these patches.  My only concern is whether the case of 
> swapping a non-current drawable (that had a fast-clear as the last 
> render) produces the correct result.  In the piglit thread, I suggested 
> adding a test specifically for this case.
>
> I suspect that if fast-clear fails in that case, then multisampling also 
> fails.  Both can probably be fixed as follow-on work.  Does that seem 
> plausible?

Swapping a non-current drawable doesn't work in direct rendering, at
all, since as far back as I was able to figure out.  I saw no way
forward toward making it possible.  I don't think we should distract
this series with this issue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130524/8be74caa/attachment-0001.pgp>