Bug 2797 - DRI with r300 doesn't work with Crystal Space
DRI with r300 doesn't work with Crystal Space
Status: RESOLVED NOTABUG
Product: DRI
Classification: Unclassified
Component: libGL
XOrg git
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-24 11:32 UTC by Ethan Glasser-Camp
Modified: 2005-03-31 18:54 UTC (History)
0 users

See Also:


Attachments
patch to link r300_dri.so against libGL (426 bytes, patch)
2005-03-30 09:22 UTC, Ethan Glasser-Camp
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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 ajax at nwnk dot net 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 ajax at nwnk dot net 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!