[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#639621: libgl1-mesa-dri: A DRI1-capable r300_dri.so should be provided



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
adeason@dson.org



Reply to: