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

[Ian Romanick]

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?

> [PATCH 01/12] intel: Conditionally compile mcs-related code for i965 only.
> [PATCH 02/12] intel: Create intel_miptree_get_region() to prepare for fast color clear.
> [PATCH 03/12] i965/gen7+: Create an enum for keeping track of fast color clear state.
> [PATCH 04/12] i965/gen7+: Set up MCS in SURFACE_STATE whenever MCS is present.
> [PATCH 05/12] i965/gen7+: Create helper functions for single-sample MCS buffers.
> [PATCH 06/12] i965/gen7+: Implement fast color clear operation in BLORP.
> [PATCH 07/12] i965/blorp: Expand clear class hierarchy to prepare for RT resolves.
> [PATCH 08/12] i965/blorp: Write blorp code to do render target resolves.
> [PATCH 09/12] i965/gen7+: Ensure that front/back buffers are fast-clear resolved.
> [PATCH 10/12] i965/gen7+: Resolve color buffers when necessary.
> [PATCH 11/12] i965/gen7+: Disable fast color clears on shared regions.
> [PATCH 12/12] i965/gen7: Enable support for fast color clears.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev