Re: [RFC v2 0/2] Discussion around eviction improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux