Cleaning Up The Linux Graphics Driver Stack

[airlied]

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.

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?

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.

[jbarnes]

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.

[libv]

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.

[daniels]

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.

[libv]

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.

[Ex-Cyber]

ogled unichrome a lot

ogling radeonhd all the time

Is is somehow unwholesome to "ogle" FLOSS code? I thought that was kind of the point.

[libv]

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.

[deanjo]

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

[airlied]

I am never the one who forks, and i am always the one who ends up getting proven right in the end.

Maybe, just maybe, i am the one who see things way before others even want to consider the same things.

unichrome not a fork? seriously? you wrote it all from scratch?

I musta missed that bit.

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.

[libv]

Unichrome doesn't have a kernel drm or mesa driver component.

Shipping drivers and expecting your users to enable the functionality they want with an xorg.conf is also fail, (radeonhd might have DRI enabled now).

This talk held nothing of interest really. *yawn*.

Intel ship releases every quarter with the recommended components are tested together, this stuff doesn't need to be in one tree, shipping out of tree kernel modules is also fail.

Dave.

Thank you for being right within my expectation.