dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Daniel Vetter <daniel@ffwll.ch>, DMA-resvusage@phenom.ffwll.local
Cc: daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 06/16] drm/amdgpu: use DMA_RESV_USAGE_KERNEL
Date: Wed, 6 Apr 2022 16:54:01 +0200	[thread overview]
Message-ID: <0228f800-9cc1-e640-4eb3-771f81e1717a@amd.com> (raw)
In-Reply-To: <Yk2Kyhf7Ah9IkNne@phenom.ffwll.local>

Am 06.04.22 um 14:42 schrieb Daniel Vetter:
> On Wed, Apr 06, 2022 at 09:51:22AM +0200, Christian König wrote:
>> Wait only for kernel fences before kmap or UVD direct submission.
>>
>> This also makes sure that we always wait in amdgpu_bo_kmap() even when
>> returning a cached pointer.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++++-----
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c    |  2 +-
>>   2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index a3cdf8a24377..5832c05ab10d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -761,6 +761,11 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
>>   	if (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)
>>   		return -EPERM;
>>   
>> +	r = dma_resv_wait_timeout(bo->tbo.base.resv, DMA_RESV_USAGE_KERNEL,
>> +				  false, MAX_SCHEDULE_TIMEOUT);
>> +	if (r < 0)
>> +		return r;
>> +
>>   	kptr = amdgpu_bo_kptr(bo);
>>   	if (kptr) {
>>   		if (ptr)
>> @@ -768,11 +773,6 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
>>   		return 0;
>>   	}
>>   
>> -	r = dma_resv_wait_timeout(bo->tbo.base.resv, DMA_RESV_USAGE_WRITE,
>> -				  false, MAX_SCHEDULE_TIMEOUT);
>> -	if (r < 0)
>> -		return r;
>> -
>>   	r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
> I wonder whether waiting for kernel fences shouldn't be ttm's duty here.
> Anyway patch makes some sense to me.

I was thinking the same and already had it halve implemented until I 
realized that this won't work because of the ptr caching.

Need to move that around as well and rework the whole handling.

Christian.

>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>   	if (r)
>>   		return r;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
>> index 3654326219e0..6eac649499d3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
>> @@ -1164,7 +1164,7 @@ static int amdgpu_uvd_send_msg(struct amdgpu_ring *ring, struct amdgpu_bo *bo,
>>   
>>   	if (direct) {
>>   		r = dma_resv_wait_timeout(bo->tbo.base.resv,
>> -					  DMA_RESV_USAGE_WRITE, false,
>> +					  DMA_RESV_USAGE_KERNEL, false,
>>   					  msecs_to_jiffies(10));
>>   		if (r == 0)
>>   			r = -ETIMEDOUT;
>> -- 
>> 2.25.1
>>


  reply	other threads:[~2022-04-06 14:54 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06  7:51 Christian König
2022-04-06  7:51 ` [PATCH 01/16] dma-buf/drivers: make reserving a shared slot mandatory v4 Christian König
2022-04-06 12:21   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 02/16] dma-buf: add enum dma_resv_usage v4 Christian König
2022-04-06  7:51 ` [PATCH 03/16] dma-buf: specify usage while adding fences to dma_resv obj v6 Christian König
2022-04-06 12:32   ` Daniel Vetter
2022-04-06 12:35     ` Daniel Vetter
2022-04-07  8:01       ` Christian König
2022-04-07  9:26         ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 04/16] dma-buf & drm/amdgpu: remove dma_resv workaround Christian König
2022-04-06 12:39   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 05/16] dma-buf: add DMA_RESV_USAGE_KERNEL v3 Christian König
2022-04-06 12:41   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 06/16] drm/amdgpu: use DMA_RESV_USAGE_KERNEL Christian König
2022-04-06 12:42   ` Daniel Vetter
2022-04-06 14:54     ` Christian König [this message]
2022-04-06  7:51 ` [PATCH 07/16] drm/radeon: " Christian König
2022-04-06 12:43   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 08/16] drm/etnaviv: always wait for kernel fences Christian König
2022-04-06 12:46   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 09/16] drm/nouveau: only wait for kernel fences in nouveau_bo_vm_cleanup Christian König
2022-04-06 12:47   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 10/16] RDMA: use DMA_RESV_USAGE_KERNEL Christian König
2022-04-06 12:48   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 11/16] dma-buf: add DMA_RESV_USAGE_BOOKKEEP v3 Christian König
2022-04-06  7:51 ` [PATCH 12/16] drm/amdgpu: use DMA_RESV_USAGE_BOOKKEEP Christian König
2022-04-06  7:51 ` [PATCH 13/16] dma-buf: wait for map to complete for static attachments Christian König
2022-04-06  7:51 ` [PATCH 14/16] drm/i915: drop bo->moving dependency Christian König
2022-04-06 13:24   ` Matthew Auld
2022-04-06  7:51 ` [PATCH 15/16] drm/ttm: remove bo->moving Christian König
2022-04-06 12:52   ` Daniel Vetter
2022-04-06  7:51 ` [PATCH 16/16] dma-buf: drop seq count based update Christian König
2022-04-06 13:00   ` Daniel Vetter
2022-04-06 12:59 ` Daniel Vetter

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=0228f800-9cc1-e640-4eb3-771f81e1717a@amd.com \
    --to=christian.koenig@amd.com \
    --cc=DMA-resvusage@phenom.ffwll.local \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /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