Message-ID: <20210729123732.3259a9bf@eldfell>
Date:   Thu, 29 Jul 2021 12:37:32 +0300
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Michel Dänzer <michel@...nzer.net>,
        Rob Clark <robdclark@...omium.org>,
        Matthew Brost <matthew.brost@...el.com>,
        Roy Sun <Roy.Sun@....com>,
        Christian König <ckoenig.leichtzumerken@...il.com>,
        open list <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>,
        Luben Tuikov <luben.tuikov@....com>,
        Gustavo Padovan <gustavo@...ovan.org>,
        Alex Deucher <alexander.deucher@....com>,
        Tian Tao <tiantao6@...ilicon.com>,
        Lee Jones <lee.jones@...aro.org>,
        Christian König <christian.koenig@....com>,
        "open list:DMA BUFFER SHARING FRAMEWORK" 
        <linux-media@...r.kernel.org>
Subject: Re: [RFC 0/4] dma-fence: Deadline awareness

On Thu, 29 Jul 2021 11:03:36 +0200
Daniel Vetter <daniel@...ll.ch> wrote:

> On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> > On 2021-07-29 9:09 a.m., Daniel Vetter wrote:  
> > > On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:  
> > >> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer <michel@...nzer.net> wrote:  
> > >>> On 2021-07-28 3:13 p.m., Christian König wrote:  
> > >>>> Am 28.07.21 um 15:08 schrieb Michel Dänzer:  
> > >>>>> On 2021-07-28 1:36 p.m., Christian König wrote:  
> > >>>>>> Am 27.07.21 um 17:37 schrieb Rob Clark:  
> > >>>>>>> On Tue, Jul 27, 2021 at 8:19 AM Michel Dänzer <michel@...nzer.net> wrote:  
> > >>>>>>>> On 2021-07-27 5:12 p.m., Rob Clark wrote:  
> > >>>>>>>>> On Tue, Jul 27, 2021 at 7:50 AM Michel Dänzer <michel@...nzer.net> wrote:  
> > >>>>>>>>>> On 2021-07-27 1:38 a.m., Rob Clark wrote:  
> > >>>>>>>>>>> From: Rob Clark <robdclark@...omium.org>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Based on discussion from a previous series[1] to add a "boost" mechanism
> > >>>>>>>>>>> when, for example, vblank deadlines are missed.  Instead of a boost
> > >>>>>>>>>>> callback, this approach adds a way to set a deadline on the fence, by
> > >>>>>>>>>>> which the waiter would like to see the fence signalled.

...

> > I'm not questioning that this approach helps when there's a direct
> > chain of fences from the client to the page flip. I'm pointing out
> > there will not always be such a chain.
> > 
> >   
> > >> But maybe the solution to make this also useful for mutter  
> > 
> > It's not just mutter BTW. I understand gamescope has been doing
> > this for some time already. And there seems to be consensus among
> > developers of Wayland compositors that this is needed, so I expect
> > at least all the major compositors to do this longer term.
> > 
> >   
> > >> is to, once we have deadline support, extend it with an ioctl to
> > >> the dma-fence fd so userspace can be the one setting the
> > >> deadline.  
> > 
> > I was thinking in a similar direction.
> >   
> > > atomic ioctl with TEST_ONLY and SET_DEADLINES? Still gives mutter
> > > the option to bail out with an old frame if it's too late?  
> > 
> > This is a bit cryptic though, can you elaborate?  
> 
> So essentially when the mutter compositor guesstimator is fairly
> confident about the next frame's composition (recall you're keeping
> track of clients to estimate their usual latency or something like
> that), then it does a TEST_ONLY commit to check it all works and prep
> the rendering, but _not_ yet fire it off.
> 
> Instead it waits until all buffers complete, and if some don't, pick
> the previous one. Which I guess in an extreme case would mean you
> need a different window tree configuration and maybe different
> TEST_ONLY check and all that, not sure how you solve that.
> 
> Anyway, in that TEST_ONLY commit my idea is that you'd also supply
> all the in-fences you expect to depend upon (maybe we need an
> additional list of in-fences for your rendering job), plus a deadline
> when you want to have them done (so that there's enough time for your
> render job still). And the kernel then calls dma_fence_set_deadline
> on all of them.
> 
> Pondering this more, maybe a separate ioctl is simpler where you just
> supply a list of in-fences and deadlines.
> 
> The real reason I want to tie this to atomic is for priviledge
> checking reasons. I don't think normal userspace should have the
> power to set arbitrary deadlines like this - at least on i915 it will
> also give you a slight priority boost and stuff like that, to make
> sure your rendering for the current frame goes in ahead of the next
> frame's prep work.
> 
> So maybe just a new ioctl that does this which is limited to the
> current kms owner (aka drm_master)?

Yeah.

Why not have a Wayland compositor *always* "set the deadlines" for the
next screen update as soon as it gets the wl_surface.commit with the
new buffer and fences (a simplified description of what is actually
necessary to take a new window state set into use)?

The Wayland client posted the frame to the compositor, so surely it
wants it ready and displayed ASAP. If we happen to have a Wayland frame
queuing extension, then also take that into account when setting the
deadline.

Then, *independently* of that, the compositor will choose which frames
it will actually use in its composition when the time comes.

No need for any KMS atomic commit fiddling, userspace just explicitly
sets the deadline on the fence and that's it. You could tie the
privilege of setting deadlines to simply holding DRM master on whatever
device? So the ioctl would need both the fence and any DRM device fd.

A rogue application opening a DRM device and becoming DRM master on it
just to be able to abuse deadlines feels both unlikely and with
insignificant consequences. It stops the obvious abuse, and if someone
actually goes the extra effort, then so what.


Thanks,
pq

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists