summaryrefslogtreecommitdiffstats
path: root/src/intel/blorp
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2018-01-17 21:31:09 -0800
committerJason Ekstrand <[email protected]>2018-02-08 16:35:31 -0800
commit13b621d6fd30b7337844ff53cc8b166d07154a82 (patch)
treee0afd44002d3410b3199899679928e169274b83b /src/intel/blorp
parent571ed588ac5385a1c145d210a1c7b334e04c40ce (diff)
anv: Only fast clear single-slice images
The current strategy we use for managing resolves has an issues where we track clear colors and the need for resolves per-LOD but we still allow resolves of only a subset of the slices in any given LOD and doing so sets the "needs resolve" flag for that LOD to false while leaving the remaining layers unresolved. This patch is only the first step and does not, by itself fix anything. However, it's fairly self-contained and splitting it out means any performance regressions should bisect to this nice obvious commit rather than to the giant "rework aux tracking" commit. Nanley and I did some testing and none of the applications we tested even tried to fast-clear anything other than the first slice of an image. The test was done by adding a printf right before we call blorp_fast_clear if we were every going to touch any slice other than the first with a fast-clear. Due to the way the original code was structured, this would not have included applications which only cleared a subset of layers. The applications tested were: * All Sascha Willems demos * Aztec Ruins * Dota 2 * The Talos Principle * Mad Max * Warhammer 40,000: Dawn of War III * Serious Sam Fusion 2017: BFE While not the full list of shipping applications, it's a pretty good spread and covers most of the engines we've seen running on our driver. If this is ever shown to be a performance problem in the future, we can reconsider our strategy. Reviewed-by: Nanley Chery <[email protected]>
Diffstat (limited to 'src/intel/blorp')
0 files changed, 0 insertions, 0 deletions