new userspace API approaches atomic *

[Ville Syrjälä]

On Sun, Dec 16, 2012 at 04:04:01PM +1000, Dave Airlie wrote:
> > There are several problems with this:
> >
> > - I can't test other drivers
> >
> > - I don't have the knowledge or inclination to implement atomic semantics
> >   for everyone's favorite hardware, and without that there's little
> >   point in doing the work. Some of my initial code was layered on top of
> >   drm_crtc_helper though, so it might be possible to use that as a basis
> >   for an atomic helper, but there would actually be no benefit from
> >   using it apart from allowing those drivers to respond to the atomic
> >   ioctl. But we wouldn't use any of that w/ i915, so it would be better is
> >   someone else does that part.
> 
> The "I can't test it" argument doesn't fly with me, you are creating a
> new API that adds a useful feature, it should be possible to get a few
> other driver maintainers interested, but also I'd hope that most of
> the ideas for converting to a new API would be mechanical in a lot of
> ways. Atomic semantics aren't hw specific from what i can see, if they
> are then the API is obviously wrong.

How/when the hardware state needs to be updated to guarantee atomic
behaviour _is_ hardware specific. I suppose eventually you could distill
it down to a handful of models that could cover most hardware. But
note that on some hardware even different scanout engines on the same
chip behave differently, so to update them atomically with each other is
going be a delicate dance.

> > - Replacing all the legacy codepaths with new code in one go increases the
> >   chance that we get a regression, and then we have no choice but to
> >   back out the whole thing. Also it seems that no-one apart from Rob has
> >   even looked at the code, so it seems likely that there would be heavy
> >   opposition to replacing the current code with something new.
> 
> I never said one go, I said before pushing the new API. This means you
> get everything internally converted in the drm/driver interface, drop
> the old drm/driver interface, and the new userspace API. At least
> regressions should be a lot more obvious and we can port a driver at a
> time if needed. We can also block new drivers from using the old
> interfaces from being merged.

Now you're confusing me. How can we port one driver at a time if we
can't merge the feature before all drivers are ported? Or do you mean
porting one driver at a time in some staging tree, and then once all are
ported merge the whole thing? Doable, but painful due to code flux.

> > - These are the reasons I would like to merge the thing without touching
> >   the legcay codepaths too much. Then each driver author could move their
> >   code over the new APIs. I'm willing to help of course, but the driver
> >   authors are in a much better position to make something that actually
> >   works for their hardware.
> 
> Yup thats what you want, but you don't want to bring in the new API
> before this happens, since only once you've ported a bunch of drivers
> will you know the API actually works.

You mean the external API? I know it works. It makes no assumptions about
the hardware behaviour. It even resembles OpenWF Display quite decently,
which should reassure some people. It's entirely property based, so if it
wouldn't work then the current property API would be totally broken as well.

If you mean the internal API, then it will also work because it makes no
assumptions either. It's a transaction type of thing, which just builds
the state, and finally commits it. How you do that commit part is
hardware specific, but the input for the commit will be just the new
device state, so each driver has full freedom to handle it as best they
see fit.

> >> f) get b merged standalone, transition phase is fine, but every driver
> >> needs to be ported before the API
> >> goes in.
> >
> > Why? The current drivers are not using the same APIs internally anyway.
> > i915 doesn't use drm_crtc_helper for example. You didn't demand that
> > Daniel rewrite drm_crtc_helper to suit i915 and fix up all the other
> > drivers, did you?
> >
> 
> helpers are not APIs. The API from drm_crtc.c to driver is the main
> modesetting API, for instance Daniel is trying to stop taking locks in
> the drm_crtc side of things, to do this he is going and reimplementing
> lots of bits in lots of drivers at the same time.

I know. But none of that requires writing a lot of hardware specific
logic.

> > Right, so either I rewrite the modeset and pageflip code for all drivers,
> > or I wait until all the driver authors decide to help me. The first one
> > will take approximately five years given that I don't know the hardware
> > and I have other tasks on my plate, and based on the past interest the
> > second one doesn't seem likely to happen anytime soon
> >
> > All this make me think I should just try to push it as an i915 private
> > feature. Damn the other drivers. That should make the management happy too
> > since everyone that needs atomic display updates on Linux will need to buy
> > Intel hardware.
> >
> > Oh well, the world is supposedly ending in a few days anyway, so perhaps
> > I can just relax and stop caring :)
> 
> Well start by converting Intel to a new internal API without the
> external, kick a few driver authors to start porting other drivers to
> the new internal API. The API seems like it should be pretty much hw
> independent. But I expect getting other maintainers interested might
> involve actually going out and actually writing crappy patches and
> sending them to them to pick up. I can also help kick heads in the
> right direction.
> 
> I just don't want to implement any userspace APIs on only one driver,
> and this and atomic modeset are things that are definitely heading in
> that direction.

Convincing others to work on it would be easier if it would be in
the kernel, rather than some private tree. But if you're commited
to merging it eventually, then that's at least some kind of
carrot/stick.

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