[RFC 0/9] nuclear pageflip

[Ville Syrjälä]

On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrjälä
> >> <ville.syrjala at linux.intel.com> wrote:
> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
> >> >> > Rob Clark <rob at ti.com> wrote:
> >> >> >
> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark <rob.clark at linaro.org> wrote:
> >> >> >> > From: Rob Clark <rob at ti.com>
> >> >> >> >
> >> >> >> > This is following a bit the approach that Ville is taking for atomic-
> >> >> >> > modeset, in that it is switching over to using properties for everything.
> >> >> >> > The advantage of this approach is that it makes it easier to add new
> >> >> >> > attributes to set as part of a page-flip (and even opens the option to
> >> >> >> > add new object types).
> >> >> >>
> >> >> >> oh, and for those wondering what the hell this is all about,
> >> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
> >> >> >> and zero or more attached plane layers, optionally changing various
> >> >> >> properties such as z-order (or even blending modes, etc) atomically.
> >> >> >> It includes the option for a test step so userspace compositor can
> >> >> >> test a proposed configuration (if any properties not marked as
> >> >> >> 'dynamic' are updated).  This intended to allow, for example, weston
> >> >> >> compositor to synchronize updates to plane (sprite) layers with CRTC
> >> >> >> layer.
> >> >> >>
> >> >> >
> >> >> > Can we please name this something different? I complained about this in
> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
> >> >> >
> >> >> > Some suggestions:
> >> >> > multiplane pageflip
> >> >> > muliplane atomic pageflip
> >> >> > atomic multiplane pageflip
> >> >> > atomic multiflip
> >> >> > pageflip of atomic and multiplane nature
> >> >> >
> >> >> > Nuclear is not at all descriptive and requires as your response shows
> >> >> > :-)
> >> >> >
> >> >>
> >> >> fair enough.. I was originally calling it atomic-pageflip until
> >> >> someone (I don't remember who) started calling it nuclear-pageflip to
> >> >> differentiate from atomic-modeset.  But IMO we could just call the two
> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
> >> >> pageflip2, but that seems much more boring)
> >> >
> >> > My plan has been to use the same ioctl for both uses. They'll need
> >> > nearly identical handling anyway on the ioctl level. I have something
> >> > semi-working currently, but I need to clean it up a bit before I can
> >> > show it to anyone.
> >>
> >> I do think the atomic-pageflip ioctl really should take the crtc-id..
> >> so probably should be two ioctls, but nearly identical
> >
> > But then you can't support atomic pageflips across multiple crtcs even
> > if the hardware would allow it. I would hate to add such limitation to
> > the API. I can immediately think of a use case; combining several
> > smaller displays to form a single larger display.
> >
> > With a unified API you could just add some kind of flag that tells the
> > kernel that user space really wants an atomic update, and if the
> > driver/hardware can't do it, it can return an error.
> 
> well, that is really only a problem for X11..  and atomic flip across
> multiple crtc's is a potential mess from performance standpoint unless
> your displays are vsync'd lock.

It won't be truly atomic unless they are vsync locked. But anyways more 
buffers can be used to solve the performance problem. But that's a
separate issue and in that case it doesn't really matter whether you
issue separate ioctls for each crtc.

> weston already renders each output individually, rather than spanning
> a single fb across multiple displays like x11 does.  So this problem
> really doesn't exist for weston.

It does if you want to make sure the user sees the flip on both displays
at the same time.

-- 
Ville Syrjälä
Intel OTC