[RFC 0/9] nuclear pageflip

[Rob Clark]

On Fri, Sep 14, 2012 at 4:14 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> 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.

well, I do think it is quite useful to be able to enable/disable
planes as part as part of the flip.. you really don't want to have to
block the compositor for a synchronous operation to enable/disable a
plane..  even if you have to return -EBUSY for a transition (ie. if a
plane is still pending vblank on other crtc to switch over, etc)

I am on the fence about multi-crtc flip.  Although the
everything-is-a-property approach does, I suppose, means we could
support it with one ioctl.  Maybe we should start without.  If later
we want to support multi-crtc flip, we can add a driver cap to give
userspace an idea about what it could expect to work.

What I am leaning towards now is an ioctl a bit more like Ville's
atomic-modeset ioctl, but with a single user_data, and userspace gets
a single event back (if requested).  If userspace wants an event per
CRTC it should do multiple ioctl calls, one per CRTC.

BR,
-R

> --
> Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel