Cleaning Up The Linux Graphics Driver Stack

[bugmenot]

Will the video of this be freely available? (as opposed to just premium members - I am not sure how the videos work on here as there does not seem to be any tab on the site)

and if so, any idea how long it would take?

Either way, keep up with the good work with this site - it keeps me and many others well informed.

Thanks.

[Michael]

If you want an Xorg that is easy to build then the JHBuild is fairly awesome: http://www.x.org/wiki/JhBuildInstructions. I do a full git head checkout and build every couple of days without much issue other than an occasional bad patch.

Daniel said during Luc's talk that the JHBuild should be broken and not used.

[Firebird347]

I beg to differ, Luc! I just did a couple days ago... but it was a pain. Is there a document somewhere that tracks which versions of modules are compatible?

The autoconf scripts tend to take care of minimum versions, but when you want to build an older xorg-server so you can use the catalyst drivers, it's useful to know the maximums...

If you want an Xorg that is easy to build then the JHBuild is fairly awesome: http://www.x.org/wiki/JhBuildInstructions. I do a full git head checkout and build every couple of days without much issue other than an occasional bad patch.

[libv]

Are you going to propose such changes on the mesa3d-dev list?

Yes, i am working out some further details and a further proof of concept right now, and hope to have something presentable by the end of the week.

[MrCooper]

With a few changes in mostly the mesa repo, [...]

Are you going to propose such changes on the mesa3d-dev list?

[jbarnes]

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.

I suppose that's possible. But I used to be in your camp on this; when X was split I thought splitting Mesa would be a good idea too. Now that I've worked with things for awhile though, I've come to the conclusion that we've gone too far. Drivers should be more tightly coupled with the core they interact with, since updating driver APIs is often necessary to increase performance, add features and sometimes even fix bugs. If the drivers are separate, that means keeping around a lot of compat code, increasing the number of combinations we need to support and generally making things less stable.

But that's just my opinion right now, in time maybe other approaches will become more feasible.

[libv]

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 later learned that you had blown up over this via-via. Similarly i learned that you made one of your blown-up statements when the layoffs at SUSE Nue happened.

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.

The fact that you had issues with vm86 and therefor wanted to disable this are all good reasons, and i am sure that you would've had people agree with you soon when you proposed it somewhere public.

My question was: "Where was this discussed?". Egbert had just spent some time fixing up vm86 with NX kernel support, and here that code was just labeled deprecated out of the blue. So, my very honest, direct, and perfectly reasonable question was: "where was this discussed?".

We, and a lot of people with us, both know you made a big stink about me asking you this. And the reason for that is purely that this question exposed the wrong mode of working. A mode of working that is supposedly no longer possible today.

[libv]

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.

Of course you do not remember, you were nowhere near xfree86 at the time. At the time you just were the only volunteer for becoming the drm maintainer, there is little other traffic from you on xfree86.

We had our driver build and run outside of both during the war. And when the dust settled, we were porting back released versions to the Xorg tree.

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 should ask the forkers that. I just refused to take in VBE based modesetting, with a lot of solid reasons as to why it should be refused. Remember, this was 2005, when even keithp was shooting everything modesetting down. And a year before you gave me crap over the too complicated output abstraction, and reinventing it for i2c based output chip driver modules, showing that you clearly missed the point already.

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.

KMS happened a year later. You did fork.

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.

Avivo was not supporting more hardware at the time of our driver release. It just was not dealing with wiring up connectors much, while we were. Until we finally managed to write up the code to parse the atombios data tables, we had to go and maintain a board layout table of our own.

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.

With RadeonHD we did just that, from the very moment that we were allowed to do so by AMD/ATI. We immediately created the #radeonhd channel and the mailinglist (we needed a mailinglist for this immediately, which upon first asking was blatantly refused by daniels), we worked with phoronix from that point on too. You copied that in the next few weeks, to little initial success.

Our community ended up producing a few very good results. Great example: You would not have had HDMI code at all today, if Christian Koenig hadn't done so for RadeonHD. Plus, he did so in a way that fully fused with the RadeonHD blockwise modularity concept, a concept even Alex couldn't grasp at the time according to Mr Bridgman.

So please, stop throwing useless crap that can be proven wrong immediately.

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.

If this logical shortcut had any real value, it would just tell people how important and crucial a developer i am :P

But it is not this logically simple.

Unichrome "died" in the same way openchrome "died". Nobody cares about this hw much anymore. Difference between me and openchrome is that the openchrome people don't do much in the way of active development even when they are around.

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.

You never understood this community thing either. You copied this from radeonhd in september/oktober and beyond, and had a hard time coping after that too.

Now, if both you and alex would give up right now, the activity levels on ati related topics would die down to radeonhds (which still sees some activity) straight away.

Nobody else is doing the boring stuff.

This is actually exacerbated by the fact that Mr Bridgman is not making real hw information available anymore. Nobody could fix up current code if this source of information dries up, let alone continue work.

We specifically demanded that when we wrote our proposal to AMD, one of many reasons for providing documentation is that companies and people could continue, when for whatever reason, the information stream died out. This also benefitted AMD, as it would help give people confidence in the long term usability of their hardware.

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.

This i will never deny. Novell is a bank, and it tries to squeeze blood from the diamond that once was SUSE. That's not SUSE's fault, and a lot of SUSE people try to do the best they can under these circumstances.

But redhat is not trying to sell the linux desktop at all. It is just using its money to make big statements and then forces the others to make a working product out of the proof of concepts and pipedreams, wasting a lot of resources in the process. I must admit, it's a very clever tactic.

[libv]

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.

[nwnk]

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.