[RFC 0/9] nuclear pageflip

[Ville Syrjälä]

On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > 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.
> 
> that was basically my thinking.. separate ioctls for each crtc.  The
> way my branch works currently, you can do this.  A page-flip on crtc
> #2 won't care that there is still a flip pending on crtc #1.
> 
> I guess that doesn't strictly guarantee that the two pageflips happen
> at the exact same time, but unless you have some way to vsync lock the
> two displays, I don't think that is possible anyways.

Sure you need hardware to keep the pipes in sync.

> So I'm not
> really sure it is worth over-complicating the ioctl to support two
> crtc's. The error checking in case a vsync is still pending is much
> easier in the driver if you know the crtc up-front at the
> atomic_begin() point.  Which is why I prefer to pass the crtc_id as a
> field in the ioctl.

Doing such checks in atomic_begin() is way too early. Unless you want
to block/return immediately if there's a pending flip.

I want to allow user space to force feed the driver with flips at
speeds greater than the display refresh. The last frame to finish
rendering before the vblank is the one that should end up on the
screen. That way you can do tear-free triple buffering without
throttling to screen refresh, which is great for benchmarks. It's
also a nice way to support cases where you want to throttle to a
60 Hz display, but you still want to clone the content to say a
24 or 30 Hz display.

-- 
Ville Syrjälä
Intel OTC