Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: The Fight Over Merging Drivers Back Into X Server

  1. #1
    Join Date
    Jan 2007
    Posts
    14,645

    Default The Fight Over Merging Drivers Back Into X Server

    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...

    http://www.phoronix.com/vr.php?view=OTkxOQ

  2. #2
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    400

    Default

    bikeshedding?

  3. #3
    Join Date
    Feb 2011
    Posts
    55

    Default

    Code:
    bikeshedding?
    Not completely.

    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?

  4. #4
    Join Date
    Feb 2011
    Posts
    1,096

    Default

    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.

  5. #5
    Join Date
    Feb 2011
    Posts
    1,096

    Default

    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.

  6. #6
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,130

    Default

    Quote Originally Posted by TheBlackCat View Post
    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.
    That's not the problem, at least as I understand it. The problem is that the fast moving branches require API changes that need to be propagated back to the obsolete drivers, which has two drawbacks: (a) extra work for hardware noone is using, and (b) regressions that go unnoticed (again, since noone is using those drivers).

    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.

  7. #7
    Join Date
    Sep 2010
    Posts
    459

    Default

    I really don't see why it has to be like this.
    Drivers and core infrastructure should be separated.

    Let's take a look.

    Pros:
    1) easier to propagate API changes across drivers (just like Linux)
    1a) thus easier to change ABI
    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?
    Or have the necessary time to debug unforeseen things?
    Driver compat code for various versions allows easy to change api/abi.


    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)
    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.

    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 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.
    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.


    Cons:
    1) more work for distros to backport just driver changes to old servers (especially if people follow through on (3) above)
    Don't underestimate that, especially the testing for unavailable hardware.

    1a) if backporting is harder, new hardware support will be more difficult to land in "enterprise" level distros
    Which means smaller use, which means less people interested in getting it to work. (Critical mass harder to achieve.)

    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
    Not only that but sometimes other components depend on a specific server version.
    This causes stuff not to work any more if you use another one.
    Thus becomes unusable.

    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 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.


    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.

  8. #8
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    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.

  9. #9
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    575

    Default

    Quote Originally Posted by crazycheese View Post
    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.
    That's so unbelievably wrong

  10. #10
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    575

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •