aboutsummaryrefslogtreecommitdiffstats
path: root/SConstruct
diff options
context:
space:
mode:
authorMarek Olšák <[email protected]>2016-06-21 18:18:46 +0200
committerMarek Olšák <[email protected]>2016-06-29 20:12:00 +0200
commit49e3c74cdd0da5abd6cad1fb14af6cc0d85d76c9 (patch)
tree7a928269bb6fc839a7e316265c09626ac8ba3c41 /SConstruct
parent9124457bff70686ea804d7e35fb63bea5db5a8a2 (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 'SConstruct')
0 files changed, 0 insertions, 0 deletions