diff options
author | Marek Olšák <[email protected]> | 2016-06-21 18:18:46 +0200 |
---|---|---|
committer | Marek Olšák <[email protected]> | 2016-06-29 20:12:00 +0200 |
commit | 49e3c74cdd0da5abd6cad1fb14af6cc0d85d76c9 (patch) | |
tree | 7a928269bb6fc839a7e316265c09626ac8ba3c41 /src/gallium/drivers/radeon/.dir-locals.el | |
parent | 9124457bff70686ea804d7e35fb63bea5db5a8a2 (diff) |
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 <[email protected]>
Diffstat (limited to 'src/gallium/drivers/radeon/.dir-locals.el')
0 files changed, 0 insertions, 0 deletions