[RFC 0/9] nuclear pageflip

[Ville Syrjälä]

On Sat, Sep 15, 2012 at 11:05:29AM -0500, Rob Clark wrote:
> On Sat, Sep 15, 2012 at 9:53 AM, Ville Syrjälä <syrjala at sci.fi> wrote:
> > On Fri, Sep 14, 2012 at 05:46:35PM -0400, Kristian Høgsberg wrote:
> >> I think (hope) the consensus coming out of this thread is something
> >> along these lines:
> >>
> >>  - We use properties for specifying what to change to be future
> >> compatible with new crtc features, but also to allow exposing
> >> hw-specific properties and tie them into the atomicity of the
> >> pageflip.  The KMS overlays are a lowest-common denominator for all
> >> the various overlay types out there and it should be possible to write
> >> a piece of chipset specific compositor code to use features that can't
> >> be expressed through KMS overlays.
> >
> > Properties are good. Check.
> >
> >>  - We have two types of properties: dynamic and non-dynamic ones.
> >> Dynamic properties can always be changed in the next frame (fb bos, hw
> >> cursor position, overlay position, for example), non-dynamic
> >> properties typically involve changing the way bandwidth are allocated
> >> and changing them may fail.
> >
> > There's just no way to make such a general split. The simple fact is
> > that even moving an overlay can fail due to timing/bandwith related
> > constraints.
> 
> fwiw, the driver should indicate this by setting a flag on the
> property, this way userspace knows what can be changed dynamically and
> what can not.

OK maybe user space could notice that all of the properties it's
going to manipulate have that flag in the correct position. User space
could then skip the check ioctl, and proceed straight to the commit
phase with the nice feeling that it should not fail. But that's just
an optimization.

Or are you actually suggesting that changing any property with the
flag in the wrong position would require a full modeset, ie. force
you to take the blocking code path? That just won't fly.

> > So I propose that we have:
> > - One ioctl that takes an arbitrary number of obj/prop/value tuples
> 
> well, to be fair, if we convert everything to properties, maybe
> drm/kms only needs one ioctl for everything :-P

Sure, why not ;) Well, we still have all the enumerations stuff and
whatnot. I see no point in changing those when they work adequately.
But actually setting the state of the hardware can be handled through
a single ioctl.

> But different ioctls are cheap..  I don't think it hurts to have two
> instead of one.  I really don't see modeset and pageflip as the same
> thing. Maybe from the front-end of the video pipe, they are.  But
> from encoder and back they are different.  Modeset can take many
> vblank cycles to complete.  And is infrequent.  Introducing a
> state-machine to try to make this asynchronous is just adding a lot of
> complexity and potential fail for not really much gain.

I don't entirely agree with the infrequent part. Fullscreen video on
external displays is one case where you really may want to change the
mode quite often. Or you may not want to change the actual timings on
the display, but you still want to change the resolution of the CRTC,
and let a panel fitter handle the difference in input and output
resolutions. But thanks to the way kms is designed those two things
are both linked to the display mode of the CRTC, so you still need a
modeset to handle it.

> Even flip on multiple crtcs introduces some new edge cases, like
> moving a plane from one crtc to another.  If this is split into two
> ioctl calls, then the test on the 2nd crtc can -EBUSY because the
> plane is still pending disconnect from the first.  But the test on the
> 1st crtc can succeed.  I can see the usefulness of flip on
> multi-crtc... but since it isn't nearly as useful/important as
> flipping multiple planes on a single crtc, I don't see the harm in
> starting simple and adding this later.

Forcing you to rewrite user space multiple times. And keeping all the
old codepaths around in both kernel and user space side to maintain
ABI compatibility both ways. Also the speed at which these things
trickle through to the actual users is very slow, so adding new ioctls
every six months to handle overlapping tasks is not sensible IMHO.

My _point_ is that there is no need to hardcode these restrictions
into the API. We already know what kind of API will handle all these
cases, so why can't we just go with that API from the very beginning?

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/