gallium/radeon: add a heuristic enabling DCC for scanout surfaces (v2)
authorMarek Olšák <marek.olsak@amd.com>
Tue, 21 Jun 2016 16:18:46 +0000 (18:18 +0200)
committerMarek Olšák <marek.olsak@amd.com>
Wed, 29 Jun 2016 18:12:00 +0000 (20:12 +0200)
commit49e3c74cdd0da5abd6cad1fb14af6cc0d85d76c9
tree7a928269bb6fc839a7e316265c09626ac8ba3c41
parent9124457bff70686ea804d7e35fb63bea5db5a8a2
gallium/radeon: add a heuristic enabling DCC for scanout surfaces (v2)

DCC for displayable surfaces is allocated in a separate buffer and is
enabled or disabled based on PS invocations from 2 frames ago (to let
queries go idle) and the number of slow clears from the current frame.

At least an equivalent of 5 fullscreen draws or slow clears must be done
to enable DCC. (PS invocations / (width * height) + num_slow_clears >= 5)

Pipeline statistic queries are always active if a color buffer that can
have separate DCC is bound, even if separate DCC is disabled. That means
the window color buffer is always monitored and DCC is enabled only when
the situation is right.

The tracking of per-texture queries in r600_common_context is quite ugly,
but I don't see a better way.

The first fast clear always enables DCC. DCC decompression can disable it.
A later fast clear can enable it again. Enable/disable typically happens
only once per frame.

The impact is expected to be negligible because games usually don't have
a high level of overdraw. DCC usually activates when too much blending
is happening (smoke rendering) or when testing glClear performance and
CMASK isn't supported (Stoney).

v2: rename stuff, add assertions

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
src/gallium/drivers/radeon/r600_pipe_common.c
src/gallium/drivers/radeon/r600_pipe_common.h
src/gallium/drivers/radeon/r600_texture.c
src/gallium/drivers/radeonsi/si_blit.c
src/gallium/drivers/radeonsi/si_state.c
src/gallium/drivers/radeonsi/si_state_draw.c