From: Jacek P. <jac...@gm...> - 2006-05-30 18:16:15
|
Quake2 works here without hardware acceleration on Radeon 9800, same binary works correctly on Matrox G400, in both cases drivers are from Mesa CVS. This is part of quake2 output with LIBGL_DEBUG enabled: Using libGL.so for OpenGL...Initializing OpenGL display ...setting fullscreen mode 3: 640 480 Using XFree86-VidModeExtension Version 2.2 libGL error: dlopen /usr/lib/xorg/modules/dri//r300_dri.so failed (/usr/lib/xorg/modules/dri//r300_dri.so: undefined symbol: _glapi_add_dispatch) libGL error: dlopen /usr/lib/xorg/modules/dri//r300_dri.so failed (/usr/lib/xorg/modules/dri//r300_dri.so: undefined symbol: _glapi_add_dispatch) libGL error: unable to find driver: r300_dri.so What does it mean? Everything else works - glxinfo display correct Renderer string (Mesa DRI R300 20040924 AGP 1x x86/MMX+/3DNow!+/SSE TCL), games, Blender and my code works with direct rendering enabled.... The only difference is that quake2 loads libGL.so with dlopen, but I am sure that it uses /usr/lib/libGL.so (I tried to rename it) - just like each other application. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net |
From: Ian R. <id...@us...> - 2006-05-30 18:55:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jacek Poplawski wrote: > Quake2 works here without hardware acceleration on Radeon 9800, same binary > works correctly on Matrox G400, in both cases drivers are from Mesa CVS. > > This is part of quake2 output with LIBGL_DEBUG enabled: > > Using libGL.so for OpenGL...Initializing OpenGL display > ...setting fullscreen mode 3: 640 480 > Using XFree86-VidModeExtension Version 2.2 > libGL error: dlopen /usr/lib/xorg/modules/dri//r300_dri.so failed > (/usr/lib/xorg/modules/dri//r300_dri.so: undefined symbol: > _glapi_add_dispatch) > libGL error: dlopen /usr/lib/xorg/modules/dri//r300_dri.so failed > (/usr/lib/xorg/modules/dri//r300_dri.so: undefined symbol: > _glapi_add_dispatch) > libGL error: unable to find driver: r300_dri.so > > What does it mean? It means that your r300_dri.so is *really* old. _glapi_add_dispatch was removed from libGL months ago. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfJRWX1gOwKyEAw8RAqziAJ4gVllY19W5lqb/emhWuDiJmShv8gCgkkhT Z1B6NZb2N3vxEx4bHoa0ev8= =GdmQ -----END PGP SIGNATURE----- |
From: Ian R. <id...@us...> - 2006-05-30 21:05:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jacek Poplawski wrote: >> It means that your r300_dri.so is *really* old. _glapi_add_dispatch was >> removed from libGL months ago. > > But I just compiled it today... > I've updated my Mesa CVS snapshot and used "make linux-dri-x86", then > copied r300_dri.so. > I have this symbol in 4 places: > > jp@darkwood ~/CVS/Mesa % grep -r _glapi_add_dispatch * > src/mesa/glapi/glapi.c: * calls \c _glapi_add_dispatch we'll put in > the proper offset. If that > src/mesa/glapi/glapi.c:_glapi_add_dispatch( const char * const * > function_names, > src/mesa/glapi/glapi.h:_glapi_add_dispatch( const char * const * > function_names, > src/mesa/drivers/dri/common/utils.c: offset = > _glapi_add_dispatch( functions, parameter_signature ); My mistake. _glapi_add_dispatch is the new function. The old function was _glapi_add_entrypoint or something. It seems that the libGL that is being used is too old. I seem to recall that Quake2 does a dlopen on libGL, so you need to make sure that it's getting the right one. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfLNHX1gOwKyEAw8RArfTAJ9ZRiNzMfFKj6ChumDyA46lZLFA5ACfaMkW km/aRcpjfOlI2CDcoLFYKUQ= =7msH -----END PGP SIGNATURE----- |
From: Daniel S. <da...@fo...> - 2006-05-30 21:23:27
|
On Tue, May 30, 2006 at 02:04:07PM -0700, Ian Romanick wrote: > Jacek Poplawski wrote: > >> It means that your r300_dri.so is *really* old. _glapi_add_dispatch w= as > >> removed from libGL months ago. > >=20 > > But I just compiled it today... > > I've updated my Mesa CVS snapshot and used "make linux-dri-x86", then > > copied r300_dri.so. > > I have this symbol in 4 places: > >=20 > > jp@darkwood ~/CVS/Mesa % grep -r _glapi_add_dispatch * > > src/mesa/glapi/glapi.c: * calls \c _glapi_add_dispatch we'll put in > > the proper offset. If that > > src/mesa/glapi/glapi.c:_glapi_add_dispatch( const char * const * > > function_names, > > src/mesa/glapi/glapi.h:_glapi_add_dispatch( const char * const * > > function_names, > > src/mesa/drivers/dri/common/utils.c: offset =3D > > _glapi_add_dispatch( functions, parameter_signature ); >=20 > My mistake. _glapi_add_dispatch is the new function. The old function > was _glapi_add_entrypoint or something. It seems that the libGL that is > being used is too old. I seem to recall that Quake2 does a dlopen on > libGL, so you need to make sure that it's getting the right one. Either that, or the libGL is from fglrx. |
From: Jacek P. <jac...@gm...> - 2006-05-30 21:55:56
|
The same libGL.so is being used in all cases, and I can't find any other on my system. 1) line from glxinfo output: OpenGL renderer string: Mesa DRI R300 20040924 AGP 1x x86/MMX+/3DNow!+/SSE TCL 2) line from ldd glxinfo: libGL.so.1 => /usr/lib/libGL.so.1 (0xb7e60000) 3) /usr/lib: lrwxrwxrwx 1 root root 10 2006-05-30 23:35 /usr/lib/libGL.so -> libGL.so.1 4) line from strace quake2: open("/usr/lib/libGL.so", O_RDONLY) = 8 (that's the only libGL in strace log) PS. When I set "LIBGL_ALWAYS_INDIRECT" or unset "R300_FORCE_R300" I see Mesa version 6.4.2 (instead 6.5.1) in glxinfo -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net |
From: Jacek P. <jac...@gm...> - 2006-05-31 06:40:57
|
On 5/30/06, Pedro Maia <ped...@ne...> wrote: > > To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 > > In my case it works fine, with that trick , without it didn't work. > But why it didn't work? It opens /usr/lib/libGL.so for sure, because without it even software accelerated OpenGL doesn't work in the game. Quake2 is the only application I tried which loads libGL with dlopen. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net |
From: Ian R. <id...@us...> - 2006-06-01 15:55:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jacek Poplawski wrote: > On 5/30/06, Pedro Maia <ped...@ne...> wrote: > >> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 >> >> In my case it works fine, with that trick , without it didn't work. > > But why it didn't work? It opens /usr/lib/libGL.so for sure, because > without > it even software accelerated OpenGL doesn't work in the game. > Quake2 is the only application I tried which loads libGL with dlopen. I think the way that Quake2 dlopens libGL prevents some symbols in libGL from being exposed to the driver. I seem to remember alanh mentioning something about this, but I don't recall the details. My dlopen-fu is lacking, so I'm not sure what the problem or the solution might be. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEfw2RX1gOwKyEAw8RAhk1AJ9xXh8olg1fe6jEPGYwdsQgjHMVgACgjM2c eXbnZXbtfn2nTHvhfnGUVLg= =fgPp -----END PGP SIGNATURE----- |
From: Alan H. <al...@fa...> - 2006-06-01 16:07:26
|
On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jacek Poplawski wrote: > > On 5/30/06, Pedro Maia <ped...@ne...> wrote: > > > >> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 > >> > >> In my case it works fine, with that trick , without it didn't work. > > > > But why it didn't work? It opens /usr/lib/libGL.so for sure, because > > without > > it even software accelerated OpenGL doesn't work in the game. > > Quake2 is the only application I tried which loads libGL with dlopen. > > I think the way that Quake2 dlopens libGL prevents some symbols in libGL > from being exposed to the driver. I seem to remember alanh mentioning > something about this, but I don't recall the details. My dlopen-fu is > lacking, so I'm not sure what the problem or the solution might be. Basically, what happens is this.... A game may try to dlopen libGL itself at runtime rather than linking at build time. So, the linux dllinker does not bother to search for symbols to resolve that exist in the DRI driver. I'm not sure exactly why it doesn't though. Doing this... export LD_PRELOAD=/usr/lib/libGL.so to force the libGL linkage fixes the issue. Alan. |
From: Alan H. <al...@fa...> - 2006-06-01 16:17:08
|
On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: > On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Jacek Poplawski wrote: > > > On 5/30/06, Pedro Maia <ped...@ne...> wrote: > > > > > >> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 > > >> > > >> In my case it works fine, with that trick , without it didn't work. > > > > > > But why it didn't work? It opens /usr/lib/libGL.so for sure, because > > > without > > > it even software accelerated OpenGL doesn't work in the game. > > > Quake2 is the only application I tried which loads libGL with dlopen. > > > > I think the way that Quake2 dlopens libGL prevents some symbols in libGL > > from being exposed to the driver. I seem to remember alanh mentioning > > something about this, but I don't recall the details. My dlopen-fu is > > lacking, so I'm not sure what the problem or the solution might be. > > Basically, what happens is this.... > > A game may try to dlopen libGL itself at runtime rather than linking at > build time. > > So, the linux dllinker does not bother to search for symbols to resolve > that exist in the DRI driver. I'm not sure exactly why it doesn't > though. Actually I do remember my theory.... When a program is linked at build time, libGL is the one responsible for dlload'ing the DRI driver and resolves symbols perfectly well with the current RTLD flags. But when the program dlopen's libGL itself, it resolves what it currently has access to which the DRI driver isn't actually loaded. I suspect for this to work the libGL's dlinit() routine (that's called when dlopen'ed) would need to someone link in the correct DRI driver at that time - but I'm pretty sure all the available details to do that wouldn't be available. I don't think there's any easy fix, which is why I resorted to the LD_PRELOAD approach. This may all be bogus though. Alan. |
From: Jacek P. <jac...@gm...> - 2006-05-31 16:39:40
|
> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 It helps on r300, I wonder why it isn't needed on mga. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net |
From: Brian P. <bri...@tu...> - 2006-06-01 17:52:44
|
Alan Hourihane wrote: > On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: > >>On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>Jacek Poplawski wrote: >>> >>>>On 5/30/06, Pedro Maia <ped...@ne...> wrote: >>>> >>>> >>>>> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 >>>>> >>>>>In my case it works fine, with that trick , without it didn't work. >>>> >>>>But why it didn't work? It opens /usr/lib/libGL.so for sure, because >>>>without >>>>it even software accelerated OpenGL doesn't work in the game. >>>>Quake2 is the only application I tried which loads libGL with dlopen. >>> >>>I think the way that Quake2 dlopens libGL prevents some symbols in libGL >>>from being exposed to the driver. I seem to remember alanh mentioning >>>something about this, but I don't recall the details. My dlopen-fu is >>>lacking, so I'm not sure what the problem or the solution might be. >> >>Basically, what happens is this.... >> >>A game may try to dlopen libGL itself at runtime rather than linking at >>build time. >> >>So, the linux dllinker does not bother to search for symbols to resolve >>that exist in the DRI driver. I'm not sure exactly why it doesn't >>though. > > > Actually I do remember my theory.... > > When a program is linked at build time, libGL is the one responsible for > dlload'ing the DRI driver and resolves symbols perfectly well with the > current RTLD flags. > > But when the program dlopen's libGL itself, it resolves what it > currently has access to which the DRI driver isn't actually loaded. I > suspect for this to work the libGL's dlinit() routine (that's called > when dlopen'ed) would need to someone link in the correct DRI driver at > that time - but I'm pretty sure all the available details to do that > wouldn't be available. > > I don't think there's any easy fix, which is why I resorted to the > LD_PRELOAD approach. > > This may all be bogus though. This sounds related to the -Bsymbolic linker option. When you build a shared library, the -Bsymbolic option tells the linker to resolve references in the shared library to symbols defined within the library, in preference to other locations. For example, if libGL had a function called init_driver(), -Bsymbolic would ensure that references to init_driver() were resolved to that function, and not another init_driver() function that might be defined in the application itself. The lack of -Bsymbolic in some libraries has caused me grief in the past. I've also raised this issue with some commercial OpenGL vendors. -Brian |
From: Adam K K. <ad...@vo...> - 2006-06-06 01:21:51
|
Brian Paul wrote: > Alan Hourihane wrote: > >> On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: >> >> >>> On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: >>> >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Jacek Poplawski wrote: >>>> >>>> >>>>> On 5/30/06, Pedro Maia <ped...@ne...> wrote: >>>>> >>>>> >>>>> >>>>>> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 >>>>>> >>>>>> In my case it works fine, with that trick , without it didn't work. >>>>>> >>>>> But why it didn't work? It opens /usr/lib/libGL.so for sure, because >>>>> without >>>>> it even software accelerated OpenGL doesn't work in the game. >>>>> Quake2 is the only application I tried which loads libGL with dlopen. >>>>> >>>> I think the way that Quake2 dlopens libGL prevents some symbols in libGL >>>> >>> >from being exposed to the driver. I seem to remember alanh mentioning >>> >>>> something about this, but I don't recall the details. My dlopen-fu is >>>> lacking, so I'm not sure what the problem or the solution might be. >>>> >>> Basically, what happens is this.... >>> >>> A game may try to dlopen libGL itself at runtime rather than linking at >>> build time. >>> >>> So, the linux dllinker does not bother to search for symbols to resolve >>> that exist in the DRI driver. I'm not sure exactly why it doesn't >>> though. >>> >> Actually I do remember my theory.... >> >> When a program is linked at build time, libGL is the one responsible for >> dlload'ing the DRI driver and resolves symbols perfectly well with the >> current RTLD flags. >> >> But when the program dlopen's libGL itself, it resolves what it >> currently has access to which the DRI driver isn't actually loaded. I >> suspect for this to work the libGL's dlinit() routine (that's called >> when dlopen'ed) would need to someone link in the correct DRI driver at >> that time - but I'm pretty sure all the available details to do that >> wouldn't be available. >> >> I don't think there's any easy fix, which is why I resorted to the >> LD_PRELOAD approach. >> >> This may all be bogus though. >> > > This sounds related to the -Bsymbolic linker option. > > When you build a shared library, the -Bsymbolic option tells the > linker to resolve references in the shared library to symbols defined > within the library, in preference to other locations. > > For example, if libGL had a function called init_driver(), -Bsymbolic > would ensure that references to init_driver() were resolved to that > function, and not another init_driver() function that might be defined > in the application itself. > > The lack of -Bsymbolic in some libraries has caused me grief in the > past. I've also raised this issue with some commercial OpenGL vendors. > > -Brian > > > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > Just a quick FYI... Something has changed in my installation recently (in the last week) to create the need for LD_PRELOAD in games that previously didn't need it. I don't know if it's the 'apt-get upgrade' I did or the upgrade of the Mesa drivers, but suddenly Orbz and MarbleBlast, both of which previously worked fine, now need to be run with LD_PRELOAD. I imagine that this is going to become an even bigger issue as games and applications are added to KDE/Gnome/XFCE menus and users can't figure out why those applications are running so slowly. Adam |
From: Alan H. <al...@fa...> - 2006-06-07 11:23:21
|
On Thu, 2006-06-01 at 11:20 -0600, Brian Paul wrote: > Alan Hourihane wrote: > > On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: > > > >>On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: > >> > >>>-----BEGIN PGP SIGNED MESSAGE----- > >>>Hash: SHA1 > >>> > >>>Jacek Poplawski wrote: > >>> > >>>>On 5/30/06, Pedro Maia <ped...@ne...> wrote: > >>>> > >>>> > >>>>> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 > >>>>> > >>>>>In my case it works fine, with that trick , without it didn't work. > >>>> > >>>>But why it didn't work? It opens /usr/lib/libGL.so for sure, because > >>>>without > >>>>it even software accelerated OpenGL doesn't work in the game. > >>>>Quake2 is the only application I tried which loads libGL with dlopen. > >>> > >>>I think the way that Quake2 dlopens libGL prevents some symbols in libGL > >>>from being exposed to the driver. I seem to remember alanh mentioning > >>>something about this, but I don't recall the details. My dlopen-fu is > >>>lacking, so I'm not sure what the problem or the solution might be. > >> > >>Basically, what happens is this.... > >> > >>A game may try to dlopen libGL itself at runtime rather than linking at > >>build time. > >> > >>So, the linux dllinker does not bother to search for symbols to resolve > >>that exist in the DRI driver. I'm not sure exactly why it doesn't > >>though. > > > > > > Actually I do remember my theory.... > > > > When a program is linked at build time, libGL is the one responsible for > > dlload'ing the DRI driver and resolves symbols perfectly well with the > > current RTLD flags. > > > > But when the program dlopen's libGL itself, it resolves what it > > currently has access to which the DRI driver isn't actually loaded. I > > suspect for this to work the libGL's dlinit() routine (that's called > > when dlopen'ed) would need to someone link in the correct DRI driver at > > that time - but I'm pretty sure all the available details to do that > > wouldn't be available. > > > > I don't think there's any easy fix, which is why I resorted to the > > LD_PRELOAD approach. > > > > This may all be bogus though. > > This sounds related to the -Bsymbolic linker option. > > When you build a shared library, the -Bsymbolic option tells the > linker to resolve references in the shared library to symbols defined > within the library, in preference to other locations. > > For example, if libGL had a function called init_driver(), -Bsymbolic > would ensure that references to init_driver() were resolved to that > function, and not another init_driver() function that might be defined > in the application itself. > > The lack of -Bsymbolic in some libraries has caused me grief in the > past. I've also raised this issue with some commercial OpenGL vendors. It can't be this as the libGL we're using now is from Mesa, and mklib already add the -Bsymbolic for us. I'm not sure how the linker can resolve the symbol anyway. The fact that the application has dlopen'ed libGL and the linker doesn't even know which DRI driver to pull in to resolve at that time. Having an unresolvable symbol like _glapi_add_dispatch in libGL without libGL being able to do it's loadable DRI driver first maybe a bad thing. Unless some of the glibc folks can help resolve this one. Alan. |