Announcement

Collapse
No announcement yet.

Cleaning Up The Linux Graphics Driver Stack

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Lol, sounds like the biggest house cleaning in the linux graphics ecosystem should start with the personnel involved with it before tackling any code.

    Comment


    • #22
      Originally posted by airlied View Post
      unichrome not a fork? seriously? you wrote it all from scratch?

      I musta missed that bit.
      Unichrome is the xfree86 via driver, it was taken outside of the xfree86 project because of the Xorg/Xfree86 war that completely crippled development. I got the two other active developers of this project together and then created unichrome. When Xorg versus Xfree86 stabilised, we took unichrome stable releases into the then still monolithic Xorg tree.

      Openchrome forked away much later; my focus was rightfully modesetting, the openchrome people wanted to play with Xv and MPEG encoding. This was years before people like you even wanted to be associated with modesetting. Openchrome today has 3 ways of setting a mode; old-style (before the fork), new-style (ogled unichrome a lot), and VBE: none of which completely stable and there is a switch statement and a config option somewhere to decide which to use. It seems that my strong stance on modesetting was absolutely justified.

      In any case, unichrome can hardly be described as a fork. We "forked" from the VIA people when they handed us the code and who then continued their own in-house development, while everyone worked hard on making the public code in the xfree86 repository useful. And when I took unichrome out of xfree86, I had all the developers of the via driver along. That is hardly a fork, that's a reorganisation.


      So radeonhd was a good idea now? the community you built up around it like unichrome seems to have sustained it well when Novell decided development of it wasn't going to give them any advantage over anyone else.

      Dave.
      RadeonHD was a great idea. We started writing up code late July 2007, on modesetting stuff, and since this part was completely different from everything before, we were not allowed by AMD to talk to anyone until their big press release, and we did not want to destabilize the existing radeon driver even further; we took the right decision to start a separate X.org driver (of which modesetting is always the bulk of the code anyway).

      You were one of the people who forked away later, much, much later. November 2007 to be exact. While you tried to write from scratch (ogling radeonhd all the time, as we did find out lots of things that ATI was unwilling or unable to tell us): you first even added the radeonhd copyright holders on some files afterwards, as you would've otherwise gotten in real big trouble. You removed some of these later.

      A nice example, today, still, you are using symbols in your driver which are preceded with RHD.

      For all intents and purposes, that can be described as a fork. The radeon r500+ code did not exactly help getting older hardware support stable, now did it? And i guess you never really managed to hit that "I can do modesetting in 1500 lines" statement you made on XDS Cambridge.

      RadeonHD development has pretty much stopped because:
      a) I got laid off from novell, due to massive budgetcuts and selection on the basis of "socialauswahl" under german laws. I got separated from the hardware, completely losing most of my ability to advance anything.
      b) due to the massive layoffs, the remaining people are now working their asses off to cope. Nobody sadly has enough time to devote to this project left.

      I find this all rather amusing how you are responding here. Why is your reaction this extreme all of a sudden? Did I say anything that puts you on shaky ground?

      It almost feels like that time when i asked Ajax where the decision to stop using VM86 in the Xorg tree was discussed. He had a huge blowup inside redhat internally, even though it was a very dry, normal and actually very succinct question. I guess it exposed a real issue with how Ajax was working there, as otherwise such an extreme reaction could not be explained. Many months later, and we have patch review on the xserver.

      Comment


      • #23
        Originally posted by libv View Post
        ogled unichrome a lot
        Originally posted by libv View Post
        ogling radeonhd all the time
        Is is somehow unwholesome to "ogle" FLOSS code? I thought that was kind of the point.

        Comment


        • #24
          Originally posted by Ex-Cyber View Post
          Is is somehow unwholesome to "ogle" FLOSS code? I thought that was kind of the point.
          Not in itself. But first dishing out unholy amounts of crap at the original code and the original authors, and then depending _as_ much on that original code: taking both its fixes and many ideas; that is not that nice a way of working.

          And this happened in both cases. And in the second case, one of the people doing so is now calling the code he forked from forks. Pot, kettle, etc...

          There is a lot of history here, and a lot of it is just extremely childish when looked at from outside, or if you take a momentary snapshot. But if you look at the technical side of things, and combine this with history, and when you start to see what happened when by whom, then certain modes of operation by certain people become clear.

          Feel free to also find out my MOO, you'll find that it is a lot less bad as some like to make it appear.

          Comment


          • #25
            Originally posted by libv View Post
            There is a lot of history here, and a lot of it is just extremely childish when looked at from outside, or if you take a momentary snapshot.
            You're not wrong. What a great advertisement for X this is.

            Comment


            • #26
              Originally posted by jbarnes View Post
              Another mis-characterization. I'm really sorry I missed this session. We work hard on stability and robustness; if you look back at our release notes you'll see quite a focus on that especially recently. And yes, we also add features desired by our users and customers, and do performance work required to make new features work. It's not an either/or proposition, we have users demanding all three.
              What i suggested in my talk was not binary either. With a few changes in mostly the mesa repo, graphics driver developers will be free to choose how they handle the constant stability, basic functionality, features and performance balancing act.

              Comment


              • #27
                Originally posted by libv View Post
                What i suggested in my talk was not binary either. With a few changes in mostly the mesa repo, graphics driver developers will be free to choose how they handle the constant stability, basic functionality, features and performance balancing act.
                But it sounds like you want to do that by separating even more modules and creating stable ABI between them (again, sorry I missed the talk, sounds like it was quite an event)?

                IMO, we've split things too much already. Modular X was great to get the libraries and server split, but we never should have split the drivers out, since that makes fixing the acceleration and other driver APIs like DRI2 much harder than it needs to be. So rather than making Mesa more like X, I'd say we should make X more like Mesa, and pull the drivers back in.

                Comment


                • #28
                  Originally posted by libv View Post
                  Unichrome is the xfree86 via driver, it was taken outside of the xfree86 project because of the Xorg/Xfree86 war that completely crippled development. I got the two other active developers of this project together and then created unichrome. When Xorg versus Xfree86 stabilised, we took unichrome stable releases into the then still monolithic Xorg tree.
                  So a fork by any other name is? oh its a fork. I'm not sure the X.org split changed the XFree86 development model at all, I don't remember seeing XFree86 bugs with patches to their VIA driver bringing it up to speed with the unichrome changes.


                  Originally posted by libv View Post
                  Openchrome forked away much later; my focus was rightfully modesetting, the openchrome people wanted to play with Xv and MPEG encoding. This was years before people like you even wanted to be associated with modesetting. Openchrome today has 3 ways of setting a mode; old-style (before the fork), new-style (ogled unichrome a lot), and VBE: none of which completely stable and there is a switch statement and a config option somewhere to decide which to use. It seems that my strong stance on modesetting was absolutely justified.
                  And there was no way you could work with anyone else in the same tree?
                  even though the featureset was othogonal, now let me guess the problem was with the people trying to contribute not with you? We've somehow managed in every other driver developed to do both modesetting and acceleration work at the same time in the same codebase. Now what makes unichrome special?


                  Originally posted by libv View Post
                  You were one of the people who forked away later, much, much later. November 2007 to be exact. While you tried to write from scratch (ogling radeonhd all the time, as we did find out lots of things that ATI was unwilling or unable to tell us): you first even added the radeonhd copyright holders on some files afterwards, as you would've otherwise gotten in real big trouble. You removed some of these later.
                  Code reuse to save time was necessary, later review revealed most of that code was pointless, we still haven't gotten around to removing it all, but there was a number of pointless abstraction layers. The KMS code pretty much removes all of them, so I don't see the need to destabilise or cleanup the dead end that is DDX modesetting at this point.


                  For all intents and purposes, that can be described as a fork. The radeon r500+ code did not exactly help getting older hardware support stable, now did it? And i guess you never really managed to hit that "I can do modesetting in 1500 lines" statement you made on XDS Cambridge.
                  Well avivo was pretty much that, and supported more hw at the time than your first release. It actually helped us reorganise a lot of the -ati code and it really helped with getting r4xx stable as we only have reverse engineered atombios support up to that point.

                  RadeonHD development has pretty much stopped because:
                  you haven't really got the point, which is where are the communities that you are meant to build up around open source projects to stop them dying when companies pull people out because of their questionable reasons for being involved in the first place.

                  Unichrome stopped dead when you moved to work on RHD, and RHD has pretty much stopped dead since you went the other way and Novell people got re-routed. I don't think -ati or KMS would stop because I decided to do something different and similar for Alex or Jerome or Corbin or anyone else. The thing is to create a sustainable open source driver you need to create a community of developers and testers around it and for some reasons projects involving you this doesn't seem to happen.

                  Also didn't you say KMS would never work.

                  I find this all rather amusing how you are responding here. Why is your reaction this extreme all of a sudden? Did I say anything that puts you on shaky ground?
                  Actually I was just trolling because it was raining outside, Red Hat has a business model apparently that works, I'm not sure of the details but money seems to come out at the end.

                  Dave.

                  Comment


                  • #29
                    It almost feels like that time when i asked Ajax where the decision to stop using VM86 in the Xorg tree was discussed. He had a huge blowup inside redhat internally, even though it was a very dry, normal and actually very succinct question. I guess it exposed a real issue with how Ajax was working there, as otherwise such an extreme reaction could not be explained. Many months later, and we have patch review on the xserver.
                    That's a nice theory, but it's, uh, divorced from reality.

                    The thread, for those who didn't read it, was here. I'm not sure where in that you're inferring anything like a "huge blowup" or "extreme reaction". It's a verbose response, but I figured it was worth giving the long form answer for posterity.

                    I'd been fighting vm86 bugs intermittently at Red Hat since even before RHEL5 came out, starting with:

                    * Fri Nov 3 2006 Adam Jackson <[email protected]> 1.1.1-48.2.el5
                    - Build both x86emu and vm86 backends on x86. Prefer x86emu when running
                    in Xen dom0. Add "Int10Backend" option to the ServerLayout section to
                    allow runtime configuration. (#213151)


                    ... a trick I am not especially proud of. The only reason we didn't switch to x86emu completely in RHEL5 was because vm86 was the tested path from the dawn of time, so it was at least a known quantity; switching could have introduced new bugs, and this is RHEL, so we're paranoid. But Fedora switched to x86emu everywhere literally five days later. Three, if you don't count the weekend.

                    Now, having shipped that for twenty-four months, I felt pretty confident it was correct, so I committed the default switch upstream so I could drop a configure option from the spec file. You rightly called me out for not justifying it fully in the commit, though at that point I didn't really think "do the obviously correct thing" needed a lot of justification. But claiming the change (or the explanatory email) was the result of some internal strife is just fiction. The reality is that for two years I was the only person at Red Hat even remotely looking at the vm86 problem, let alone caring about it.

                    I do find it amusing how you interpret everything as a conspiracy with backroom dealings and dirty secrets though. It's like every time you see hoofprints you think Illuminati unicorns instead of horses.

                    Comment


                    • #30
                      Originally posted by jbarnes View Post
                      But it sounds like you want to do that by separating even more modules and creating stable ABI between them (again, sorry I missed the talk, sounds like it was quite an event)?

                      IMO, we've split things too much already. Modular X was great to get the libraries and server split, but we never should have split the drivers out, since that makes fixing the acceleration and other driver APIs like DRI2 much harder than it needs to be. So rather than making Mesa more like X, I'd say we should make X more like Mesa, and pull the drivers back in.
                      I knew that people would be spewing a lot of useless flack over this, and i also knew that you would be one of the more reasonable people. You do not have to outright believe me, i do not expect that, but i think that, in time, you will agree on many things stated/proposed in this talk.

                      Comment

                      Working...
                      X