From: "Christian König" <christian.koenig@amd.com>
To: Simon Ser <contact@emersion.fr>
Cc: Jason Ekstrand <jason@jlekstrand.net>,
James Jones <jajones@nvidia.com>,
wayland-devel@lists.freedesktop.org,
Pekka Paalanen <ppaalanen@gmail.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline
Date: Tue, 11 Oct 2022 14:10:18 +0200 [thread overview]
Message-ID: <240b0135-5219-b923-ac08-1ed574dcb901@amd.com> (raw)
In-Reply-To: <YlRyF1ugXQAIFNoNIuFRmDek7S85or_YpAz26fHKaaQIYeCB3RVGSjEaYhw6nI0iH_k6vDjPYeF6ekmVeEgUWyf5V5w4aMm8Z5oVPjGQKh4=@emersion.fr>
Am 10.10.22 um 11:13 schrieb Simon Ser:
> On Sunday, October 9th, 2022 at 20:00, Christian König <christian.koenig@amd.com> wrote:
>
>> Am 09.10.22 um 16:40 schrieb Simon Ser:
>>
>>> Introduce a new DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD IOCTL
>>> which signals an eventfd when a timeline point completes.
>> I was entertaining the same though for quite a while, but I would even
>> go a step further and actually always base the wait before signal
>> functionality of the drm_syncobj and the eventfd functionality. That
>> would save us quite a bit of complexity I think.
> Hm what do you mean exactly? I'm not sure I'm following.
Essentially we have the syncobj_wait_entry structure which is added to
the list whenever somebody starts to wait for a sequence which hasn't
materialized yet.
Instead of extending this maybe just completely nuke the
syncobj_wait_entry handling and replace it with your implementation here.
Absolutely not a must have, but might be easier to maintain in the long
term.
Regards,
Christian.
>
>> As a general note I think the name
>> DRM_IOCTL_SYNCOBJ_TIMELINE_REGISTER_EVENTFD is just to long, just make
>> that DRM_IOCTL_SYNCOBJ_EVENTFD. Same for the function names as well.
> Agreed.
>
>> Additional to that I think we should also always have a graceful
>> handling for binary syncobjs. So please try to avoid making this special
>> for the timeline case (the timeline case should of course still be
>> supported).
> This makes sense to me.
next prev parent reply other threads:[~2022-10-11 12:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-09 14:40 [RFC PATCH] drm/syncobj: add IOCTL to register an eventfd for a timeline Simon Ser
2022-10-09 18:00 ` Christian König
2022-10-10 9:13 ` Simon Ser
2022-10-11 12:10 ` Christian König [this message]
2022-10-12 10:25 ` Simon Ser
2022-10-12 11:00 ` Christian König
2022-10-10 8:19 ` Pekka Paalanen
2022-10-10 9:20 ` Simon Ser
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=240b0135-5219-b923-ac08-1ed574dcb901@amd.com \
--to=christian.koenig@amd.com \
--cc=contact@emersion.fr \
--cc=dri-devel@lists.freedesktop.org \
--cc=jajones@nvidia.com \
--cc=jason@jlekstrand.net \
--cc=ppaalanen@gmail.com \
--cc=wayland-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.