Phoronix: The Fight Over Merging Drivers Back Into X Server
The debate that started back up again this week at XDC2011 Chicago about merging drivers back into the X.Org Server has now moved online. Jesse Barnes has published the pros / cons that were mentioned at the X.Org Developers' Conference this week to the X.Org development mailing list for developers to now debate the idea online. This has been a hotly disputed matter for the past two years...
Some of the drivers (gallium and gallium/rx00 gallium/nouveau to name two well-known ones) are moving at a frantic pace, with every day brining its lot of new features/optimisations. They have their own QA system which works reasonably well (never had a r600 checkout refuse to start on me, and I run git), that said, there is still room for improvement (crashes/corruption), which is why mesa 7.12/8.0 isn't scheduled until January.
OTOH, base xorg apparently observes a much more stringent QA to allow it too keep with its time based schedule. It also moves at a slower pace.
The question being asked is: is forcing everyone into one boat worth the hassle to get rid of version squew(?sp). Personally I'm undecided so I'll let others debate it. One thing is certain though, the question isn't trivial.
P.S: Am I the only one who finds that the troubling part of the bike shed anologie isn't that the bike shed couldn't get built but that the nuclear reactor could?
Does xorg use git? If so, couldn't they have separate fast-paste branches and merge only complete features into master? If not, maybe this would be a good reason to change.
To follow up on my previous post, reading the discussion it is clear they are using git, so this shouldn't really be an issue. Features that are ready go into master, while developers can develop as fast and unstable as they want in other branches.
From that viewpoint, it makes perfect sense to separate the obsolete drivers into a stable, legacy branch and keep Mesa 7.12/8.0 lean and mean.
I really don't see why it has to be like this.
Drivers and core infrastructure should be separated.
Let's take a look.
One point, drivers need to be tested. And what says there is going to be somebody every time for every driver to test and make this change?Pros:
1) easier to propagate API changes across drivers (just like Linux)
1a) thus easier to change ABI
Or have the necessary time to debug unforeseen things?
Driver compat code for various versions allows easy to change api/abi.
They actually already have that because the server can block you from working on a computer. You only create more hurry and delays because projects are being forced to follow another projects timing. This can turn out to be not ideal for other projects and hinder development.2) developers focused on driver development now have more incentive to make sure the server works well so regular releases can still happen (i.e. more people working on blockers whether driver or not as releases approach)
Also you remove the ability of several combinations of driver+server to work. Quite strange that you use incentive to make stuff work as reason for point two and pretend it doesn't exist in this point. Most problems arise from drivers and software needing different versions of x server.3) allows removal of driver compat code for various server versions
3a) thus removes combinations of driver+server that developers have to support & test 4) increased test coverage for the server as users wanting current driver code will be building new servers too
Also you could add libraries that call the newer equivalent calls from the newest server while communicating with something with an older api/abi.
Perfectly possible but it doesn't seem to be done.
(Here is an idea. Why not adding a backwards compatible version that holds the oldest compatible version? )
Seriously, versions are a fact of life and a sign of technological progress. Either you use driver compat code for various server versions or you provide a stable api/abi for a long time.
This is the best solution to make things work reliable and being able to have enough time to develop reasonable complex drivers.
Either you have versions or you will be stuck with always having to do backwards compatibility.
And fantasizing about everyone suddenly magically working in the same pace in one dictated schedule that comes out for just one project is not going to help anything getting done. If you already think other projects can throw everything overboard and just do stuff your schedule then you are not aware of reality.
They would already be doing that if that was possible but obviously this doesn't happen. Making merging servers in x server a joke and useless.
Don't underestimate that, especially the testing for unavailable hardware.Cons:
1) more work for distros to backport just driver changes to old servers (especially if people follow through on (3) above)
Which means smaller use, which means less people interested in getting it to work. (Critical mass harder to achieve.)1a) if backporting is harder, new hardware support will be more difficult to land in "enterprise" level distros
Not only that but sometimes other components depend on a specific server version.2) harder for users to just upgrade drivers independently, now they'll have to build the whole server
2a) thus less testing of current driver code from technical users
This causes stuff not to work any more if you use another one.
Thus becomes unusable.
You have underestimated the capability of dozens of different projects to just adapt to one project out of the blue. If that one project can't be flexible and thinks it needs that to happen. Then it already shows it cannot take into account other projects needs and timing.I've already made my views pretty clear; I'd prefer merging the drivers back in. But I don't do as much work on the DIX or DDX as I used to, and lots of others would be affected as well, so I'd like to hear what people think. Have I captured the pros & cons fully? What to distro maintainers think? And driver developers, both input & output?
You mostly left out when distro's, or other software require a certain server version because something else depends on it.
Now having drivers demand a certain version or miss features (or stability anyone) would be unworkable and a recipe for failure.
Distro's already package a certain version and all other components are compiled for that.
In the future maybe we could have a fairly stable x server api/abi.
Maybe this will be wayland or something else.
Until then, changes and having to take them into account are a fact of life.
I applaud the use of driver compat code for various server versions. It is the most reliable, flexible, most bang for the work put into it and compatible approach.
That's what always should be done.
(Or in the long run, even better would be a standard but first let things evolve because it's needed.)
Last edited by plonoma; 09-16-2011 at 06:11 AM.
Drivers belong in operating system kernel.
Regardless of type.
If you move something out of kernel to application X , it will not be available for every other application, except those using X.
If this feature is only valuable to application X, then it should be moved to application X.
Wayland is upcoming. Moving gfx drivers into xorg will mean wayland will have to copy-paste or start from scratch.
Something actually done is valued MUCH more than useless speculations about AIR.
The people who test the drivers will continue to do so after this change - the difference for most folk is xorg-server will be updated too (I'm taking about the PPA folk) for the folk like me who deals directly with Git - it might be a bit of a pain to set up but it won't be the end of the world
With cherry picking to old xorg versions there's no reason why new hardware couldn't be added or bug fixes either for that matter
This change will not affect Wayland what so ever - Wayland doesn't use the DDX driver only the DRM kernel stuff and Mesa
Also unless we're willing to contribute we can't really dictate how development should take place
We're all happy with the stripping of the old code from the Intel DDX. We're mostly happy with the removal of the drivers and the general clean-up of mesa. Why don't we just trust the dev's to do what's best for the code.
Each driver will only have to work with with the current xorg-server which will massively reduce the number of combinations to test down to 1
This WILL give us better drivers in the long run