On 16/05/2024 20:21, Alex Deucher wrote:
On Thu, May 16, 2024 at 8:18 AM Tvrtko Ursulin <tursulin@xxxxxxxxxx> wrote:From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxx> Reduced re-spin of my previous series after Christian corrected a few misconceptions that I had. So lets see if what remains makes sense or is still misguided. To summarise, the series address the following two issues: * Migration rate limiting does not work, at least not for the common case where userspace configures VRAM+GTT. It thinks it can stop migration attempts by playing with bo->allowed_domains vs bo->preferred domains but, both from the code, and from empirical experiments, I see that not working at all. When both masks are identical fiddling with them achieves nothing. Even when they are not identical allowed has a fallback GTT placement which means that when over the migration budget ttm_bo_validate with bo->allowed_domains can cause migration from GTT to VRAM. * Driver thinks it will be re-validating evicted buffers on the next submission but it does not for the very common case of VRAM+GTT because it only checks if current placement is *none* of the preferred placements.For APUs at least, we should never migrate because GTT and VRAM are both system memory so are effectively equal performance-wise. Maybe
I was curious about this but thought there could be a reason why VRAM carve-out is a fix small-ish size. It cannot be made 1:1 with RAM or some other solution?
this regressed when Christian reworked ttm to better handle migrating buffers back to VRAM after suspend on dGPUs?
I will leave this to Christian to answer but for what this series is concerned I'd say it is orthogonal to that.
Here we have two fixes not limited to APU use cases, just so it happens fixing the migration throttling improves things there too. And that even despite the first patch which triggering *more* migration attempts. Because the second patch then correctly curbs them.
First patch should help with transient overcommit on discrete, allowing things get back into VRAM as soon as there is space.
Second patch tries to makes migration throttling work as intended. Volunteers for testing on discrete? :)
These two patches appear to have a positive result for a memory intensive game like Assassin's Creed Valhalla. On an APU like Steam Deck the game has a working set around 5 GiB, while the VRAM is configured to 1 GiB. Correctly respecting the migration budget appears to keep buffer blits at bay and improves the minimum frame rate, ie. makes things smoother. From the game's built-in benchmark, average of three runs each: FPS migrated KiB min avg max min-1% min-0.1% because 20784781 10.00 37.00 89.67 22.00 12.33 patched 4227688 13.67 37.00 81.33 23.33 15.00
Hmm! s/because/before/ here obviously! Regards, Tvrtko
Disclaimers that I have is that more runs would be needed to be more confident about the results. And more games. And APU versus discrete. Cc: Christian König <christian.koenig@xxxxxxx> Cc: Friedrich Vock <friedrich.vock@xxxxxx> Tvrtko Ursulin (2): drm/amdgpu: Re-validate evicted buffers drm/amdgpu: Actually respect buffer migration budget drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 112 +++++++++++++++++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 ++++- 2 files changed, 103 insertions(+), 30 deletions(-) -- 2.44.0
