From: zhoucm1 <david1.zhou@amd.com>
To: "Christian König" <deathsimple@vodafone.de>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 5/6] drm/amdgpu: save the PD addr before scheduling the job
Date: Thu, 16 Jun 2016 17:54:12 +0800 [thread overview]
Message-ID: <57627744.7080806@amd.com> (raw)
In-Reply-To: <576276FB.1040303@vodafone.de>
On 2016年06月16日 17:52, Christian König wrote:
> Am 16.06.2016 um 10:33 schrieb zhoucm1:
>>
>>
>> On 2016年06月15日 19:44, Christian König wrote:
>>> From: Christian König <christian.koenig@amd.com>
>>>
>>> When we pipeline evictions the page directory could already be
>>> moving somewhere else when grab_id is called.
>> Isn't PD bo protected by job fence?
>> I think before job fence is signalled, the PD bo is safe, there
>> shouldn't be a chance to evict PD bo.
>
> The crux here is that we start to pipeline BO evictions (we plan them
> but don't execute them immediately).
>
> E.g. the eviction won't happen before the protecting fence is
> signaled, but we have it planned and so the address returned by
> amdgpu_bo_gpu_offset() is already the new one.
Thanks for mentioned, I see the code in ttm_bo_handle_move_mem:
if (bo->mem.mm_node) {
bo->offset = (bo->mem.start << PAGE_SHIFT) +
bdev->man[bo->mem.mem_type].gpu_offset;
bo->cur_placement = bo->mem.placement;
} else
bo->offset = 0;
it seems better to update the offset after the moving-fence is
signalled, add a moving-fence callback?
Regards,
David Zhou
>
> Regards,
> Christian.
>
>>
>> Regards,
>> David Zhou
>>>
>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++----
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> index a3d7d13..850c4dd 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> @@ -661,6 +661,8 @@ static int amdgpu_cs_ib_vm_chunk(struct
>>> amdgpu_device *adev,
>>> }
>>> }
>>> + p->job->vm_pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
>>> +
>>> r = amdgpu_bo_vm_update_pte(p, vm);
>>> if (!r)
>>> amdgpu_cs_sync_rings(p);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index d3e0576..82efb40 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -177,7 +177,6 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm,
>>> struct amdgpu_ring *ring,
>>> struct amdgpu_sync *sync, struct fence *fence,
>>> unsigned *vm_id, uint64_t *vm_pd_addr)
>>> {
>>> - uint64_t pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
>>> struct amdgpu_device *adev = ring->adev;
>>> struct fence *updates = sync->last_vm_update;
>>> struct amdgpu_vm_id *id, *idle;
>>> @@ -250,7 +249,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm,
>>> struct amdgpu_ring *ring,
>>> if (atomic64_read(&id->owner) != vm->client_id)
>>> continue;
>>> - if (pd_addr != id->pd_gpu_addr)
>>> + if (*vm_pd_addr != id->pd_gpu_addr)
>>> continue;
>>> if (!same_ring &&
>>> @@ -298,14 +297,13 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm,
>>> struct amdgpu_ring *ring,
>>> fence_put(id->flushed_updates);
>>> id->flushed_updates = fence_get(updates);
>>> - id->pd_gpu_addr = pd_addr;
>>> + id->pd_gpu_addr = *vm_pd_addr;
>>> list_move_tail(&id->list, &adev->vm_manager.ids_lru);
>>> atomic64_set(&id->owner, vm->client_id);
>>> vm->ids[ring->idx] = id;
>>> *vm_id = id - adev->vm_manager.ids;
>>> - *vm_pd_addr = pd_addr;
>>> trace_amdgpu_vm_grab_id(vm, ring->idx, *vm_id, *vm_pd_addr);
>>> error:
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-06-16 10:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 11:44 [PATCH 1/6] drm/ttm: remove no_gpu_wait param from ttm_bo_move_accel_cleanup Christian König
2016-06-15 11:44 ` [PATCH 2/6] drm/ttm: remove TTM_BO_PRIV_FLAG_MOVING Christian König
2016-06-15 11:44 ` [PATCH 3/6] drm/ttm: simplify ttm_bo_wait Christian König
2016-06-15 11:44 ` [PATCH 4/6] drm/ttm: add the infrastructur for pipelined evictions Christian König
2016-06-15 16:21 ` Alex Deucher
2016-07-02 8:39 ` Thomas Hellstrom
2016-07-02 16:10 ` Christian König
2016-06-15 11:44 ` [PATCH 5/6] drm/amdgpu: save the PD addr before scheduling the job Christian König
2016-06-16 8:33 ` zhoucm1
2016-06-16 9:52 ` Christian König
2016-06-16 9:54 ` zhoucm1 [this message]
2016-06-16 10:10 ` Christian König
2016-06-15 11:44 ` [PATCH 6/6] drm/amdgpu: pipeline evictions as well Christian König
2016-06-15 16:22 ` Alex Deucher
2016-06-15 13:27 ` [PATCH 1/6] drm/ttm: remove no_gpu_wait param from ttm_bo_move_accel_cleanup Christian König
2016-06-15 15:57 ` Alex Deucher
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=57627744.7080806@amd.com \
--to=david1.zhou@amd.com \
--cc=deathsimple@vodafone.de \
--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