Re: [Mesa3d-dev] DRI SDK and modularized drivers.
-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- -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen l...@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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Mon, Mar 22, 2010 at 10:46:37PM +0100, Nicolai Haehnle wrote: On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen l...@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. -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Fri, Mar 19, 2010 at 06:26:03PM +0100, Nicolai Haehnle wrote: On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@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. -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
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#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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
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#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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
Nicolai Haehnle escribió: because we want to have the DRM in our codebase Why? -- __ | , , | | / \ | | ((__-^^-,-^^-__))Octavio Rossell Tabet | | `-_---' `---_-' octa...@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: octavio.vcf-- 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-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@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 -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] DRI SDK and modularized drivers.
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-boun...@lists.freedesktop.org [mailto:xorg-boun...@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-...@lists.sourceforge.net; x...@lists.freedesktop.org Subject: Re: [Mesa3d-dev] DRI SDK and modularized drivers. On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@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 ___ x...@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen l...@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 mostawesomed...@gmail.com -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Thu, Mar 18, 2010 at 01:28:28AM -0700, Corbin Simpson wrote: On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen l...@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
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
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. -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
