[RFC 0/9] nuclear pageflip

[Jesse Barnes]

On Wed, 12 Sep 2012 21:58:31 +0300
Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:

> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
> > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä
> > <ville.syrjala at linux.intel.com> wrote:
> > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
> > >> But I think we could still do this w/ one ioctl per crtc for atomic-pageflip.
> > >
> > > We could, if we want to sacrifice the synced multi display case. I just
> > > think it might be a real use case at some point. IVI feels like the most
> > > likely short term cadidate to me, but perhaps someone would finally
> > > introduce some new style phone/tablet thingy. I have seen
> > > concepts/prototypes of such multi display gadgets in the past, but the
> > > industry apparently got a bit stuck on the rectangular slab with
> > > touchscreen on one side design.
> > 
> > I could be wrong, but I think IVI the screens would normally be too
> > far apart to matter?
> 
> I was thinking of something like a display on the dash that normally
> sits low with only a small sliver visible, and extends upwards when
> you fire up a movie player for example. Internally it could be made
> up of two displays for power savings purposes.
> 
> > Anyways, it is really only a problem if you can't do two ioctl()s
> > within one vblank period. If it actually turns out to be a real
> > problem,
> 
> Well exactly that's the problem this whole atomic pageflip stuff is
> trying to tackle, no? ;)
> 
> > we could always add later an ioctl that takes an array of
> > 'struct drm_mode_crtc_atomic_page_flip's.  I'm not sure if this is
> > really useful or not.. but maybe I'm thinking too much about how
> > weston does it's rendering of different output's independently.
> 
> I'm just now thinking of surfaceflinger's way of doing things, with
> its prepare and commit phases. If you need to issue two ioctls to handle
> cloned displays, then you can end up in a somewhat funky situation.
> 
> Let's say you have a video overlay in use (one each display naturally),
> and you increase the downscaling factor enough so that you now have
> enough memory bandwith to support only one overlay. With independent
> check ioctls for each display, you never have the full device state
> available in the kernel, so each check succeeds during the prepare
> phase. So you decide that you can keep using the video overlays.
> 
> You then proceed to commit the state, but after the first display has
> been commited you get an error when trying to commit the second one.
> What can you do now? The only option is to keep displaying the old
> frame on the other displays for some time longer, and then on the
> next frame you can switch to GPU composition. But on the next frame you
> perhaps no longer need to use GPU composition, but since you can't
> verify that in the prepare phase, you have no other option but to use
> GPU composition.
> 
> So when you run into a configuration that can be supported only
> partially, you get animation stalls on some displays due to skipped
> frames, and you always have to fall back to GPU composition for the 
> next frame.
> 
> If on the other hand you would check the whole state in one ioctl,
> you'd get the error in the first prepare phase, and could fall back
> to GPU composition immediately.
> 
> Am I too much of a perfectionst in considering such things? I don't
> think so, but perhaps other people disagree.

I don't think there's any harm in having multiple ioctls for different
things.

I was initially hoping the nuclear page flip would be very simple.
Intended for simply updating buffers of several planes associated with
a single display.  That makes the inner loop of something like Wayland
or SF simple, but obviously doesn't cover every case (in fact I had
avoided dealing with moving planes initially).

Rob's patchset goes further than that, but obviously not as far as you
propose.

OTOH, keeping things really simple and not very featureful means there
are fewer points of failure, which is what I think callers would expect
from a flip API...

So where does that leave us?  I'd propose we have a very simple,
stripped down, single crtc flip ioctl, along with a big atomic mode set
ioctl, and then perhaps a fancier multi-crtc flip ioctl.

-- 
Jesse Barnes, Intel Open Source Technology Center