Re: Tackling the indefinite/user DMA fence problem

From: Daniel Stone <daniel@fooishbar.org>
To: Simon Ser <contact@emersion.fr>
Cc: "Daniel Vetter" <daniel@ffwll.ch>,
	tvrtko.ursulin@linux.intel.com, daniels@collabora.com,
	"Michel Dänzer" <michel.daenzer@mailbox.org>,
	gustavo@padovan.org, Felix.Kuehling@amd.com,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Christian König" <christian.koenig@amd.com>,
	linaro-mm-sig@lists.linaro.org, sergemetral@google.com,
	tzimmermann@suse.de, alexander.deucher@amd.com,
	skhawaja@google.com, sumit.semwal@linaro.org,
	jason@jlekstrand.net, maad.aldabagh@amd.com
Subject: Re: Tackling the indefinite/user DMA fence problem
Date: Wed, 25 May 2022 15:15:59 +0100	[thread overview]
Message-ID: <CAPj87rPW=YW8OnRyByJ_-6k3M9Oo7m7cTg88F8AF4TfudAjAJA@mail.gmail.com> (raw)
In-Reply-To: <nR302DiNnOEkhrGg7TsRINiS2R-WuPiI2uJiERdMMaSUV9e_0xlX1eu1CzzhlCXJmJ-ss1BdkTSZ-XiEOnyMUTn6v3A_sb1jTkvAxfuS-f8=@emersion.fr>

Hi,

On Wed, 25 May 2022 at 15:07, Simon Ser <contact@emersion.fr> wrote:
> On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > You can add that to the list of reasons why compositors need to stop
> > > using buffers with unsignaled fences. There's plenty of other reasons
> > > there already (the big one being that otherwise slow clients can slow
> > > down the compositor, even if the compositor uses a high priority context
> > > and the HW supports preemption).
> >
> >
> > Yeah that's tbh another reason why I think we shouldn't do umf as a
> > transparent thing - compositors need to get better anyway, so we might as
> > well take this as a chance to do this right.
>
> As a compositor dev, I agree -- we should definitely be smarter about
> this. Note, it would help a lot to have a good way to integrate the
> waits into a poll(2) event loop.

The same holds for Weston. We're currently working through a bunch of
internal infrastructure to be able to handle this. Mutter (aka GNOME)
is also really well-placed to be able to do this.

Having pollable waits would be really useful, but I don't think it's
essential. In my strawman I'm just waking up at the usual
just-before-repaint point and checking; if it doesn't make it for this
frame then we'll wait for the next frame. If someone submits buffers
which take 4 repaint periods to clear then we'll have 3 'unnecessary'
wakeups, but given the GPU is already slammed then it's not an
efficiency problem I don't think. (I don't know if all the other
compositor people share this view.)

Cheers,
Daniel