Re: Ubuntu plans for Natty release
On Fre, 2010-11-26 at 18:58 +0100, Julien Cristau wrote: > On Fri, Nov 26, 2010 at 08:44:29 +0100, Michel Dänzer wrote: > > > I've thought of a simpler possible solution: > > > > * Fix the Gallium drivers to bail gracefully instead of crashing > > with UMS (this will need to happen anyway). > > * Ship the classic and Gallium drivers in separate directories and > > set the libGL search path such that the two directories will be > > tried one after another. > > > Won't you also need to make the xserver's dri driver loader look for > both drivers (for aiglx)? Good catch :) I forgot to mention AIGLX. It might be best to stick to the classic drivers for that for now, as they're probably more robust for that, and I don't think the additional functionality offered by the Gallium drivers can be used via indirect rendering anyway. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1291221472.1124.115.ca...@thor.local
Re: Ubuntu plans for Natty release
On Fri, Nov 26, 2010 at 08:44:29 +0100, Michel Dänzer wrote: > I've thought of a simpler possible solution: > > * Fix the Gallium drivers to bail gracefully instead of crashing > with UMS (this will need to happen anyway). > * Ship the classic and Gallium drivers in separate directories and > set the libGL search path such that the two directories will be > tried one after another. > Won't you also need to make the xserver's dri driver loader look for both drivers (for aiglx)? Cheers, Julien signature.asc Description: Digital signature
Re: Ubuntu plans for Natty release
On Fre, 2010-11-26 at 19:32 +1100, Christopher James Halse Rogers wrote: > On Fri, 2010-11-26 at 08:44 +0100, Michel Dänzer wrote: > > On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers > > wrote: > > > On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > > > > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > > > > wrote: > > > > > > > > > Can you see an easy solution which allows changes during X's runtime > > > > > and > > > > > will handle UMS transparently? > > > > > > > > One possibility would be an r[36]00_dri.so wrapper which can pass > > > > through to the classic or Gallium drivers based on KMS vs. UMS and > > > > configuration via environment variables and/or configuration files. This > > > > might be appropriate for upstream as well. > > > > > > > That sounds an awful lot like work :). > > > > I've thought of a simpler possible solution: > > > > * Fix the Gallium drivers to bail gracefully instead of crashing > > with UMS (this will need to happen anyway). > > * Ship the classic and Gallium drivers in separate directories and > > set the libGL search path such that the two directories will be > > tried one after another. > > > > r300g would be in the first directory searched. With UMS, it would fail > > to initialize, and libGL would pick up r300 from the second directory. > > > > This solution would also allow overriding the default driver with > > $LIBGL_DRIVERS_PATH. > > > > I really hope you don't have to stick with your ugly X driver patch. :} > > That sounds like a good plan. Do you know off the top of your head how > much of this is already ready? Apart from the bug fix, no code changes should be necessary, just invoking configure --with-dri-searchpath /path/to/first/directory:/path/to/second/directoy. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290762517.1124.20.ca...@thor.local
Re: Ubuntu plans for Natty release
On Fri, 2010-11-26 at 08:44 +0100, Michel Dänzer wrote: > On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers > wrote: > > On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > > > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > > > wrote: > > > > > > > Can you see an easy solution which allows changes during X's runtime and > > > > will handle UMS transparently? > > > > > > One possibility would be an r[36]00_dri.so wrapper which can pass > > > through to the classic or Gallium drivers based on KMS vs. UMS and > > > configuration via environment variables and/or configuration files. This > > > might be appropriate for upstream as well. > > > > > That sounds an awful lot like work :). > > I've thought of a simpler possible solution: > > * Fix the Gallium drivers to bail gracefully instead of crashing > with UMS (this will need to happen anyway). > * Ship the classic and Gallium drivers in separate directories and > set the libGL search path such that the two directories will be > tried one after another. > > r300g would be in the first directory searched. With UMS, it would fail > to initialize, and libGL would pick up r300 from the second directory. > > This solution would also allow overriding the default driver with > $LIBGL_DRIVERS_PATH. > > I really hope you don't have to stick with your ugly X driver patch. :} > That sounds like a good plan. Do you know off the top of your head how much of this is already ready? signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers wrote: > On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > > wrote: > > > > > Can you see an easy solution which allows changes during X's runtime and > > > will handle UMS transparently? > > > > One possibility would be an r[36]00_dri.so wrapper which can pass > > through to the classic or Gallium drivers based on KMS vs. UMS and > > configuration via environment variables and/or configuration files. This > > might be appropriate for upstream as well. > > > That sounds an awful lot like work :). I've thought of a simpler possible solution: * Fix the Gallium drivers to bail gracefully instead of crashing with UMS (this will need to happen anyway). * Ship the classic and Gallium drivers in separate directories and set the libGL search path such that the two directories will be tried one after another. r300g would be in the first directory searched. With UMS, it would fail to initialize, and libGL would pick up r300 from the second directory. This solution would also allow overriding the default driver with $LIBGL_DRIVERS_PATH. I really hope you don't have to stick with your ugly X driver patch. :} -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290757469.1124.17.ca...@thor.local
Re: Ubuntu plans for Natty release
On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers wrote: > On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > > wrote: > > > On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote: > > > > On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers > > > > wrote: > > > > > > > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > > > > the DDX select between them based on kms support and an xorg.conf > > > > > setting (default to r300g, as that's the default upstream, and > > > > > whichever > > > > > r600 driver ends up being default in 7.10). This is not going to be > > > > > accepted upstream, but is, I think, a reasonable distro-patch to > > > > > retain > > > > > UMS support for radeon while defaulting to the upstream-default > > > > > driver. > > > > > > > > IMHO any solution which doesn't allow easily choosing between the 3D > > > > drivers during the X server's runtime (when KMS is enabled) isn't > > > > adequate. > > > > > > Certainly not adequate for driver development, > > > > Actually, driver developers probably tend to have their own custom > > setups anyway. > > > > > but is it necessary for end-users? This would be necessary for > > > allowing per-application overrides, but should we care about this? > > > > Probably not as long as the default 3D driver works (well enough), but > > e.g. for comparing between the 3D drivers it would be much more > > convenient and save nerves and time, also for bug triagers. > > > > > > > Can you see an easy solution which allows changes during X's runtime and > > > will handle UMS transparently? > > > > One possibility would be an r[36]00_dri.so wrapper which can pass > > through to the classic or Gallium drivers based on KMS vs. UMS and > > configuration via environment variables and/or configuration files. This > > might be appropriate for upstream as well. > > > That sounds an awful lot like work :). > > Also, my understanding was that UMS / classic mesa would not be > particularly supported upstream. If you'd welcome such a patch, maybe > that work is justified. > > I was only expecting to carry this dual-stack UMS/KMS hack for one > release, maybe two, and then not caring at all about UMS after that. Is that an issue, given choosing the 3D driver is only possible with KMS and will be useful for as long as there's more than one 3D driver? If you feel it's too much work, how about trying the simple update-alternatives solution first and worrying about something more sophisticated if that turns out to be problematic? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289567668.6227.79.ca...@thor.local
Re: Ubuntu plans for Natty release
On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > wrote: > > On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote: > > > On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers > > > wrote: > > > > > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > > > the DDX select between them based on kms support and an xorg.conf > > > > setting (default to r300g, as that's the default upstream, and whichever > > > > r600 driver ends up being default in 7.10). This is not going to be > > > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > > > UMS support for radeon while defaulting to the upstream-default driver. > > > > > > IMHO any solution which doesn't allow easily choosing between the 3D > > > drivers during the X server's runtime (when KMS is enabled) isn't > > > adequate. > > > > Certainly not adequate for driver development, > > Actually, driver developers probably tend to have their own custom > setups anyway. > > > but is it necessary for end-users? This would be necessary for > > allowing per-application overrides, but should we care about this? > > Probably not as long as the default 3D driver works (well enough), but > e.g. for comparing between the 3D drivers it would be much more > convenient and save nerves and time, also for bug triagers. > > > > Can you see an easy solution which allows changes during X's runtime and > > will handle UMS transparently? > > One possibility would be an r[36]00_dri.so wrapper which can pass > through to the classic or Gallium drivers based on KMS vs. UMS and > configuration via environment variables and/or configuration files. This > might be appropriate for upstream as well. > That sounds an awful lot like work :). Also, my understanding was that UMS / classic mesa would not be particularly supported upstream. If you'd welcome such a patch, maybe that work is justified. I was only expecting to carry this dual-stack UMS/KMS hack for one release, maybe two, and then not caring at all about UMS after that. > However, given that switching to UMS will require some kind of tweaking > anyway, I'm not sure why the script / procedure for that couldn't just > include appropriate update-alternatives calls. > The trick is getting all the users to see the same documentation :). signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers wrote: > On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote: > > On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers > > wrote: > > > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > > the DDX select between them based on kms support and an xorg.conf > > > setting (default to r300g, as that's the default upstream, and whichever > > > r600 driver ends up being default in 7.10). This is not going to be > > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > > UMS support for radeon while defaulting to the upstream-default driver. > > > > IMHO any solution which doesn't allow easily choosing between the 3D > > drivers during the X server's runtime (when KMS is enabled) isn't > > adequate. > > Certainly not adequate for driver development, Actually, driver developers probably tend to have their own custom setups anyway. > but is it necessary for end-users? This would be necessary for > allowing per-application overrides, but should we care about this? Probably not as long as the default 3D driver works (well enough), but e.g. for comparing between the 3D drivers it would be much more convenient and save nerves and time, also for bug triagers. > Can you see an easy solution which allows changes during X's runtime and > will handle UMS transparently? One possibility would be an r[36]00_dri.so wrapper which can pass through to the classic or Gallium drivers based on KMS vs. UMS and configuration via environment variables and/or configuration files. This might be appropriate for upstream as well. However, given that switching to UMS will require some kind of tweaking anyway, I'm not sure why the script / procedure for that couldn't just include appropriate update-alternatives calls. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289477210.6227.46.ca...@thor.local
Re: Ubuntu plans for Natty release
On Wed, 2010-11-10 at 13:58 -0800, Eric Anholt wrote: > On Wed, 10 Nov 2010 18:57:45 +1100, Christopher James Halse Rogers > wrote: > > Hey all. > > > > There are a couple of things in mesa that we'd like to do for Natty that > > could do with some coördination with Debian-X: > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > the DDX select between them based on kms support and an xorg.conf > > setting (default to r300g, as that's the default upstream, and whichever > > r600 driver ends up being default in 7.10). This is not going to be > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > UMS support for radeon while defaulting to the upstream-default driver. > > > > 2) As always, we need more space on the CDs. The DRI drivers are both > > large (~44MB) and contain substantial quantities of common code. Fedora > > at one point linked their DRI drivers with a shared libdricore¹, and I'm > > looking at doing something similar for the gallium drivers. This shaves > > about 30MB off the DRI drivers on AMD64 - down to 12MB, without touching > > the gallium drivers. > > > > Are either of these interesting to debian-x? Should I be committing > > these changes to the debian branches, or keeping them Ubuntu-specific? > > > > Also, > > 3) We'll possibly strip out all the less-used (ie: non-intel, > > non-radeon) DRI drivers into a separate package & add jockey hooks for > > users to install them if needed. That's not going to be so interesting > > for Debian, though. > > I'd like to see libdricore patches pushed upstream as a build option if > it's not too invasive. Fedora dropped them because they got tired of > porting them forward, but I think at the point where two+ distros and > half the mesa developers want the patch in place, we should just shove > it in. Fair enough. I'll see how upstream-friendly I can make them, then submit them. signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Wed, 2010-11-10 at 11:27 +0100, Cyril Brulebois wrote: > Christopher James Halse Rogers > (10/11/2010): > > There are a couple of things in mesa that we'd like to do for Natty that > > could do with some coördination with Debian-X: […] > > Unfortunately I haven't played with mesa at all yet, so I can't > comment for now. I guess I would prefer having your work kept in the > ubuntu branches for now. > No problem. I'll make sure it's easy to cherry-pick should you end up wanting it. signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote: > On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers > wrote: > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > the DDX select between them based on kms support and an xorg.conf > > setting (default to r300g, as that's the default upstream, and whichever > > r600 driver ends up being default in 7.10). This is not going to be > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > UMS support for radeon while defaulting to the upstream-default driver. > > IMHO any solution which doesn't allow easily choosing between the 3D > drivers during the X server's runtime (when KMS is enabled) isn't > adequate. > Certainly not adequate for driver development, but is it necessary for end-users? This would be necessary for allowing per-application overrides, but should we care about this? Mainly I'm concerned with ensuring that users who turn off KMS get 3D. I don't expect upstream to care or support this; focusing on kms/gallium is a perfectly reasonable decision to make. From our end though, if UMS is *not too much effort* to keep going then it's both useful for debugging (when UMS works & KMS doesn't) and allows people to have a usable system while those bugs are being fixed. Changing the DRI driver name when using UMS seems like the simplest solution here, and once we're doing that it's close to no extra effort to add an xorg.conf option for users to twiddle. Can you see an easy solution which allows changes during X's runtime and will handle UMS transparently? signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Wed, 10 Nov 2010 18:57:45 +1100, Christopher James Halse Rogers wrote: > Hey all. > > There are a couple of things in mesa that we'd like to do for Natty that > could do with some coördination with Debian-X: > > 1) Ship both the classic and gallium versions of r300 & r600, and have > the DDX select between them based on kms support and an xorg.conf > setting (default to r300g, as that's the default upstream, and whichever > r600 driver ends up being default in 7.10). This is not going to be > accepted upstream, but is, I think, a reasonable distro-patch to retain > UMS support for radeon while defaulting to the upstream-default driver. > > 2) As always, we need more space on the CDs. The DRI drivers are both > large (~44MB) and contain substantial quantities of common code. Fedora > at one point linked their DRI drivers with a shared libdricore¹, and I'm > looking at doing something similar for the gallium drivers. This shaves > about 30MB off the DRI drivers on AMD64 - down to 12MB, without touching > the gallium drivers. > > Are either of these interesting to debian-x? Should I be committing > these changes to the debian branches, or keeping them Ubuntu-specific? > > Also, > 3) We'll possibly strip out all the less-used (ie: non-intel, > non-radeon) DRI drivers into a separate package & add jockey hooks for > users to install them if needed. That's not going to be so interesting > for Debian, though. I'd like to see libdricore patches pushed upstream as a build option if it's not too invasive. Fedora dropped them because they got tired of porting them forward, but I think at the point where two+ distros and half the mesa developers want the patch in place, we should just shove it in. pgppNmTtmkm3B.pgp Description: PGP signature
Re: Ubuntu plans for Natty release
Christopher James Halse Rogers (10/11/2010): > There are a couple of things in mesa that we'd like to do for Natty that > could do with some coördination with Debian-X: […] Unfortunately I haven't played with mesa at all yet, so I can't comment for now. I guess I would prefer having your work kept in the ubuntu branches for now. Mraw, KiBi. signature.asc Description: Digital signature
Re: Ubuntu plans for Natty release
On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers wrote: > > 1) Ship both the classic and gallium versions of r300 & r600, and have > the DDX select between them based on kms support and an xorg.conf > setting (default to r300g, as that's the default upstream, and whichever > r600 driver ends up being default in 7.10). This is not going to be > accepted upstream, but is, I think, a reasonable distro-patch to retain > UMS support for radeon while defaulting to the upstream-default driver. IMHO any solution which doesn't allow easily choosing between the 3D drivers during the X server's runtime (when KMS is enabled) isn't adequate. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289378008.10682.102.ca...@thor.local
Ubuntu plans for Natty release
Hey all. There are a couple of things in mesa that we'd like to do for Natty that could do with some coördination with Debian-X: 1) Ship both the classic and gallium versions of r300 & r600, and have the DDX select between them based on kms support and an xorg.conf setting (default to r300g, as that's the default upstream, and whichever r600 driver ends up being default in 7.10). This is not going to be accepted upstream, but is, I think, a reasonable distro-patch to retain UMS support for radeon while defaulting to the upstream-default driver. 2) As always, we need more space on the CDs. The DRI drivers are both large (~44MB) and contain substantial quantities of common code. Fedora at one point linked their DRI drivers with a shared libdricore¹, and I'm looking at doing something similar for the gallium drivers. This shaves about 30MB off the DRI drivers on AMD64 - down to 12MB, without touching the gallium drivers. Are either of these interesting to debian-x? Should I be committing these changes to the debian branches, or keeping them Ubuntu-specific? Also, 3) We'll possibly strip out all the less-used (ie: non-intel, non-radeon) DRI drivers into a separate package & add jockey hooks for users to install them if needed. That's not going to be so interesting for Debian, though. ¹: http://pkgs.fedoraproject.org/gitweb/?p=mesa.git;a=blob;f=mesa-7.1-link-shared.patch;h=592e2e2163e8e06a1607dcaa5608024dab196745;hb=HEAD -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289375866.5263.4.ca...@ed
