From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Alex Deucher <alexdeucher@gmail.com>,
Tvrtko Ursulin <tursulin@igalia.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
kernel-dev@igalia.com,
"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
"Christian König" <christian.koenig@amd.com>,
"Friedrich Vock" <friedrich.vock@gmx.de>
Subject: Re: [RFC v2 0/2] Discussion around eviction improvements
Date: Fri, 31 May 2024 11:12:13 +0200 [thread overview]
Message-ID: <bd1d46ca-044b-468b-9458-4e9e43472930@gmail.com> (raw)
In-Reply-To: <CADnq5_PhZ5bqEJKQ+bPQAeXihMfZrFVqLN-+nd69+zZooBT6BA@mail.gmail.com>
Am 16.05.24 um 21:21 schrieb Alex Deucher:
> On Thu, May 16, 2024 at 8:18 AM Tvrtko Ursulin <tursulin@igalia.com> wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>>
>> 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
> this regressed when Christian reworked ttm to better handle migrating
> buffers back to VRAM after suspend on dGPUs?
Yeah, that's quite likely. I'm already looking into this.
Regards,
Christian.
>
> Alex
>
>> 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
>>
>> 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@amd.com>
>> Cc: Friedrich Vock <friedrich.vock@gmx.de>
>>
>> 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
>>
next prev parent reply other threads:[~2024-05-31 9:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 12:18 [RFC v2 0/2] Discussion around eviction improvements Tvrtko Ursulin
2024-05-16 12:18 ` [RFC 1/2] drm/amdgpu: Re-validate evicted buffers Tvrtko Ursulin
2024-05-16 12:18 ` [RFC 2/2] drm/amdgpu: Actually respect buffer migration budget Tvrtko Ursulin
2024-05-16 19:21 ` [RFC v2 0/2] Discussion around eviction improvements Alex Deucher
2024-05-17 7:41 ` Tvrtko Ursulin
2024-05-17 13:43 ` Alex Deucher
2024-05-31 9:12 ` Christian König [this message]
2024-05-30 10:17 ` Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd1d46ca-044b-468b-9458-4e9e43472930@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=friedrich.vock@gmx.de \
--cc=kernel-dev@igalia.com \
--cc=tursulin@igalia.com \
--cc=tvrtko.ursulin@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.