From: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
To: Chris Wilson
<chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>,
"Zhou,
David(ChunMing)" <David1.Zhou-5C7GfCeVMHo@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Christian König"
<ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
Date: Thu, 13 Dec 2018 12:11:10 +0000 [thread overview]
Message-ID: <36d34a20-2562-4265-9abc-4d3bd6d358ef@amd.com> (raw)
In-Reply-To: <154470106444.11001.18115532802703573952@skylake-alporthouse-com>
Am 13.12.18 um 12:37 schrieb Chris Wilson:
> Quoting Chunming Zhou (2018-12-11 10:34:45)
>> From: Christian König <ckoenig.leichtzumerken@gmail.com>
>>
>> Implement finding the right timeline point in drm_syncobj_find_fence.
>>
>> v2: return -EINVAL when the point is not submitted yet.
>> v3: fix reference counting bug, add flags handling as well
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 43 ++++++++++++++++++++++++++++++++---
>> 1 file changed, 40 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index 76ce13dafc4d..d964b348ecba 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
>> struct dma_fence **fence)
>> {
>> struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
>> - int ret = 0;
>> + struct syncobj_wait_entry wait;
>> + int ret;
>>
>> if (!syncobj)
>> return -ENOENT;
>>
>> *fence = drm_syncobj_fence_get(syncobj);
>> - if (!*fence) {
>> + drm_syncobj_put(syncobj);
>> +
>> + if (*fence) {
>> + ret = dma_fence_chain_find_seqno(fence, point);
>> + if (!ret)
>> + return 0;
>> + dma_fence_put(*fence);
>> + } else {
>> ret = -EINVAL;
>> }
>> - drm_syncobj_put(syncobj);
>> +
>> + if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
>> + return ret;
>> +
>> + memset(&wait, 0, sizeof(wait));
>> + wait.task = current;
>> + wait.point = point;
>> + drm_syncobj_fence_add_wait(syncobj, &wait);
>> +
>> + do {
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + if (wait.fence) {
>> + ret = 0;
>> + break;
>> + }
>> +
>> + if (signal_pending(current)) {
>> + ret = -ERESTARTSYS;
>> + break;
>> + }
>> +
>> + schedule();
>> + } while (1);
> I've previously used a dma_fence_proxy so that we could do nonblocking
> waits on future submits. That would be preferrable (a requirement for
> our stupid BKL-driven code).
That is exactly what I would definitely NAK.
I would rather say we should come up with a wait_multiple_events() macro
and completely nuke the custom implementation of this in:
1. dma_fence_default_wait and dma_fence_wait_any_timeout
2. the radeon fence implementation
3. the nouveau fence implementation
4. the syncobj code
Cause all of them do exactly the same. The dma_fence implementation
unfortunately came up with a custom event handling mechanism instead of
extending the core Linux wait_event() system.
This in turn lead to a lot of this duplicated handling.
Christian.
> -Chris
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-12-13 12:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 10:34 [PATCH 01/10] dma-buf: add new dma_fence_chain container v4 Chunming Zhou
2018-12-11 10:34 ` [PATCH 02/10] drm/syncobj: remove drm_syncobj_cb and cleanup Chunming Zhou
2018-12-11 10:34 ` [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v3 Chunming Zhou
2018-12-11 10:34 ` [PATCH 04/10] drm/syncobj: add support for timeline point wait v8 Chunming Zhou
2018-12-11 10:34 ` [PATCH 05/10] drm/syncobj: add timeline payload query ioctl v4 Chunming Zhou
2018-12-11 10:34 ` [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3 Chunming Zhou
2018-12-13 11:37 ` Chris Wilson
2018-12-13 12:11 ` Koenig, Christian [this message]
[not found] ` <36d34a20-2562-4265-9abc-4d3bd6d358ef-5C7GfCeVMHo@public.gmane.org>
2018-12-13 12:21 ` [Intel-gfx] " Chris Wilson
2018-12-13 12:24 ` Koenig, Christian
2018-12-13 16:01 ` Daniel Vetter
[not found] ` <20181213160148.GG21184-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-12-13 16:47 ` Koenig, Christian
2018-12-13 17:26 ` Daniel Vetter
2018-12-13 18:55 ` Koenig, Christian
[not found] ` <20181211103449.25899-1-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2018-12-11 10:34 ` [PATCH 07/10] drm/amdgpu: add timeline support in amdgpu CS v2 Chunming Zhou
2018-12-11 10:34 ` [PATCH 08/10] drm/syncobj: add transition iotcls between binary and timeline v2 Chunming Zhou
2018-12-13 11:29 ` [Intel-gfx] [PATCH 01/10] dma-buf: add new dma_fence_chain container v4 Chris Wilson
2018-12-11 10:34 ` [PATCH 09/10] drm/syncobj: add timeline signal ioctl for syncobj v2 Chunming Zhou
2018-12-11 10:34 ` [PATCH 10/10] drm/amdgpu: update version for timeline syncobj support in amdgpu Chunming Zhou
2018-12-12 5:31 ` [PATCH 01/10] dma-buf: add new dma_fence_chain container v4 Zhou, David(ChunMing)
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=36d34a20-2562-4265-9abc-4d3bd6d358ef@amd.com \
--to=christian.koenig-5c7gfcevmho@public.gmane.org \
--cc=David1.Zhou-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org \
--cc=ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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