From: Tvrtko Ursulin <tursulin@ursulin.net>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
friedrich.vock@gmx.de
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/6] drm/amdgpu: Re-validate evicted buffers v2
Date: Tue, 13 Aug 2024 16:07:47 +0100 [thread overview]
Message-ID: <7ff1a613-98b2-4587-a55b-c433e22df5bc@ursulin.net> (raw)
In-Reply-To: <20240604160503.43359-7-christian.koenig@amd.com>
I was waiting for some replies elsewhere on this thread. Anwyay.. for
the below, because I don't understand how come an important fix like
this is not garnering more attention:
On 04/06/2024 17:05, Christian König wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Since you pretty much changed my logic you could also "demote" me to
Reported-by:. In which case I could theoretically even provide an r-b. :)
>
> Currently the driver appears to be thinking that it will be attempting to
> re-validate the evicted buffers on the next submission if they are not in
> their preferred placement.
>
> That however appears not to be true for the very common case of buffers
> with allowed placements of VRAM+GTT. Simply because the check can only
> detect if the current placement is *none* of the preferred ones, happily
> leaving VRAM+GTT buffers in the GTT placement "forever".
>
> Fix it by extending the VRAM+GTT special case to the re-validation logic.
>
> v2: re-work the criteria to consider if something is in it's preferred
> placement or not and also disable the handling on APUs.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 4e2391c83d7c..1a470dafa93d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1242,15 +1242,15 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev, struct amdgpu_bo_va *bo_va,
> return r;
> }
>
> - /* If the BO is not in its preferred location add it back to
> - * the evicted list so that it gets validated again on the
> - * next command submission.
> - */
> if (bo && bo->tbo.base.resv == vm->root.bo->tbo.base.resv) {
> - uint32_t mem_type = bo->tbo.resource->mem_type;
> -
> - if (!(bo->preferred_domains &
> - amdgpu_mem_type_to_domain(mem_type)))
> + /*
> + * If the preferred location is VRAM but we placed it into GTT
> + * add it back to the evicted list so that it gets validated
> + * again on the next command submission.
> + */
> + if (!(adev->flags & AMD_IS_APU) &&
> + bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM &&
> + bo->tbo.resource->mem_type != TTM_PL_VRAM)
I think this logic works to fix discrete and APU apart that I don't like
the special casing things so much. Which is perhaps a consequence of too
many dynamic games with placements. :(
That said, my version also had a little bit of special casing so perhaps
the battle for clean design has been lost.
So ack from me for this version. Not sure it is good to merge it though
without also fixing the migration throttling and that is a more
difficult one (the part where I was awaiting a reply).
Regards,
Tvrtko
> amdgpu_vm_bo_evicted(&bo_va->base);
> else
> amdgpu_vm_bo_idle(&bo_va->base);
prev parent reply other threads:[~2024-08-13 15:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 16:04 Rate limit improvements for TTM Christian König
2024-06-04 16:04 ` [PATCH 1/6] drm/amdgpu: cleanup MES command submission Christian König
2024-06-04 16:04 ` [PATCH 2/6] drm/ttm: add TTM_PL_FLAG_TRESHOLD Christian König
2024-06-05 1:12 ` kernel test robot
2024-06-04 16:05 ` [PATCH 3/6] drm/amdgpu: enable GTT fallback handling for dGPUs only Christian König
2024-11-12 15:12 ` Alex Deucher
2024-06-04 16:05 ` [PATCH 4/6] drm/amdgpu: re-order AMDGPU_GEM_DOMAIN_DOORBELL handling Christian König
2024-06-04 16:05 ` [PATCH 5/6] drm/amdgpu: always enable move threshold for BOs Christian König
2024-06-11 16:24 ` Tvrtko Ursulin
2024-06-14 9:53 ` Christian König
2024-06-14 16:06 ` Tvrtko Ursulin
2024-06-28 8:13 ` Tvrtko Ursulin
2024-06-04 16:05 ` [PATCH 6/6] drm/amdgpu: Re-validate evicted buffers v2 Christian König
2024-08-13 15:07 ` Tvrtko Ursulin [this message]
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=7ff1a613-98b2-4587-a55b-c433e22df5bc@ursulin.net \
--to=tursulin@ursulin.net \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=friedrich.vock@gmx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox