DRI doesn't work on 2.4.0 but does on prerelease-ac5

DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Michael D. Crawford]

I was testing the 2.4.0 kernel by running "make exec" in the Mesa-3.4 sources,
which builds and runs a bunch of demos, and was suprised to see one of the tests
emit a message that said DRI wasn't available.  It had been working before.

Just to make sure I then booted off of 2.4.0-prerelease-ac5 and it was working
again.

This is with XFree86 4.0.1 on Slackware 7.1.  I have an ATI Rage Millenium card
on a machine with a 667 MHz Pentium III and 128 MB of 133 MHz RAM.  The
motherboard is an ASUS P3V4X.  It has an ACPI bios but ACPI is disabled in the
config.

Could XFree86 4.0.2 fix this?  I had been waiting until the binary packages were
available from ftp.slackware.com because Patrick Volkerding lays out the
directories in a slightly different manner that he argues pretty convincingly is
preferable, but it would be a drag for me to reproduce by building it myself.
 
AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
as modules.

In the /var/log/XFree86.0.log file I see the following under 2.4.0 final
release:

(EE) r128(0): R128DRIScreenInit failed (DRM version = 2.1.2, expected 1.0.x). 
Disabling DRI.
(0): [drm] failed to remove DRM signal handler
(0): failed to destroy server context
(0): [drm] removed 1 reserved context for kernel
(0): [drm] unmapping 4096 bytes of SAREA 0xc5bb3000 at 0x40014000

in the corresponding point of the same file under 2.4.0-prerelease-ac5 I have:

(II) r128(0): [agp] Mode 0x1f000203 [AGP 0x1106/0x0691; Card 0x1002/0x5246]
(II) r128(0): [agp] 8192 kB allocated with handle 0xcc82b000
(II) r128(0): [agp] ring handle = 0xe4000000
(II) r128(0): [agp] Ring mapped at 0x421d9000
(II) r128(0): [agp] ring read ptr handle = 0xe4101000
(II) r128(0): [agp] Ring read ptr mapped at 0x40015000
(II) r128(0): [agp] vertex buffers handle = 0xe4102000
(II) r128(0): [agp] Vertex buffers mapped at 0x422da000
(II) r128(0): [agp] indirect buffers handle = 0xe4202000
(II) r128(0): [agp] Indirect buffers mapped at 0x423da000
(II) r128(0): [agp] AGP texture map handle = 0xe4302000
(II) r128(0): [agp] AGP Texture map mapped at 0x424da000
(II) r128(0): [drm] register handle = 0xdd000000
(II) r128(0): [drm] Added 64 16384 byte vertex buffers
(II) r128(0): [drm] Mapped 64 vertex buffers

The relevant parts of my .config file are as follows (and are identical between
the two kernel versions, I used "make oldconfig" and didn't change any options):

CONFIG_AGP=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_I810 is not set
CONFIG_AGP_VIA=y
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_GAMMA is not set
CONFIG_DRM_R128=y
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_MGA is not set

If you want my whole .config file I could mail it in or post it on my website.

Mike

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
crawford@goingware.com

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Alan Olsen]

On Sat, 6 Jan 2001, Michael D. Crawford wrote:

> AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
> as modules.

AGPGART doe *not* work if compiled statically.  Compile it as a module.
You will be much happier. (i.e. It might actually work.)  I would also
compile DRM and the r128 drivers as modules as well.

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [Newbie]Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[dep]

On Saturday 06 January 2001 10:30 pm, Alan Olsen wrote:

| AGPGART doe *not* work if compiled statically.  Compile it as a
| module. You will be much happier. (i.e. It might actually work.)  I
| would also compile DRM and the r128 drivers as modules as well.

it's worked fine compiled into the kernel here, along with the dri 
and mga stuff since test4.

-- 
dep
--
bipartisanship: an illogical construct not unlike the idea that
if half the people like red and half the people like blue, the 
country's favorite color is purple.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Dax Kelson]

Alan Olsen said once upon a time (Sat, 6 Jan 2001):

> On Sat, 6 Jan 2001, Michael D. Crawford wrote:
>
> > AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
> > as modules.
>
> AGPGART doe *not* work if compiled statically.  Compile it as a module.
> You will be much happier. (i.e. It might actually work.)  I would also
> compile DRM and the r128 drivers as modules as well.

AGPGART works fine for me compiled in.

Dax

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Jeff Hartmann]

> Could XFree86 4.0.2 fix this?  I had been waiting until the binary packages were
> available from ftp.slackware.com because Patrick Volkerding lays out the
> directories in a slightly different manner that he argues pretty convincingly is
> preferable, but it would be a drag for me to reproduce by building it myself.

XFree 4.0.2 will fix this.

> (EE) r128(0): R128DRIScreenInit failed (DRM version = 2.1.2, expected 1.0.x). 
> Disabling DRI.

We made binary incompatible device interface changes with 4.0.2.  These 
driver changes resulted in a more stable / faster / cleaner Rage 128 driver.

-Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Michael D. Crawford]

OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
2.4.0-ac4.  (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
AGP).

BUT - although /var/log/XFree86.0.log documents the startup of DRI, DRM and AGP,
and states the info about their initialization and stuff so that it looks like
they're working, I don't notice any performance difference running any of the
Mesa-3.4 demos whether or not I use DRI, and whether I run 4.0.1 or 4.0.2.

This makes me suspect it's not really working, or else my build of the Mesa-3.4
library wasn't configured right - but note that if I disable DRI, one of the
Mesa demos will comment that it's not available.

A specific example is Mesa-3.4/demos/gloss.  It's a rotating textured cylinder
that is partially reflective of what seems to be a landscape that is in front of
the screen being reflecting back to the viewer.  I get a pretty consistent 7.5
frames per second:

- in 4.0.1 with no DRI
- in 4.0.1 with DRI
- in 4.0.2 with no DRI
- in 4.0.2 with DRI

Having agpgart and drm/r128 compiled in or as modules also doesn't appear to
make a difference.

The frame rate for gloss drops to about 3.5 if I run geartrain (another demo)
alongside it.  Geartrain by itself seems to be about the same speed in all
cases, though it doesn't report a number.

There are a couple benchmarking tools in Mesa if someone wanted hard numbers
from me.

Can anyone suggest any 3D code that I can download that does more complex things
than the mesa demos that I can test this with?

Is my DRI really working?  If not, any tips on getting it to do so?

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
crawford@goingware.com

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Bill Nottingham]

Michael D. Crawford (crawford@goingware.com) said: 
> This makes me suspect it's not really working, or else my build of the Mesa-3.4
> library wasn't configured right - but note that if I disable DRI, one of the
> Mesa demos will comment that it's not available.

It sounds as if you're using a Mesa lib that doesn't support the
X DRI stuff, just the software renderer.

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[khromy]

On Mon, Jan 08, 2001 at 06:35:43PM +0000, Michael D. Crawford wrote:
> OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
> 2.4.0-ac4.  (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
> AGP).
> 
> BUT - although /var/log/XFree86.0.log documents the startup of DRI, DRM and AGP,
> and states the info about their initialization and stuff so that it looks like
> they're working, I don't notice any performance difference running any of the
> Mesa-3.4 demos whether or not I use DRI, and whether I run 4.0.1 or 4.0.2.
> 
> This makes me suspect it's not really working, or else my build of the Mesa-3.4
> library wasn't configured right - but note that if I disable DRI, one of the
> Mesa demos will comment that it's not available.
> 
> A specific example is Mesa-3.4/demos/gloss.  It's a rotating textured cylinder
> that is partially reflective of what seems to be a landscape that is in front of
> the screen being reflecting back to the viewer.  I get a pretty consistent 7.5
> frames per second:
> 
> - in 4.0.1 with no DRI
> - in 4.0.1 with DRI
> - in 4.0.2 with no DRI
> - in 4.0.2 with DRI
> 
> Having agpgart and drm/r128 compiled in or as modules also doesn't appear to
> make a difference.
> 
> The frame rate for gloss drops to about 3.5 if I run geartrain (another demo)
> alongside it.  Geartrain by itself seems to be about the same speed in all
> cases, though it doesn't report a number.
> 
> There are a couple benchmarking tools in Mesa if someone wanted hard numbers
> from me.
> 
> Can anyone suggest any 3D code that I can download that does more complex things
> than the mesa demos that I can test this with?
> 
> Is my DRI really working?  If not, any tips on getting it to do so?
I have this same problem with a Voodoo 3 2000(tdfx) running 2.4.0 and XFree86 4.0.2.

-- 
L1:	khromy		;khromy(at)khromy.lnuxlab.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Michael D. Crawford]

J Sloan (jjs@toyota.com) sez:

> This is a little OT for linux-kernel

Off-topic to debug a new kernel feature that will significantly add to the
competitiveness of Linux on the desktop and in engineering applications?

Remember, my original report was that DRI was reported to be working in before
the final 2.4.0 release, but stopped when the penguin peed on it, but now that
I've done what should be done to fix this, I don't have the results that others
are seeing.

While this may be due to problems with Mesa, XFree86 4.0.2, or the kernel, the
fact is that in our brave new world they operate as an integrated whole so it is
important to figure it out as a unit.  And I'm not really trying to play quake
here but QA the kernel in general - it was in noticing a discrepancy while
running the Mesa test suite that I got onto this, not because I care so much
about 3D performance.  I've yet to find a programmer's editor where 3D
performance makes much of a difference.

Comments posted here and received privately indicate that some get blazing speed
from 4.0.2 + 2.4.0, and some get, well, software speeds.  So there's a problem
to be worked out.

I've done what others have suggested, removing any GL libraries other than the
ones in /usr/X11R6/lib to make sure my applications used that one.

The build of the Mesa demos are hardwired to use the libraries from within the
source distribution directories.  If you take the gloss binary somewhere else,
delete those libraries, and make a link to the X11 GL library in /usr/lib, gloss
will run, at the amazing (and previously observed) frame rate of 7.5 FPS.

So that doesn't work.

glxinfo says dri is not available if I remove the library as I did.  So I
rebuilt Mesa and reinstalled it.  The full output of glxinfo on my machine
follows.  Note that it says "direct rendering: Yes" but the version strings
don't match.  Does that indicate the problem?

Server: 1.3 Mesa 3.4
Client: 1.2 Mesa 3.4
OpenGL: 1.2 Mesa 3.4

display: :0.0  screen:0
direct rendering: Yes
server glx vendor string: Brian Paul
server glx version string: 1.3 Mesa 3.4
server glx extensions:
    GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
    GLX_ARB_get_proc_address
client glx vendor string: Brian Paul
client glx version string: 1.2 Mesa 3.4
client glx extensions:
    GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
    GLX_ARB_get_proc_address
GLX extensions:
    GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
    GLX_ARB_get_proc_address
OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 1.2 Mesa 3.4
OpenGL extensions:
    GL_ARB_multitexture, GL_ARB_texture_cube_map, GL_ARB_tranpose_matrix, 
    GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_func_separate, 
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
    GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, 
    GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, 
    GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
    GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_texture3D, 
    GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_object, 
    GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_HP_occlusion_test, 
    GL_INGR_blend_func_separate, GL_MESA_window_pos, GL_MESA_resize_buffers, 
    GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGI_color_matrix, 
    GL_SGI_color_table, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp, 
    GL_SGIX_pixel_texture

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 24 tc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x24 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x25 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x26 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x27 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x28 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x29 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2a 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
crawford@goingware.com

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Ragnar Hojland Espinosa]

On Mon, Jan 08, 2001 at 10:45:09PM +0000, Michael D. Crawford wrote:
> glxinfo says dri is not available if I remove the library as I did.  So I
> rebuilt Mesa and reinstalled it.  The full output of glxinfo on my machine
> follows.  Note that it says "direct rendering: Yes" but the version strings
> don't match.  Does that indicate the problem?
> 

FWIW, this works:

server glx vendor string: SGI
server glx version string: 1.2
client glx vendor string: SGI
client glx version string: 1.2
OpenGL vendor string: VA Linux Systems, Inc.
OpenGL renderer string: Mesa DRI Voodoo3 20001101
OpenGL version string: 1.2 Mesa 3.4

> server glx vendor string: Brian Paul
> server glx version string: 1.3 Mesa 3.4
> client glx vendor string: Brian Paul
> client glx version string: 1.2 Mesa 3.4
> OpenGL vendor string: Brian Paul
> OpenGL renderer string: Mesa X11
> OpenGL version string: 1.2 Mesa 3.4

-- 
____/|  Ragnar Højland     Freedom - Linux - OpenGL      Fingerprint  94C4B
\ o.O|                                                   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for      104B78C56 B72F0822
   U     chaos and madness await thee at its end."       hkp://keys.pgp.com

Handle via comment channels only.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Bill Crawford]

 The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
Michael is quite right in saying he needed to blow it away. The only
way I could get DRI working until recently was to transplant a copy
of libGL.so from the XFree86 build tree into /usr/lib, delete or rename
the Mesa package version out of the way, and run ldconfig.

 This is being fixed in Red Hat Raw Hide, and someone put up a version
for download (can't remember where now; will have a look tomorrow and
let you know).

-- 
/* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */
#include "stddiscl.h"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Alan Cox]

>  The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.

Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
advantages including mostly working on Matrox cards which 1.0 never did (for
me anyway) and handling things that Mesa 3.3 tried to allocate the odd gig
of ram for and then exploded.

With the CVS stuff the 2.4 kernel should work out of the box. You need -ac for
some ALi AGP chipsets.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Alan Olsen]

On Wed, 10 Jan 2001, Alan Cox wrote:

> >  The Mesa package in Red Hat 7 won't do DRI with recent XFree86 CVS.
> 
> Yep. Its Mesa 3.3/DRI 1.0. XFree86 CVS is Mesa 3.4/DRI 2.0. That has several
> advantages including mostly working on Matrox cards which 1.0 never did (for
> me anyway) and handling things that Mesa 3.3 tried to allocate the odd gig
> of ram for and then exploded.
> 
> With the CVS stuff the 2.4 kernel should work out of the box. You need -ac for
> some ALi AGP chipsets.

My experiences with the Matrox G400 has been similar.

With 4.0.1 and the Matrox drivers, I could get DRI to work... For a while
and then the whole thing would lock tight as a drum, kernel and all.

The Matrox drivers on their ftp site will not even build with
XFree86 4.0.2. 

XFree86 4.0.2 with 2.4.0-test 12 no longer locks up on some GL games.
(Heavy Gear II, Quake III, and Heretic 2 all work well.) The only
exception I can find is Descent 3 which has a nasty visual smearing
problem that makes it unplayable. (Not certain why. Have not pressed the
issue with Loki yet.) Xinerama has an odd problem, which Keith Packard is
looking into. (When he gets back from Hawaii.) Xinerama is usable, but has
some ugly screen artifacts on the second screen.

The other big difference between 4.0.1 under the 2.2.17 with back-ported
AGP and the 4.0.2 on 2.4.0-test 12 is that I now get a contant frame rate.
On the earlier version, the framerate could bounce around 25% of the total
frames with the Mesa gears test.  The new version I see a varience of
about 2 frames or so! VERY steady.

I will be testing the performance under 2.4.0 final sometime later
tonight, after I am done with the project I am currently working on.  (One
of those "I have an idea and must test it now" kinda days.  So far, the
code has all worked...)  

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Gareth Hughes]

Michael D. Crawford wrote:
>
> glxinfo says dri is not available if I remove the library as I did. So I 
> rebuilt Mesa and reinstalled it. The full output of glxinfo on my machine 
> follows. Note that it says "direct rendering: Yes" but the version strings 
> don't match. Does that indicate the problem? 
> 
> Server: 1.3 Mesa 3.4 
> Client: 1.2 Mesa 3.4 
> OpenGL: 1.2 Mesa 3.4 
> 
> display: :0.0 screen:0 
> direct rendering: Yes 
> server glx vendor string: Brian Paul 
> server glx version string: 1.3 Mesa 3.4 
> server glx extensions: 
>     GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
>     GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
>     GLX_ARB_get_proc_address 
> client glx vendor string: Brian Paul 
> client glx version string: 1.2 Mesa 3.4 
> client glx extensions: 
>     GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
>     GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
>     GLX_ARB_get_proc_address 
> GLX extensions: 
>     GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
>     GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
>     GLX_ARB_get_proc_address 
> OpenGL vendor string: Brian Paul 
> OpenGL renderer string: Mesa X11 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> OpenGL version string: 1.2 Mesa 3.4 
> OpenGL extensions: 
>     ...

You are still using software Mesa.  It's not using the DRI libGL.so,
simple as that.

You should see something like this:

demos> glxinfo 
display: :0.0  screen:0
...
OpenGL vendor string: VA Linux Systems, Inc.
OpenGL renderer string: Mesa DRI Radeon 20010105 AGP 2x x86/3DNow!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OpenGL version string: 1.2 Mesa 3.4
OpenGL extensions:
    GL_ARB_multitexture, GL_ARB_tranpose_matrix, GL_EXT_abgr, 
    GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, 
    GL_EXT_compiled_vertex_array, GL_EXT_histogram,
GL_EXT_packed_pixels, 
    GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, 
    GL_EXT_texture3D, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, 
    GL_EXT_texture_env_dot3, GL_EXT_texture_object,
GL_EXT_texture_lod_bias, 
    GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, 
    GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, 
    GL_SGIS_texture_edge_clamp
...

Try running with LIBGL_DEBUG=verbose set.  If you don't see the
following messages, you know for sure the DRI is not being used.

demos> LIBGL_DEBUG=verbose glxinfo
libGL: trying /usr/XF86/lib/modules/dri/radeon_dri.so
libGL: trying /usr/XF86/lib/modules/dri/radeon_dri.so
display: :0.0  screen:0
...

Try reading the DRI User's Guide at http://dri.sourceforge.net, or post
to dri-users@lists.sourceforge.net for help.  It just sounds like a
config problem, not a bug in the kernel, Mesa or the DRI.

-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/