I'm glad this is being worked on. However, somewhat to my surprise, this patch series didn't help Dying Light's BO eviction problem. For those who don't know, that game performs very badly in certain areas, and it is correlated with increased TTM eviction rates. Relevant screenshots of gallium HUD and sysprof: http://www.fastquake.com/images/screen-dlgalliumhud1-20170513-171241.png http://www.fastquake.com/images/screen-dlsysprof-20170515-225919.png I noticed last week that adding RADEON_DOMAIN_GTT to the domains in radeonsi (patch: http://www.fastquake.com/files/text/radeon-gtt.txt ) greatly improved performance in these areas, to the tune of about a 30fps increase. Obviously, putting GTT in every buffer's domain is not a proper solution. But it lead me to believe that perhaps the problem wasn't just the swapping of resident BOs, but the creation of new ones that only have VRAM in their domain, and they cause existing BOs to be evicted from visible VRAM unconditionally. The attached patch assigns GTT as the busy placement for newly created BOs that have the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag, so that they will go to GTT if visible VRAM is full, instead of evicting established BOs. Since there is no way to know what the usage patterns of a new BO will be, we shouldn't evict established BOs (for which we have hypothetically had the opportunity to gather usage data) from visible VRAM for new, unknown BOs. With this patch I get hugely improved performance in Dying Light just like with the Mesa patch: I observed 30-40fps where I got 14 before, and 60fps where I got 40 before. TTM evictions and bytes moved have dropped to zero where they were exceedingly high before. Buffer evictions no longer dominate the prof trace. Screenshots: http://www.fastquake.com/images/screen-dl-gtt_busy_only-20170518-192602.png http://www.fastquake.com/images/screen-dlsysprof-gttpatch-20170518-223200.png -- John Brooks (Frogging101)
