Bug 2797

Summary: DRI with r300 doesn't work with Crystal Space
Product: DRI Reporter: Ethan Glasser-Camp <glasse>
Component: libGLAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: high    
Version: XOrg git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
patch to link r300_dri.so against libGL none

Description Ethan Glasser-Camp 2005-03-24 11:32:43 UTC 
DRI works great with some programs but not with others. Here's the log from
running tuxracer.

ethan@sundance:/opt/Xorg-6.8$ LIBGL_DEBUG=verbose tuxracer
Tux Racer 0.61 -- a Sunspire Studios Production (http://www.sunspirestudios.com)
(c) 1999-2000 Jasmin F. Patry <jfpatry@sunspirestudios.com>
"Tux Racer" is a trademark of Jasmin F. Patry
Tux Racer comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
See http://www.gnu.org/copyleft/gpl.html for details.
 
libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen 0)
libGL: OpenDriver: trying /opt/Xorg-6.8/lib/modules/dri/r300_dri.so
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
libGL error: 
Can't open configuration file /etc/drirc: No such file or directory.
 
The log continues on from there.. it works great, in other words, and I can play
hardware-accelerated tuxracer.

Here's what happens if I try to run Crystal Space:

ethan@sundance:~/software/CS$ LIBGL_DEBUG=verbose ./walktest            
NOTIFY: Could not get sound driver
libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen 0)
libGL: OpenDriver: trying /opt/Xorg-6.8/lib/modules/dri/r300_dri.so
libGL error: dlopen /opt/Xorg-6.8/lib/modules/dri/r300_dri.so failed
(/opt/Xorg-6.8/lib/modules/dri/r300_dri.so: undefined symbol: glXGetProcAddress)
libGL error: unable to find driver: r300_dri.so
  Indirect rendering may indicate a flawed OpenGL setup if you run on a local
  X server.
 
At first I thought this was an error from compiling against the wrong headers or
libraries, but recompiling doesn't make it go away. My next thought was that
this happened because walktest wasn't directly linked with libGL, but rather
uses some kind of dlopen magic to talk to a plugin that is linked against libGL.
So I linked walktest manually against libGL, which made this error went away but
then it wouldn't render anything, only draw a totally back window.

The CS people suggest this might be due to the experimentalness of the r300
driver. Any ideas?

Ethan
Comment 1 Ethan Glasser-Camp 2005-03-30 09:22:49 UTC 
Created attachment 2259 [details] [review]
patch to link r300_dri.so against libGL

I fixed the problem by linking r300_dri.so against libGL. I have no idea if
this is the Right Thing or not, though.
Comment 2 Adam Jackson 2005-03-30 09:39:27 UTC 
it's wrong.  DRI drivers should be loadable by the server as well, which is not
linked against libGL.

this is the same issue doom3 had when it first came out.  as a workaround try
running walktest with LD_PRELOAD=/usr/lib/libGL.so (or wherever you put your libGL).
Comment 3 Ethan Glasser-Camp 2005-03-31 13:18:52 UTC 
(In reply to comment #2)
> it's wrong.  DRI drivers should be loadable by the server as well, which is not
> linked against libGL.
> 
> this is the same issue doom3 had when it first came out.  as a workaround try
> running walktest with LD_PRELOAD=/usr/lib/libGL.so (or wherever you put your
libGL).

That works too. But wait, if the DRI drivers are supposed to be loadable by the
server by itself, and if the server isn't linked against libGL, then wouldn't
the server trying to load the DRI driver get an undefined symbol the same way
Crystal Space does?
Comment 4 Adam Jackson 2005-03-31 14:21:11 UTC 
(In reply to comment #3)
> That works too. But wait, if the DRI drivers are supposed to be loadable by the
> server by itself, and if the server isn't linked against libGL, then wouldn't
> the server trying to load the DRI driver get an undefined symbol the same way
> Crystal Space does?

Treading into the realm of the theoretical here, since the server doesn't
support loading DRI drivers yet...

But the answer is that the server would define these symbols itself.  When the
dynamic linker goes to resolve them it looks first in the local object and then
widens the search outward according to some fairly complicated rules.  Since the
server would define glXGetProcAddress itself, the driver would use that one.
Comment 5 Ethan Glasser-Camp 2005-04-01 12:54:47 UTC 
OK, great. Thanks for the workaround!

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.