Lol, sounds like the biggest house cleaning in the linux graphics ecosystem should start with the personnel involved with it before tackling any code.
Announcement
Collapse
No announcement yet.
Cleaning Up The Linux Graphics Driver Stack
Collapse
X
-
Originally posted by airlied View Postunichrome not a fork? seriously? you wrote it all from scratch?
I musta missed that bit.
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.
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
-
Originally posted by Ex-Cyber View PostIs is somehow unwholesome to "ogle" FLOSS code? I thought that was kind of the point.
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
-
Originally posted by jbarnes View PostAnother 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.
Comment
-
Originally posted by libv View PostWhat 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.
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
-
Originally posted by libv View PostUnichrome 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.
Originally posted by libv View PostOpenchrome 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.
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 PostYou 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.
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:
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?
Dave.
Comment
-
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.
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
-
Originally posted by jbarnes View PostBut 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
Comment