iris: Don't try to CPU read imported clear color BOs
authorKenneth Graunke <kenneth@whitecape.org>
Mon, 26 Jul 2021 19:59:42 +0000 (12:59 -0700)
committerMarge Bot <eric+marge@anholt.net>
Thu, 12 Aug 2021 19:29:59 +0000 (19:29 +0000)
commite83da2d8e3b1129d6857bb18cb212fdd08cbc69b
tree2e068276cc3a60604dfb4d87f12076c47f2778b7
parent373f0d6accd197812a9de00e388e5b86a5ddd7ff
iris: Don't try to CPU read imported clear color BOs

Previously, when importing a resource with modifiers that include
clear color as auxiliary data, we were mapping the clear color BO
on the CPU in order to set res->aux.clear_color to the value stored
there.

We are generally trying to avoid CPU mapping imported buffers, because
in hybrid setups, they could be from a different device, and may not be
mappable.  So we'd like to avoid that here.

This CPU-side knowledge of the clear color is only used in a few cases:

1. Avoiding a resolve due to a partial clear with a changing clear color

2. Avoiding disabling CCS when rendering to a texture view of a resource
   where the only format difference is sRGB vs. linear and the clear
   color is 0/1.

Instead of mapping the clear color BO on the CPU, we instead set a flag
indicating that we don't know the clear color, and reset it to known on
our first clear.

In the first case, the first partial fast clear of a resource would eat
an extra resolve (there is no penalty if we clear the whole resource).

The second case doesn't seem that critical, as it's someone rendering
to an imported BO - when the common case is to texture from it.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11888>
src/gallium/drivers/iris/iris_clear.c
src/gallium/drivers/iris/iris_resolve.c
src/gallium/drivers/iris/iris_resource.c
src/gallium/drivers/iris/iris_resource.h