From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Matthew Brost" <matthew.brost@intel.com>,
arunpravin.paneerselvam@amd.com,
"Thomas Hellström (Intel)" <thomas_os@shipmail.org>,
francois.dugast@intel.com, amd-gfx@lists.freedesktop.org,
luben.tuikov@amd.com, dakr@redhat.com,
dri-devel@lists.freedesktop.org, felix.kuehling@amd.com
Subject: Re: [PATCH 01/13] drm: execution context for GEM buffers v4
Date: Mon, 19 Jun 2023 14:29:23 +0200 [thread overview]
Message-ID: <20230619142923.74c21fca@collabora.com> (raw)
In-Reply-To: <26c94e6a-9458-7aeb-8e6f-85838bac43ca@amd.com>
On Mon, 19 Jun 2023 12:44:06 +0200
Christian König <christian.koenig@amd.com> wrote:
> Am 19.06.23 um 12:12 schrieb Boris Brezillon:
> > [SNIP]
> > Note that the drm_exec_until_all_locked() helper I introduced is taking
> > an expression, so in theory, you don't have to define a separate
> > function.
> >
> > drm_exec_until_all_locked(&exec, {
> > /* inlined-code */
> > int ret;
> >
> > ret = blabla()
> > if (ret)
> > goto error;
> >
> > ...
> >
> > error:
> > /* return value. */
> > ret;
> > });
> >
> > This being said, as soon as you have several failure paths,
> > it makes things a lot easier/controllable if you make it a function,
> > and I honestly don't think the readability would suffer from having a
> > function defined just above the user. My main concern with the original
> > approach was the risk of calling continue/break_if_contended() in the
> > wrong place, and also the fact you can't really externalize things to
> > a function if you're looking for a cleaner split. At least with
> > drm_exec_until_all_locked() you can do both.
>
> Yeah, but that means that you can't use return inside your code block
> and instead has to define an error label for handling "normal"
> contention which is what I'm trying to avoid here.
Sorry, didn't pay attention to this particular concern. Indeed, if you
want to return inside the expression, that's a problem.
>
> How about:
>
> #define drm_exec_until_all_locked(exec) \
> __drm_exec_retry: if (drm_exec_cleanup(exec))
>
>
> #define drm_exec_retry_on_contention(exec) \
> if (unlikely(drm_exec_is_contended(exec))) \
> goto __drm_exec_retry
>
>
> And then use it like:
>
> drm_exec_until_all_locked(exec)
> {
> ret = drm_exec_prepare_obj(exec, obj);
> drm_exec_retry_on_contention(exec);
> }
>
> The only problem I can see with this is that the __drm_exec_retry label
> would be function local.
Yeah, I'm not sure it's safe to use non-local labels for that, because,
as soon as you have more than one drm_exec_until_all_locked() call in a
given function it won't work, which is why I placed things in a block
with local labels, which in turn means you can't return directly,
unfortunately.
next prev parent reply other threads:[~2023-06-19 12:29 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 11:51 Common DRM execution context v4 Christian König
2023-05-04 11:51 ` [PATCH 01/13] drm: execution context for GEM buffers v4 Christian König
2023-05-04 14:02 ` Thomas Hellström (Intel)
2023-05-25 20:42 ` Danilo Krummrich
2023-06-14 12:23 ` Boris Brezillon
2023-06-14 12:30 ` Christian König
2023-06-14 13:02 ` Boris Brezillon
2023-06-17 11:54 ` Boris Brezillon
2023-06-19 8:59 ` Thomas Hellström (Intel)
2023-06-19 9:20 ` Christian König
2023-06-19 9:33 ` Thomas Hellström (Intel)
2023-06-19 9:48 ` Christian König
2023-06-19 11:06 ` Thomas Hellström (Intel)
2023-06-21 13:35 ` Christian König
2023-06-19 10:23 ` Boris Brezillon
2023-06-19 10:12 ` Boris Brezillon
2023-06-19 10:44 ` Christian König
2023-06-19 11:05 ` Boris Brezillon
2023-06-19 12:01 ` Boris Brezillon
2023-06-19 12:29 ` Boris Brezillon [this message]
2023-06-20 6:47 ` Boris Brezillon
2023-06-20 7:28 ` Christian König
2023-05-04 11:51 ` [PATCH 02/13] drm: add drm_exec selftests v2 Christian König
2023-05-04 12:07 ` Maíra Canal
2023-05-04 12:52 ` Christian König
2023-05-04 11:51 ` [PATCH 03/13] drm/amdkfd: switch over to using drm_exec v2 Christian König
2023-05-04 11:51 ` [PATCH 04/13] drm/amdgpu: use drm_exec for GEM and CSA handling Christian König
2023-05-04 11:51 ` [PATCH 05/13] drm/amdgpu: use drm_exec for MES testing Christian König
2023-05-04 11:51 ` [PATCH 06/13] drm/amdgpu: use the new drm_exec object for CS v2 Christian König
2023-06-12 13:16 ` Tatsuyuki Ishi
2023-06-20 4:07 ` Tatsuyuki Ishi
2023-06-20 4:14 ` Tatsuyuki Ishi
2023-06-20 8:13 ` Christian König
2023-06-20 8:12 ` Christian König
2023-06-20 8:16 ` Tatsuyuki Ishi
2023-06-20 9:04 ` Tatsuyuki Ishi
2023-06-20 8:28 ` Boris Brezillon
2023-06-20 8:44 ` Christian König
2023-06-20 9:09 ` Boris Brezillon
2023-06-20 9:14 ` Christian König
2023-06-20 9:20 ` Boris Brezillon
2023-05-04 11:51 ` [PATCH 07/13] drm/radeon: switch over to drm_exec Christian König
2023-05-04 11:51 ` [PATCH 08/13] drm/qxl: switch to using drm_exec Christian König
2023-06-20 9:13 ` Thomas Zimmermann
2023-06-20 9:15 ` Christian König
2023-05-04 11:51 ` [PATCH 09/13] drm/lima: " Christian König
2023-05-04 11:51 ` [PATCH 10/13] drm/virtgpu: " Christian König
2023-05-04 11:51 ` [PATCH 11/13] drm/panfrost: " Christian König
2023-05-04 11:51 ` [PATCH 12/13] drm/v3d: " Christian König
2023-05-04 11:51 ` [PATCH 13/13] drm: remove drm_gem_(un)lock_reservations Christian König
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=20230619142923.74c21fca@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=arunpravin.paneerselvam@amd.com \
--cc=christian.koenig@amd.com \
--cc=dakr@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=francois.dugast@intel.com \
--cc=luben.tuikov@amd.com \
--cc=matthew.brost@intel.com \
--cc=thomas_os@shipmail.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