Luc Modularizes Mesa, DRI Drivers

[tapir]

Thank you luc.

From the diagrams on your fosdem slides it's obvious -even for a non-programmer like myself- that the linux graphics stack can use some improvements, and it's great to see someone doing something about it.

[libv]

You never asked about the license. The -radeon guys did, and we agreed to license the bit of code they asked for under MIT/X11.

As said, we were not allowed to talk to anyone about this. We even had a major incident where one of the SUSE guys posted a news item over ATIs plans in late august, and in the end that turned out to be a leak from inside AMD/ATI. Heck, if Michael hadn't posted his article ahead of the latest schedule change (as no-one informed him about the change in plans), we might still be waiting for that announcement.

And it has to be said, I am not too certain how you would have responded when asked in July 2007 by the SUSE people, before the big event, as opposed to afterwards, when asked by Redhat and ATI.

[daniels]

RadeonHD started afresh late july 2007. We were not at liberty to discuss anything with the outside world (while those who imposed that limitation on us happily did so all the time).

We discussed basing our work on top of avivo, but avivo was GPL-ed, and we were unable to get that to change (and i am not sure whether, at the time, you would have at all been willing to change that when we came a-knocking). Avivo did relatively little as well, so we soon progressed to a point where we overshot avivo functionality (not hard when spending worktime on it and when the hardware is available).

GPL was the main reason why avivo became just one of many levers that made AMD decide to open source things. But it was a more significant one than some other people thought they were (judging from the claims they made shortly after the announcements/releases from september 2007).

You never asked about the license. The -radeon guys did, and we agreed to license the bit of code they asked for under MIT/X11.

[libv]

Great job Luc!! Everyone's making fantastic progress but I hope it gets further along to provide a nice soft warm place for windows converts to land. Everyone was trying to jump ship in the fedora 10/ubuntu 9.04 days. Let's just hope this gets done well on this next round of releases as it will mean millions of users. I'm already seeing large groups of linux users on the net which is unheard of 2 years ago.

Well, it is not just about windows users. It will also lure more people away from closed source drivers, as those closed source drivers are simply easier to procure and install. And, it will also make it easier for those who have used open source drivers before, who before were forced to update part of their installation or just dist-upgrade.

Imagine how many more people will be installing, testing and using the latest graphics driver bits when this process is made easy.

[libv]

'API' implies some vague sort of design. $(includedir)/xorg is many things, but not designed. The idea is to basically incrementally create useful APIs that everyone can use without too much pain. You should know this, having written a Screen(Pre)Init before ...

Again, what does one gain from moving drivers back into the xserver that one doesn't gain from a tinderbox? I do not see it.

Current slightly more distributed model does not impede such things either, it just is a slight bit more hassle, and therefor (and only therefor) requires the developer to think a bit further about the changes he is about to make (although it hasn't stopped anyone from breaking things horribly in the past).

My analysis: people just do not want to do this tiny bit of extra thinking.

[libv]

Tell me the story of radeonhd again? :P

RadeonHD started afresh late july 2007. We were not at liberty to discuss anything with the outside world (while those who imposed that limitation on us happily did so all the time).

We discussed basing our work on top of avivo, but avivo was GPL-ed, and we were unable to get that to change (and i am not sure whether, at the time, you would have at all been willing to change that when we came a-knocking). Avivo did relatively little as well, so we soon progressed to a point where we overshot avivo functionality (not hard when spending worktime on it and when the hardware is available).

GPL was the main reason why avivo became just one of many levers that made AMD decide to open source things. But it was a more significant one than some other people thought they were (judging from the claims they made shortly after the announcements/releases from september 2007).

We figured that graphics drivers were probably going to be able to work out -retro, or have an alias or something. I admit it's not ideal though; we could do something like display the root weave in everything but RC/stable tarballs?

Yeah, that sounds like a plan. Although i still do not understand why the root weave had to go to begin with. It is all about delaying the unblanking of the displays, and it shouldn't be impossible to delay thsi unblanking a bit further than is/was the case.

If nothing is running on top, you then get a rootweave. If anything is running on top, you get to see what it is, without seeing the rootweave or the crapped up/old framebuffer content in between.

[Hephasteus]

Great job Luc!! Everyone's making fantastic progress but I hope it gets further along to provide a nice soft warm place for windows converts to land. Everyone was trying to jump ship in the fedora 10/ubuntu 9.04 days. Let's just hope this gets done well on this next round of releases as it will mean millions of users. I'm already seeing large groups of linux users on the net which is unheard of 2 years ago.

[daniels]

Moving drivers back into the X server is the single worst thing that people can do at this point.

Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.

'API' implies some vague sort of design. $(includedir)/xorg is many things, but not designed. The idea is to basically incrementally create useful APIs that everyone can use without too much pain. You should know this, having written a Screen(Pre)Init before ...

[daniels]

Well, forking is not my style and something like that does not succeed on its own, especially not for technical reasons. Forks are mostly only about politics and people trying to protect or enlarge their power-base outside of technical advancement.

About not liking something, and/or not liking the general direction of things, and then coding up how they should be... I have done that many times before. And several of those have turned out to be real winners, even though the people who get proven wrong in such a case, are usually not very sportive about it. This means that credit is then not given where credit is due, and this is where the whole meritocracy thing breaks down, as the next time round, the same story has to be played all over again, in pretty much the same way, with a sizable waste of resources as a consequence.

Tell me the story of radeonhd again? :P

About ctrl-alt-bcksp... I miss that too (i know, it's only off per default). It's like the X stipple and the VGA text console. When you see the stipple, you know that your driver code is not horribly broken. When it is horribly broken, you might still have ctrl-alt-backspace, which then hopefully gives you the VGA console again. If you see the VGA console again, you get to play again... All 3 are happily tied together for a graphics driver developer

We figured that graphics drivers were probably going to be able to work out -retro, or have an alias or something. I admit it's not ideal though; we could do something like display the root weave in everything but RC/stable tarballs?

[libv]

at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

I am still working on a README, and will make more noise once i have had some shut-eye.

For the adventurous, here is the quick summary:
* pick versions that are very close to your current mesa version (libGL needs to match)
> ./autogen.sh [maybe want to add --prefix=/usr/]
> make dri-sdk
> make dri-sdk-install

Then you can build, install and run your dri driver.

README: http://people.freedesktop.org/~libv/dri-sdk.txt