AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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);

      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