Your message dated Sun, 28 Aug 2011 20:56:01 +0200 with message-id <20110828185601.gc23...@mraw.org> and subject line Re: Bug#639621: libgl1-mesa-dri: A DRI1-capable r300_dri.so should be provided has caused the Debian Bug report #639621, regarding libgl1-mesa-dri: A DRI1-capable r300_dri.so should be provided to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 639621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639621 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: libgl1-mesa-dri Version: 7.11-4 On my system, using KMS and DRI2 is really slow (this is known in at least some cases; KMS/DRI2 just isn't as mature right now, I think? See 572911, 607510, and probably others). So, I have disabled KMS and just want to use regular DRI, which is currently much better. The problem is, the r300_dri.so that is shipped with libgl1-mesa-dri is the Gallium driver (I have a Radeon X1300, which uses r300_dri.so). This only works with DRI2, so all of the 3d rendering is done via swrast_dri.so. The performance isn't bad (still much better than KMS), but if I build libgl1-mesa-dri locally, and grab the non-Gallium r300_dri.so I get better performance since I'm no longer rendering via software. I think libgl1-mesa-dri should provide the non-Gallium r300_dri.so somewhere. It doesn't need to be the default, but it should be an option. I see a few ways to do this: 1. Just install the non-Gallium r300_dri.so instead of the Gallium one (I assume you don't want to do this, since the Gallium driver is deliberately chosen, and for all I know is much better on other systems) 2. Install the non-Gallium r300_dri.so under another name (r300dri1_dri.so or something?), and get the 'radeon' X driver in xserver-xorg-video-ati to report r300dri1 as the DRI driver name for DRI1. Currently it reports r300_dri.so for both DRI1 and DRI2 (see src/radeon_dri.c and R300_DRIVER_NAME in xserver-xorg-video-ati). 3. Allow the user to choose between the Gallium and non-Gallium drivers via the alternatives system, or via installing a package that diverts r300_dri.so, or something along those lines. 4. Make the Gallium r300 driver support both DRI1 and DRI2. I assume this is difficult and not a feasible short-term option, or it deliberately does not support DRI1. I'm not sure which way sounds the best to you. In the meantime, I'm just locally diverting r300_dri.so. -- Andrew Deason adea...@dson.org
--- End Message ---
--- Begin Message ---Andrew Deason <adea...@dson.org> (28/08/2011): > On my system, using KMS and DRI2 is really slow (this is known in at > least some cases; KMS/DRI2 just isn't as mature right now, I think? See > 572911, 607510, and probably others). So, I have disabled KMS and just > want to use regular DRI, which is currently much better. That's the bug you want to get solved, then. > I think libgl1-mesa-dri should provide the non-Gallium r300_dri.so > somewhere. It doesn't need to be the default, but it should be an > option. I see a few ways to do this: > > 1. Just install the non-Gallium r300_dri.so instead of the Gallium one > (I assume you don't want to do this, since the Gallium driver is > deliberately chosen, and for all I know is much better on other > systems) > > 2. Install the non-Gallium r300_dri.so under another name > (r300dri1_dri.so or something?), and get the 'radeon' X driver in > xserver-xorg-video-ati to report r300dri1 as the DRI driver name for > DRI1. Currently it reports r300_dri.so for both DRI1 and DRI2 (see > src/radeon_dri.c and R300_DRIVER_NAME in xserver-xorg-video-ati). > > 3. Allow the user to choose between the Gallium and non-Gallium drivers > via the alternatives system, or via installing a package that > diverts r300_dri.so, or something along those lines. > > 4. Make the Gallium r300 driver support both DRI1 and DRI2. I assume > this is difficult and not a feasible short-term option, or it > deliberately does not support DRI1. That's something we're not keen on doing, at all. Alternatives or diversions mean users are going to get broken stuff at some point, and concentrating on getting the Gallium drivers to work is something which looks like a better idea. > I'm not sure which way sounds the best to you. In the meantime, I'm just > locally diverting r300_dri.so. Since I'm not too happy with keeping bugs opened forever tagged “wontfix” I'm closing this bug report instead. Mraw, KiBi.signature.asc
Description: Digital signature
--- End Message ---