Hi,
I'm having some trouble running WOG on Sidux (a 'tweaked' version of Debian Sid) - performance is horribly low, around 12 fps. I *am* on Intel GMA 950 (Toshiba Portege r500), but I believe this should still be able to cope. I'm leaning towards a missing ia32 compatibility library and therefore the game reverting to software rendering, but have no way to be sure - the game doesn't seem to be logging anything of interest.
What's the best way to go about solving this?
Thanks,
Jarrad |
The Linux port of the game relies heavily on OpenGL for rendering, which the GMA 900/950 cards don't support too well, so maybe that is the problem. On the other hand, others reported the game to be "slow, but playable" with an Intel GMA 900 (albeit on a desktop computer), so it might be worth trying.
Quote: I'm leaning towards a missing ia32 compatibility library and therefore the game reverting to software rendering, but have no way to be sure - the game doesn't seem to be logging anything of interest.
This could well be the source of the problem. The easiest way to try this out might be to get a 32-bit (!) version of glxinfo, and see what it reports. Typically, if you're only missing some 32-bit drivers, the 64-bit version would print "Direct Rendering: yes" (and a lot more other stuff) while the 32-bit version would print "Direct Rendering: no" (resulting in bad performance as you reported). I think you need at least the mesa-dri package to get direct rendering to work, although I don't know if the 64-bit Debian package includes 32-bit compatibility libraries too. |
Debian has a bunch of compatibility libraries in a separate package, ia32-libs; apt-file reports i915_dri.so is one of them .
However, running i386 glxinfo (great idea btw) indeed reports that there is no DRI; setting LIBGL_DEBUG to verbose reports that it's trying to use /usr/lib/dri/i915_dri.so, which is of course the amd64 version (i386 libs are stored in /emul/ia32-linux/usr/lib, which /usr/lib32 is a link to). LD_PRELOADing /usr/lib32/dri/i915_dri.so simply gives 'object cannot be preloaded: ignored'. So... why? :D
Last modified Fri, 03/27/2009 - 20:36 by Akdor 1154 |
Ohkay.
Moving /usr/lib/dri/i915_dri.so to a backup and replacing it with the x86 version works perfectly - x86 glxinfo reports DRI= ;D and WorldOfGoo runs fantasmically. So. wtf is going on?
Why is the /usr/lib version being preferred, and why can't I just LD_PRELOAD the x86 version? (I know this isn't a problem with your package, Soultaker, but you might know anyway :)) |
To be honest, I don't have a great understanding of what is going on exactly on your system, but I can certainly guess some more.
How are you starting the game? If you use the wrapper script at /opt/WorldOfGoo/WorldOfGoo then it makes sense that you cannot LD_PRELOAD any 32-bit libraries since this script will be run by a 64-bit interpreter. The easiest fix would then be to add the LD_PRELOAD stuff in that script; a bit of a kludge (you have to remember to do it again if you ever reinstall the game) but OK. Come to think of it, an even easier way might be to symlink the i915_dri.so into the /opt/WorldOfGoo/libs subdirectory.
However, all of this doesn't explain why LD_PRELOAD wouldn't work with the 32-bit glxinfo (which I assume is not a script). Maybe Intel's OpenGL driver is dlopen()ing the library directly from the (incorrect) /usr/lib path? If this is the case, then I don't know a proper fix for it. At any rate, the game itself doesn't depend on this library, so it must be pulled in by your OpenGL library, either as a library dependency or at runtime (with dlopen()).
On a different note, I'm glad to hear the game works on your set-up; the Intel GMA is definitely on the low end of the graphics hardware spectrum, so it's nice to hear the game still runs well with it (at least when you're able to get the driver set-up apparently ;)) |
Yep, I arrived at a similar conclusion (though didn't realize the reason why the wrapper script didn't like the preload) - a little birdy called LD_DEBUG tweeted in my ear
"file=/usr/lib/dri/i915_dri.so [0]; needed by /usr/lib32/libGL.so.1 [0]"
zing!
I'll google first, then file a bug with the ia32-libs packages.[me=Akdor 1154]adds learning c/++ to TODO list[/me]
LD_PRELOADing in the wrapper on the plus side doesn't give the linker errors, but on the minus side doesn't do anything else, either. :)
Thanks for your help (and the port in the first place :)) |
Just a follow up (and workaround, yay!): I reported this to the Debian compatibility package, who then reassigned it to the mesa people, who then said it was the compatibiltiy libs' people's problem to fix, who then said no maybe they could do it themselves... etc.
On the plus side though it emerges from the discussion there that there's a workaround - a variable can be exported called LIBGL_DRIVERS_PATH that has the effect you would presume it to have. Adding
export LIBGL_DRIVERS_PATH=/usr/lib32/dri to the WoG wrapper = big win, and until the Debian maintainers deal with this it's the best solution to this problem (and for those on Debian Stable may be the only one for a few years). :) Thanks for your help in tracking this down, Soultaker.
For anyone who's interested, the bug is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521623
-Jarrad |
You are viewing a static copy of the old 2DBoy forum, which closed in 2010. It is preserved here for historical interest, but it is not possible to reply to topics. For more recent discussion about World of Goo, visit our new forum.