diff options
author | Nanley Chery <nanley.g.chery@intel.com> | 2023-04-11 19:10:46 -0700 |
---|---|---|
committer | Marge Bot <emma+marge@anholt.net> | 2023-05-15 19:54:02 +0000 |
commit | a0e51fcc4eccf1c543c098deb615013953edab0d (patch) | |
tree | b13b6a64fa4718284c42007391a57408d93a6568 | |
parent | f220f3fdaed5e15fa65644164fe8b1e1b9ed5064 (diff) | |
download | mesa-a0e51fcc4eccf1c543c098deb615013953edab0d.tar.gz |
iris: Init CCS_E to COMPRESSED_NO_CLEAR for XeHP
Use COMPRESSED_NO_CLEAR for the initial CCS aux state instead of
COMPRESSED_CLEAR. This removes a dependency on the initial clear color,
meaning that some resolves related to clear color management are now
avoided.
In the Car Chase benchmark, this avoids all 50 CCS resolves. These only
happen during the warm-up phase of the benchmark, so I'm not sure there
is an impact on FPS. This was tested on a DG2 in small-BAR mode.
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22857>
-rw-r--r-- | src/gallium/drivers/iris/iris_resource.c | 27 |
1 files changed, 20 insertions, 7 deletions
diff --git a/src/gallium/drivers/iris/iris_resource.c b/src/gallium/drivers/iris/iris_resource.c index 1087649f99e..bf2dff289a4 100644 --- a/src/gallium/drivers/iris/iris_resource.c +++ b/src/gallium/drivers/iris/iris_resource.c @@ -889,14 +889,27 @@ iris_resource_configure_aux(struct iris_screen *screen, * "CCS surface does not require initialization. Illegal CCS * [values] are treated as uncompressed memory." * - * Even if we wanted to, we can't initialize the CCS via CPU map. So, - * we choose an aux state which describes the current state and helps - * avoid ambiguating (something not currently supported for STC_CCS). + * The above quote is from the render target section, but we assume + * it applies to CCS in general (e.g., STC_CCS). The uninitialized + * CCS may be in any aux state. We choose the one which is most + * convenient. + * + * We avoid states with CLEAR because stencil does not support it. + * Those states also create a dependency on the clear color, which + * can have negative performance implications. Even though some + * blocks may actually be encoded with CLEAR, we can get away with + * ignoring them - there are no known issues that require fast + * cleared blocks to be tracked and avoided. + * + * We specifically avoid the AUX_INVALID state because it could + * trigger an ambiguate. BLORP does not have support for ambiguating + * stencil. Also, ambiguating some LODs of mipmapped 8bpp surfaces + * seems to stomp on neighboring miplevels. + * + * There is only one remaining aux state which can give us correct + * behavior, COMPRESSED_NO_CLEAR. */ - assert(isl_aux_usage_has_compression(res->aux.usage)); - initial_state = isl_aux_usage_has_fast_clears(res->aux.usage) ? - ISL_AUX_STATE_COMPRESSED_CLEAR : - ISL_AUX_STATE_COMPRESSED_NO_CLEAR; + initial_state = ISL_AUX_STATE_COMPRESSED_NO_CLEAR; } else { assert(res->aux.surf.size_B > 0); /* When CCS is used, we need to ensure that it starts off in a valid |