[Mesa3d-dev] DRI SDK and modularized drivers.

[Luc Verhaegen]

On Thu, Mar 18, 2010 at 01:28:28AM -0700, Corbin Simpson wrote:
> On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen <libv at skynet.be> wrote:
> > On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote:
> >> Modularized dri drivers and an SDK enabled mesa tree are available in my
> >> personal git repos at http://cgit.freedesktop.org/~libv/
> >>
> >> The SDK enabled mesa tree adds to the mesa build system to create shared
> >> libraries libmesadri and libmesadricommon. It creates the relevant .pc
> >> files and installs the necessary headers include/mesa/ (and updates
> >> glcore.h). The patch is about 300 lines each time, and only adjusts the
> >> build system.
> >>
> >> The modularized drivers are fully autotooled and can be built and
> >> installed the familiar way once the dependencies are available
> >> (currently, libdrm and the dri sdk, and some driver specific libdrms for
> >> i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64,
> >> mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx
> >> and unichrome.
> >>
> >> This work was done for currently 16 versions between mesa 7.0 and the
> >> freshly tagged 7.8-rc1, all were extensively and oft repeatedly built
> >> through. 5 versions were also run tested (glxinfo, glxgears) for the
> >> radeon and unichrome drivers, and the swrast driver was also tested
> >> several times. Such a large range of versions was handled to prove the
> >> long term feasability of this.
> >>
> >> This work satisfies my requirements from my "TODO: Mesa" slide from my
> >> fosdem talk, for which the slides are available at:
> >> http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$
> >>
> >> This only handles the DRI part of things, gallium seems to be more in
> >> flux atm, and from what i hear, it should be easier to have modular
> >> drivers there.
> >>
> >> Comments, additions, changes?
> >>
> >> Thanks,
> >>
> >> Luc Verhaegen.
> >
> > After giving the mesa3d-dev list the opportunity to have a whole day of
> > deafening silence, maybe the other lists should join in on that fun :p
> 
> Hey Luc,
> 
> Wow. This is pretty nifty. Lots of work here, obviously. I do have a
> couple of questions, though:
> 
> ~) Did you know about or use the automake branch that Eric and I have
> had floating around for a while?

Nope, didn't know about those, is this in your personal git repos?
 
> ~) Do you think it's gonna be tenable to ship the drivers with lots of
> shared code (i915/i965, radeon/r200/r300/r600) like this? Seems like
> we might run into the situation we've got right now with the X server
> and DDX drivers, where it might be easier to move some drivers back
> in. Also (warning: sore subject!) it reminds me of the mesa/drm tree
> and the same problems with keeping code in two locations... Maybe
> that's just me.

The goal is to solve the dependency nightmare between the driver 
specific drm, libdrm, mesa and x parts. The hot and highly volatile 
interfaces are between the driver specific parts, as of course, 
developers making changes there only have to update parts of their own 
driver.

So, identify the volatile interfaces, and the more stable interfaces, 
and then isolate the volatile ones, and then you come to only one 
conclusion.

And currently the really hot interfaces are in the intel and radeon 
stacks, and without making any changes, we are quickly converging to a 
situation where the linux kernel, libdrm, xserver and mesa are 1-1 
version tied. This means that if you update anything you pretty much 
have to update most of your installation, a situation no-one wants, and 
a situation which will be highly detrimental for the linux desktop.

It either leads to throw-away installations (where you have to be lucky, 
or need to have especially backported bits, like in preloads, to be able 
to get things to work), or no graphics at all. And i am sure that that 
is not where linux should be headed, especially not when it can be 
solved this neatly and cleanly.

> As far as Gallium goes, I really wouldn't worry about it. From what I
> can tell, the people that actually care about header stability have
> been using really specific versions of the interface in their own
> shipped bundles, and there's far too much mainline work going on right
> now to really even attempt this kind of splitting. I think there's a
> total of five branches right now that will change the entire Gallium
> interface, all getting prepared for merge? Lots of churn. Gallium's
> all mix'n'match though, so it shouldn't be a big deal further down the
> road.

While it probably is not that feasible right now, the people moving 
those interfaces that much atm should keep future modularization in 
mind.

A nice example: If you disable building gallium (as all the drivers are 
still in there) and building the dri drivers (also through configure), 
then you can easily build mesa with libdrm 2.3.0. The xserver, with 
already modular xf86 drivers has exactly libdrm 2.3.0 in its 
configure.ac requirements. Surely this is a sign that modularizing the 
driver bits and posssibly (as it is all up to the driver devs then, 
while there is no such freedom of choice now) bring those bits closer 
together in a more unified stack. There are several more examples like 
this.

Thanks,

Luc Verhaegen.