All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 20 Jun 2023 08:47:04 +0200	[thread overview]
Message-ID: <20230620084704.154b95e2@collabora.com> (raw)
In-Reply-To: <20230619142923.74c21fca@collabora.com>

On Mon, 19 Jun 2023 14:29:23 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:

> 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.

Sorry, that's wrong again. Had trouble focusing yesterday...

So, returning directly from the expression block should be perfectly
fine. The only problem is breaking out of the retry loop early and
propagating the error, but that's no more or less problematic than it
was before. We just need the drm_exec_retry_on_contention() helper you
suggested, and a drm_exec_stop() that would go to some local
__drm_exec_stop label.

	int ret = 0;

	ret = drm_exec_until_all_locked(exec, ({
		...
		ret = drm_exec_prepare_obj(exec, objA, 1);
		drm_exec_retry_on_contention(exec);
		if (ret)
			drm_exec_stop(exec, ret);
		...

		ret = drm_exec_prepare_obj(exec, objB, 1);
		drm_exec_retry_on_contention(exec);
		if (ret)
			drm_exec_stop(exec, ret);

		0;
	}));

Which is pretty close to the syntax you defined initially, except for
the '0;' oddity at the end, which is ugly, I admit.

  reply	other threads:[~2023-06-20  6:47 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
2023-06-20  6:47                   ` Boris Brezillon [this message]
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=20230620084704.154b95e2@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 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.