Log in

No account? Create an account
The DRI SDK and modular DRI drivers. - LIBV Intentionally Breaks Videodrivers [entries|archive|friends|userinfo]
Luc Verhaegen

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

The DRI SDK and modular DRI drivers. [Mar. 17th, 2010|01:31 am]
Luc Verhaegen
[Tags|, , , , , , , , , , ]
[Current Location |couch]
[mood |accomplished]
[music |Kinobe - Slip into something more comfortable.]

At FOSDEM I held a talk about "The free software graphics driver stack", analyzing the structure and the distribution of the different parts of the graphics driver stack, and, based on clear requirements, proposing a re-organization to be able to bring the individual parts of the graphics driver stack together. The slides for that talk are available here, and the audio and video of this talk have been made available too (Thanks Michael!).

Since I do not like to talk thin air, i also made a fully unified unichrome graphics driver stack available, proving that it is possible to unite all of Xorg, DRM and DRI drivers in one tree, and that it is possible to provide a reasonable amount of backwards compatibility (trivial for a stagnated driver) even in the Mesa/DRI driver.

My slides have a TODO section, and the most significant of those TODOs was for Mesa. This listed providing shared libraries, pkgconfig files and the necessary headerfiles for Mesa, much like the SDK that X has had ever since xfree86 4.0.0. Of course, such a thing would not happen on its own, so a bit after FOSDEM I set off and now I have implemented just that.

You can find the SDK enabled Mesa DRI tree here, and the individual drivers can also be found in my personal git repositories. A README like document is available too, to explain what one should do to build and install the SDK and to build and install the drivers.

What this gets you, once the SDK is properly installed, is the ability to build and install just the DRI driver to be able to fix bugs, get some performance gains, or just provide the driver developers with good feedback (provided that someone updated the driver tree to the latest compatible changes that is ;)). This without having to replace your libGL, which is where all the dependencies come weighing in. Anyone who has had to update this so far, knows how painful such an update is, and that it is often easier to do a major distribution upgrade.

So this brings us another step closer to make the free software desktop happen: the ability to easily update our graphics driver stack without touching anything else in our system!

From: (Anonymous)
2010-03-17 01:19 am (UTC)


Sounds great in concept, one package providing everything you need to support a particular piece of hardware...

However if I understand correctly, you're also talking about pulling the kernel components out into those packages - and from my experience of running the nVidia binaries and the old madwifi wireless drivers, having kernel modules built separately from the kernel is an absolute pain in the ass. Having the ath5k enter the kernel was a big plus, and is likewise one of the things I'm looking forward to with Nouveau becoming mature enough to use.
(Reply) (Thread)
[User Picture]From: libv
2010-03-17 01:34 am (UTC)

Re: Question...

Well, the beauty of providing the infrastructure to allow that is; it's up to the driver developers to decide how to deal with their own driver stack. They can have a lot of compatibility to the outside and keep the driver bits tightly dependent, or they can have a lot of compatibility internally and little externally, or anywhere in between. It can be a fully unified tree with no parts external, it can be a fully dispersed tree.

Where this balance lies can then be decided between users, distributors, hardware vendor and developers, each pulling in their preferred direction. And this is exactly what is missing today, and exactly what i am going in against here too. Some driver developers too easily label things as "impossible", for other reasons than it actually being impossible.

As a user, what you want is fully working graphics drivers from the second that you have installed your distribution. We all know that this doesn't and will not happen. So we need the second best thing, which is the ability to easily update the graphics driver bits.

Could it be that your ath5k was also not readily installable from your distribution, and that you had to build/package it yourself?

What would it be like to just use your package manager to update your graphics driver to a newer version when you, indefinitely, run into issues, without having to change anything else in your distribution? Wouldn't that make you as close to a happy camper as you can get when your hardware isn't fully working out of the box?
(Reply) (Parent) (Thread)
From: (Anonymous)
2010-03-17 02:41 am (UTC)

Re: Question...

Granted, I'm an unusual case, an LFS user running a system built entirely from upstream sources. But the same is true of a regular distro user who wants to use a custom kernel - or yes, if you have third-party modules (or versions thereof) that aren't available in a distro. Out-of-tree drivers are a pain in the ass.

From my point of view, the ideal case is that the kernel pieces stay in the kernel tree, and present a stable enough interface that the remaining userspace parts can be packaged as you propose. I install standard XOrg, Mesa, libdrm packages, and a single package for all Nouveau userspace. And build a kernel with the necessary module to support the Nouveau userspace. If I upgrade the kernel, I don't want to have to reinstall any other package, just to get X to start up again...

Now, granted that's an ideal, but I don't think it's an unreasonable goal? Or is the kernel/userspace boundary too brittle for that to work?
(Reply) (Parent) (Thread)
[User Picture]From: libv
2010-03-17 02:54 am (UTC)

Re: Question...

It is way too brittle.

The main cause is of course that graphics drivers are like the graphics hardware; hugely complex and build to compete on raw performance and features. Drivers therefor are constantly moving and always buggy.

Then there is the mindset of certain developers that makes this even worse. This makes it so that linus has to go and shout at people at least once per month. This will not change, and nouveau is probably the best example of brittle interfaces.
(Reply) (Parent) (Thread)
From: (Anonymous)
2010-03-17 08:37 pm (UTC)

Re: Question...

nouveau is probably the best example of brittle interfaces

Certainly, but then, that's only to be expected at this stage of development - without the impetus of having their code enter the kernel, they've never needed to think in terms of stable interfaces until recently.

The same is also true of the more mature (relatively speaking) drivers, then?
(Reply) (Parent) (Thread)
[User Picture]From: libv
2010-03-18 01:16 am (UTC)

Re: Question...

Sadly yes, although not the exact same extent.

I personally fear that soon we will tie kernel, xserver, mesa, and libdrm versions together 1-1. In the long run, this means that the free software desktop turns into a 1-time install/throwaway operating system that no-one will update and that people will only put together for specific hardware.
(Reply) (Parent) (Thread)
From: (Anonymous)
2010-03-17 03:44 am (UTC)
so, i would have to build the driver + the sdk seperate instead in one package and keep track of yet another package dependency (which is changing for sure with all the mesa development going on)? this looks really backwards to me ... or i'm missing something obvious ..
(Reply) (Thread)
[User Picture]From: libv
2010-03-17 03:59 am (UTC)
(and yet another anonymous post)

The dependency issue is relative.

Yes, at this point it introduces another dependency, as it splits something up where there is a very logical boundary.

This split up, however, holds the potential to clear up a rather more sizable dependency nightmare, namely the dependencies between the different parts of the same driver stack. The in-driver APIs are far more volatile than the multiple-driver APIs found in mesa, the xserver, libdrm or the drm kernel parts, and are the major source of headaches at this time.

The general philosophy here is: Split up at a more logical boundary, to be able to unify what clearly belongs together.
(Reply) (Parent) (Thread)
From: ext_228656
2010-03-22 08:59 am (UTC)

Will it go upstream?

Does this change have possibilities to go upstream? It's it being discussed over there or it's just an idea?
(Reply) (Thread)