[RFC 0/9] nuclear pageflip

Wed Sep 12 08:48:16 PDT 2012

On Wed, Sep 12, 2012 at 10:32 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote:
>> On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrjälä
>> <ville.syrjala at linux.intel.com> wrote:
>> > 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 return -EBUSY immediately if there is 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.
>>
>> Hmm, I still think that userspace should handle this.
>>
>> Keeping the existing semantics of -EBUSY when there is a pending flip
>> makes it easier to implement legacy page_flip on top of the atomic
>> APIs so the driver doesn't have to care about the difference.  I don't
>> really see the problem w/ userspace dropping frames (depending on egl
>> swap-interval) if there is still a pending page-flip.
>
> It will have to drop the most recent frames, whereas the kernel
> implementation can drop the older frames, while keeping the latest
> one. This will help minimize latency.

Hmm, ok.. that is a good point.  Well, I suppose we could pass
page_flip->flags in to atomic_begin(), and add a flag to specify
drop-behavior if you are trying to flip faster than vsync.  Probably
also need to add a driver cap to indicate whether or not the hw is
capable of this.

But I think we could still do this w/ one ioctl per crtc for atomic-pageflip.

> I know OMAP isn't really well suited for this due to the GO bit
> semantics, but I don't want to punish all hardware through the API
> design.

yeah.. well adding a cap plus flag, and passing the flags into
atomic_begin() seems like it should do the job.

(on o4, we could actually remap buffers in dmm/tiler synchronized w/
scanout.. or even not sync'd w/ scanout if you want tearing.  It is a
slightly round-about way to do flipping, but I suppose in theory we
could support that on hw newer than o3.)

BR,
-R

> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel