Re: [Mesa3d-dev] DRI SDK and modularized drivers.

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc Verhaegen]

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

Luc Verhaegen.
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Corbin Simpson]

On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen <libv@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?

~) 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.

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.

Sorry for not speaking up sooner; it's finals week and my attention to
every single email in my box is rather limited. :3

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude@gmail.com>
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [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@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.
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Nicolai Haehnle]

On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <libv@skynet.be> wrote:
> So, identify the volatile interfaces, and the more stable interfaces,
> and then isolate the volatile ones, and then you come to only one
> conclusion.

Except that the Mesa core <-> classic driver interface also wants to
change from time to time in non-trivial ways, and trying to force a
separation there on people who don't want an additional set of
compatibility issues to deal with is not exactly a friendly move.

It may seem e.g. like the DRM interface is the worst because of rather
large threads caused by certain kernel developer's problems, but that
doesn't mean problems wouldn't be created by splitting other areas. In
particular, the Mesa core <-> classic driver split only makes sense if
there are enough people who are actually working on those drivers who
would support the split. Otherwise, this is bound to lead straight
into hell.

In a way, the kernel people got it right: put all the drivers in one
repository, and make building the whole package and having parallel
installations trivial. The (only?) issues with that in X.org are that:
1) there is a cultural aversion due to the bad experience with the
horrible pre-modularization setup, and
2) it wouldn't actually solve the DRM problems, because we want to
have the DRM in our codebase, and the kernel people want to have it in
theirs.

cu,
Nicolai
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

RE: [Mesa3d-dev] DRI SDK and modularized drivers.

[Bridgman, John]

Pulling drm back out of the kernel tree seems like a hard sell, but the ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for grouping. 

I guess the core question is whether we expect the X-to-ddx and mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of years. 

On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, and on the libdrm interface side we have ongoing improvements in memory management and command submission. Tough call.

I guess another option would be a "pseudo-modular" approach where the code stays in the current trees but we adopt versioning and build/test procedures which treat ddx/mesahw/libdrm as a single code base even if the code is still living in multiple projects. That might be an easy first step, but repartitioning the code does seem like a better long-term approach.

If the drm code were omitted from the proposal and we focused only on ddx/libdrm/mesahw would that help ?

-----Original Message-----
From: xorg-bounces@lists.freedesktop.org [mailto:xorg-bounces@lists.freedesktop.org] On Behalf Of Nicolai Haehnle
Sent: Friday, March 19, 2010 1:26 PM
To: Luc Verhaegen
Cc: dri-devel@lists.sourceforge.net; mesa3d-dev@lists.sourceforge.net; xorg@lists.freedesktop.org
Subject: Re: [Mesa3d-dev] DRI SDK and modularized drivers.

On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <libv@skynet.be> wrote:
> So, identify the volatile interfaces, and the more stable interfaces, 
> and then isolate the volatile ones, and then you come to only one 
> conclusion.

Except that the Mesa core <-> classic driver interface also wants to change from time to time in non-trivial ways, and trying to force a separation there on people who don't want an additional set of compatibility issues to deal with is not exactly a friendly move.

It may seem e.g. like the DRM interface is the worst because of rather large threads caused by certain kernel developer's problems, but that doesn't mean problems wouldn't be created by splitting other areas. In particular, the Mesa core <-> classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell.

In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel installations trivial. The (only?) issues with that in X.org are that:
1) there is a cultural aversion due to the bad experience with the horrible pre-modularization setup, and
2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs.

cu,
Nicolai
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg


_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: DRI SDK and modularized drivers.

[Luca Barbieri]

> It may seem e.g. like the DRM interface is the worst because of rather large threads caused by certain kernel developer's problems, but that doesn't mean problems wouldn't be created by splitting other areas.

This would probably be best solved by merging libdrm into the Linux kernel tree.
Ingo Molnar's rationale for having tools/perf in the kernel tree
applies even more in this case.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: DRI SDK and modularized drivers.

[Luc Verhaegen]

On Fri, Mar 19, 2010 at 12:44:39PM -0500, Bridgman, John wrote:
> Pulling drm back out of the kernel tree seems like a hard sell, but the ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for grouping. 
> 
> I guess the core question is whether we expect the X-to-ddx and mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of years. 
> 
> On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, and on the libdrm interface side we have ongoing improvements in memory management and command submission. Tough call.
> 
> I guess another option would be a "pseudo-modular" approach where the code stays in the current trees but we adopt versioning and build/test procedures which treat ddx/mesahw/libdrm as a single code base even if the code is still living in multiple projects. That might be an easy first step, but repartitioning the code does seem like a better long-term approach.
> 
> If the drm code were omitted from the proposal and we focused only on ddx/libdrm/mesahw would that help ?

Well, to continue down the same path: It doesn't really matter how 
driver developers want to scatter their own different driver bits around 
today. It should be up to them.

It shouldn't matter, but sadly it does (as you're forced to have them 
into the main trees).

If those developers are free to choose how they want to handle this, 
then it will quickly become clear for some what the best mode of working 
for them really is, as opposed to being forced to work one way.

Then there will be pressure from users, hw and distro vendors, who 
might like one or another way of working better. And i guess that this 
is what those reasoning against this are mostly afraid of. Ideas like 
this can no longer be swept under the carpet with "impossible".

Luc Verhaegen.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <libv@skynet.be> wrote:
>> So, identify the volatile interfaces, and the more stable interfaces,
>> and then isolate the volatile ones, and then you come to only one
>> conclusion.
> 
> Except that the Mesa core <-> classic driver interface also wants to
> change from time to time in non-trivial ways, and trying to force a
> separation there on people who don't want an additional set of
> compatibility issues to deal with is not exactly a friendly move.

I've been busy trying to get a release out the door, so I haven't looked
at these patches yet.  I won't have a chance to look at the patches
until at least late next week.  I also wasn't at FOSDEM, so I don't have
any of the background info.

If these patches try to enforce a "stable" interface between core Mesa
and the classic DRI drivers, we're not interested.  At all.  This has
been discussed and rejected many, many times before.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkujw1sACgkQX1gOwKyEAw/iSgCaA37aTDav/amZkxuxq89d+hJm
P1MAn0dy99VSRTivgUURnCR3klnH/PSt
=DrqD
-----END PGP SIGNATURE-----
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: DRI SDK and modularized drivers.

[Luc Verhaegen]

On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've been busy trying to get a release out the door, so I haven't looked
> at these patches yet.  I won't have a chance to look at the patches
> until at least late next week.  I also wasn't at FOSDEM, so I don't have
> any of the background info.

I've grouped the slides and the recordings at the top of my blog entry 
about this.

The patches themselves are actually copies of eachother, with minor 
differences to adjust for changes of the tree around it (there are 16 or 
so versions of the sdk done from 7.0 through 7.8). Any actual patch is 
small, and it is build system only.

> If these patches try to enforce a "stable" interface between core Mesa
> and the classic DRI drivers, we're not interested.  At all.  This has
> been discussed and rejected many, many times before.

Ah, prepossession.

Ask yourself, did the fact that xf86 video drivers were out of tree, 
ever stop anyone from _really_ bad api breakage stunts?

The difference with in-tree and out-of-tree here is that out-of-tree 
should, theoretically, lead to more prudent interface changes. This 
without having to enforce anything, it happens naturally.

Out of tree drivers never stop interface changes, they just make them a
tiny bit more involved, and therefor, hopefully, causes the person 
making those changes to consider his actions a bit better.

But as said in an earlier email, what you incur on overhead here you 
can easily make up in the driver internal interfaces. And then the other 
synergies come weighing in.

Luc Verhaegen.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luc Verhaegen wrote:
> On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote:
>>
>> I've been busy trying to get a release out the door, so I haven't looked
>> at these patches yet.  I won't have a chance to look at the patches
>> until at least late next week.  I also wasn't at FOSDEM, so I don't have
>> any of the background info.
> 
> I've grouped the slides and the recordings at the top of my blog entry 
> about this.
> 
> The patches themselves are actually copies of eachother, with minor 
> differences to adjust for changes of the tree around it (there are 16 or 
> so versions of the sdk done from 7.0 through 7.8). Any actual patch is 
> small, and it is build system only.
> 
>> If these patches try to enforce a "stable" interface between core Mesa
>> and the classic DRI drivers, we're not interested.  At all.  This has
>> been discussed and rejected many, many times before.
> 
> Ah, prepossession.
> 
> Ask yourself, did the fact that xf86 video drivers were out of tree, 
> ever stop anyone from _really_ bad api breakage stunts?

The difference, and I think this is significant, is that the
functionality provided by the xf86 video drivers through the X server
hasn't changed much in quite some time.  The amount of functionality
added in every single major release of Mesa which requires driver
changes is significant.  We're far enough behind the state of the GL
spec and the closed-source drivers that I don't really want anything
that will slow us down.

You can't aim a stable interface at a moving target.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkunq7sACgkQX1gOwKyEAw8dqwCfR9/JjfCecV0Q4Po4AdnJaTOE
QrQAoJu1+zMz5shOHrhmOSL+L2um190q
=+eep
-----END PGP SIGNATURE-----
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Octavio Rossell]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Nicolai Haehnle escribió:
> because we want to
> have the DRM in our codebase

Why?

-- 
  __________________________________________________________
 |   ,           ,                                          |
 |  /             \                                         |
 | ((__-^^-,-^^-__))    Octavio Rossell Tabet               |
 |  `-_---' `---_-'     octavio@gnu.org.ve                  |
 |   `--|o` 'o|--'      http://octavio.gnu.org.ve           |
 |      \  `  /         irc.radiognu.org #gnu               |
 |       .:  :.                                             |
 |       :o_o:          Huella: FC69 551B ECB9 62B0 D992    |
 |        "-"                   BE57 B551 2497 C78B 870A    |
 |__________________________________________________________|


[-- Attachment #2: octavio.vcf --]
[-- Type: text/x-vcard, Size: 127 bytes --]

begin:vcard
fn:Octavio Rossell
n:Rossell;Octavio
email;internet:octavio@gnu.org.ve
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 199 bytes --]

_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc Verhaegen]

On Fri, Mar 19, 2010 at 06:26:03PM +0100, Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <libv@skynet.be> wrote:
> > So, identify the volatile interfaces, and the more stable interfaces,
> > and then isolate the volatile ones, and then you come to only one
> > conclusion.
> 
> Except that the Mesa core <-> classic driver interface also wants to
> change from time to time in non-trivial ways, and trying to force a
> separation there on people who don't want an additional set of
> compatibility issues to deal with is not exactly a friendly move.

You have to see this in the global picture. Sure, now it adds one 
additional set of compatibility issues, but it allows for the removal 
or reduction of most of the compatibility issues we are actually hit by 
today; namely, those between the different driver specific bits.

Those driver specific bits are, by their very nature, a lot more 
volatile.

None of this work will stop interface changes, that's the last thing i 
or anyone else wants.

It will however incur a tiny bit more overhead when making interface 
changes between drivers stacks and the outside. But that in itself is 
already outdone by the ease of making driver stack internal changes 
(where more of the pain exists now).

The other advantages are all net gains.

> It may seem e.g. like the DRM interface is the worst because of rather
> large threads caused by certain kernel developer's problems, but that
> doesn't mean problems wouldn't be created by splitting other areas.

Check the timestamps on my unichrome code: most of that work was done in 
november. And it's based on ideas that have been brewing since when i 
still was at suse (as suse, a company trying to sell service around the 
linux desktop, suffers from the current layout).

So it had nothing to do with the nouveau spat at lkml recently. This 
little shouting match is just another symptom that shows that something 
is wrong with the current setup.

> In
> particular, the Mesa core <-> classic driver split only makes sense if
> there are enough people who are actually working on those drivers who
> would support the split. Otherwise, this is bound to lead straight
> into hell.
>
> In a way, the kernel people got it right: put all the drivers in one
> repository, and make building the whole package and having parallel

"put all the drivers in one repository"?

So, all of:
	* drm
	* firmware
	* libdrm
	* xorg
	* mesa/dri
	* mesa/gallium
	* libxvmc
	* libvdpau
	(add more here)
of the same driver stack, in one repository?

> installations trivial. The (only?) issues with that in X.org are that:
> 1) there is a cultural aversion due to the bad experience with the
> horrible pre-modularization setup, and

There was an SDK there, i never used it directly, i built my driver 
against the tree (which was easy too). But I became a _really_ happy 
camper when everyone shipped the xorg sdk per default, heck, i even have 
a full debian build system in unichrome, simply because the sdk allows 
for that.

Now, about building the whole package... This is called a tinderbox, 
this is a part that's easily automated.

The real question is: where is the most pain, and how can we reduce it.
And the most pain is between the driver specific parts.

> 2) it wouldn't actually solve the DRM problems, because we want to
> have the DRM in our codebase, and the kernel people want to have it in
> theirs.

The kernel people can have theirs. What stops anyone from getting the 
drm code of a released driver stack into the next kernel version?

But when anyone decides they need a new driver stack which requires a 
new drm module, it should be easy to replace the stock kernel module.

Luc Verhaegen.
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: DRI SDK and modularized drivers.

[Nicolai Haehnle]

On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> In
>> particular, the Mesa core <-> classic driver split only makes sense if
>> there are enough people who are actually working on those drivers who
>> would support the split. Otherwise, this is bound to lead straight
>> into hell.
>>
>> In a way, the kernel people got it right: put all the drivers in one
>> repository, and make building the whole package and having parallel
>
> "put all the drivers in one repository"?
>
> So, all of:
>        * drm
>        * firmware
>        * libdrm
>        * xorg
>        * mesa/dri
>        * mesa/gallium
>        * libxvmc
>        * libvdpau
>        (add more here)
> of the same driver stack, in one repository?

Why not?

Mind you, I'm not advocating for any change at all, but as long as you
feel the need to move stuff around, why not try finding a goal that
people actually find useful? Of course, my suggestion is probably
crap, too.


[snip]
> The real question is: where is the most pain, and how can we reduce it.
> And the most pain is between the driver specific parts.

Nobody has ever had to feel the pain of a separation between Mesa core
and drivers. And since a git log I've just done tells me that you have
committed only twice to the Mesa repository within the last year or
so, maybe you should listen to the opinion of people who *have* been
active in the Mesa tree when it comes to that subject, and are working
on drivers that are probably significantly more involved than whatever
Unichrome does.


>> 2) it wouldn't actually solve the DRM problems, because we want to
>> have the DRM in our codebase, and the kernel people want to have it in
>> theirs.
>
> The kernel people can have theirs. What stops anyone from getting the
> drm code of a released driver stack into the next kernel version?
>
> But when anyone decides they need a new driver stack which requires a
> new drm module, it should be easy to replace the stock kernel module.

And that has worked so well in the past.

cu,
Nicolai

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc Verhaegen]

On Mon, Mar 22, 2010 at 10:46:37PM +0100, Nicolai Haehnle wrote:
> On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen <libv@skynet.be> wrote:
> >> In
> >> particular, the Mesa core <-> classic driver split only makes sense if
> >> there are enough people who are actually working on those drivers who
> >> would support the split. Otherwise, this is bound to lead straight
> >> into hell.
> >>
> >> In a way, the kernel people got it right: put all the drivers in one
> >> repository, and make building the whole package and having parallel
> >
> > "put all the drivers in one repository"?
> >
> > So, all of:
> >        * drm
> >        * firmware
> >        * libdrm
> >        * xorg
> >        * mesa/dri
> >        * mesa/gallium
> >        * libxvmc
> >        * libvdpau
> >        (add more here)
> > of the same driver stack, in one repository?
> 
> Why not?
> 
> Mind you, I'm not advocating for any change at all, but as long as you
> feel the need to move stuff around, why not try finding a goal that
> people actually find useful? Of course, my suggestion is probably
> crap, too.

Great, seems we agree on something here.

> [snip]
> > The real question is: where is the most pain, and how can we reduce it.
> > And the most pain is between the driver specific parts.
> 
> Nobody has ever had to feel the pain of a separation between Mesa core
> and drivers. And since a git log I've just done tells me that you have
> committed only twice to the Mesa repository within the last year or
> so, maybe you should listen to the opinion of people who *have* been
> active in the Mesa tree when it comes to that subject, and are working
> on drivers that are probably significantly more involved than whatever
> Unichrome does.

Heh.
 
> >> 2) it wouldn't actually solve the DRM problems, because we want to
> >> have the DRM in our codebase, and the kernel people want to have it in
> >> theirs.
> >
> > The kernel people can have theirs. What stops anyone from getting the
> > drm code of a released driver stack into the next kernel version?
> >
> > But when anyone decides they need a new driver stack which requires a
> > new drm module, it should be easy to replace the stock kernel module.
> 
> And that has worked so well in the past.

Yes, it did. And people for more than a year still pulled the mesa/drm 
tree and built and installed it, as doing this often solved their 
"driver stack internal" problems for them.

Luc Verhaegen.
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg