nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   32bit programs w/AMD64 (http://www.nvnews.net/vbulletin/showthread.php?t=22753)

eswan 12-26-03 06:29 PM

32bit programs w/AMD64
 
How do I run 32bit GL programs that link against libGL with the 4499 AMD64 drivers? As far as I am aware, 32bit programs require 32bit libs, which on most AMD64 distributions is handled by having both 64 and 32 bit versions of the libraries in seperate directories (ie. /lib, /lib64, /usr/X11/lib, /usr/X11/lib64, etc.) It doesn't look like the 4499 driver set includes 32bit versions. Tried setting up the 4496 32bit libs (libGL.so.1.0.4496 and libGLcore.so.1.0.4496) in the /usr/lib directory, but I'm getting a 'NV: could not get NV card info (Invalid argument)' error.

# ldd `which glxgears32`
libGL.so.1 => /usr/lib/libGL.so.1 (0x55561000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x555ca000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x555d8000)
libpthread.so.0 => /lib/libpthread.so.0 (0x556d4000)
libm.so.6 => /lib/libm.so.6 (0x55727000)
libc.so.6 => /lib/libc.so.6 (0x5574a000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x55881000)
libdl.so.2 => /lib/libdl.so.2 (0x55d59000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

# ldd `which glxgears`
libGL.so.1 => /usr/lib64/libGL.so.1 (0x0000002a9566d000)
libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x0000002a957f2000)
libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x0000002a95904000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000002a95ae6000)
libm.so.6 => /lib64/libm.so.6 (0x0000002a95c7a000)
libc.so.6 => /lib64/libc.so.6 (0x0000002a95dd4000)
libGLcore.so.1 => /usr/lib64/libGLcore.so.1 (0x0000002a96016000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000002a96586000)
/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)

# glxgears32
NV: could not get NV card info (Invalid argument)
Error: glXCreateContext failed

# dmesg
........
ioctl32(glxgears32:23326): Unknown cmd fd(6) cmd(c14046c8){01} arg(555c9980) on /dev/nvidiactl

It's likely to take a while before 64bit versions of closed source software becomes available, (the postal2mp linux demo for example :)), and wine needs to be compiled 32bit at the moment.

Phorem 12-27-03 03:00 PM

I too was having that problem and i wrote a couple of emails to some people. One of the responses i got was from Ryan (over at icculus.org) and he said that any OpenGL application that was compiled for 32bit will NOT run on 64bit at all. Regardless of what lib's you have installed. OpenGL will only run on the system it was compiled for - i.e. 32bit. I sure hope UT2004 will have a Linux64 build (they will have a windoze 64bit build but forget about that).

eswan 12-29-03 07:25 PM

Just tried with the 32bit Mesa-5.0.1 libs and that works-

# glxinfo32
name of display: :0.0
display: :0 screen: 0
direct rendering: No
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 5.0.1
...

# glxgears32
997 frames in 5.0 seconds = 199.400 FPS
1091 frames in 5.0 seconds = 218.200 FPS
1093 frames in 5.0 seconds = 218.600 FPS
...

# glxinfo
glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.3
...

# glxgears
2578 frames in 5.0 seconds = 515.600 FPS
3835 frames in 5.0 seconds = 767.000 FPS
3937 frames in 5.0 seconds = 787.400 FPS
...
All in the same session. Even tried both at the same time- about 4 fps, but works.
Maybe there's problems using 32bit libs that try to use the 64bit DRI? Would like to hear from Nvidia on this- it'd be interesting to try a matching 64/32 set of libs. I'll have to try mismatched 32bit libs/kernel module on my 32bit system and see if I get the same 'unknown cmd' error.

Nvidia's scores seem low, mesa's seem high. Running at 3200x1200 dual head, 24bpp. glxgears with the nvidia driver seems to 'stall' badly when input focus changes. This is a dual cpu system (tyan K8W), so maybe it's taking a big hit
if the process changes cpus. More tweaking, have to lookup the 'stay on one cpu' magic.

eswan 12-30-03 07:12 PM

Found the secret incantation - export __GL_FORCE_DIRECT=0
Turns off direct rendering, which on my system doesn't seem to affect glxgears much.

Final setup-
64bit 2.6.0-test11 kernel w/x86-64 patches from ftp://ftp.x86-64.org/pub/linux/v2.6/
nvidia 4499 AMD64 kernel module w/minion.de patches
nvidia 4499 AMD64 X driver in /usr/X11R6/lib64/modules/drivers
nvidia 4499 AMD64 glx X11 module in /usr/X11R6/lib64/modules/extensions
nvidia 4499 AMD64 gl libraries in /usr/lib64
nvidia 5328 x86-32bit glx X11 module in /usr/X11R6/lib/modules/extensions (probably not needed, but I ain't movin it)
nvidia 5328 x86-32bit gl libraries in /usr/lib
__GL_FORCE_DIRECT set to 0

# glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: No
server glx vendor string: NVIDIA Corporation
server glx version string: 1.3
...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce FX 5200/AGP/SSE2/3DNOW!
OpenGL version string: 1.4.0 NVIDIA 44.99
...

# glxinfo32
name of display: :0.0
display: :0 screen: 0
direct rendering: No
server glx vendor string: NVIDIA Corporation
server glx version string: 1.3
...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce FX 5200/AGP/SSE2/3DNOW!
OpenGL version string: 1.4.0 NVIDIA 44.99 << hmm.....
...

# ldd `which glxinfo32`
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x55561000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x555de000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x5563a000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x55648000)
libpthread.so.0 => /lib/libpthread.so.0 (0x55744000)
libm.so.6 => /lib/libm.so.6 (0x55797000)
libc.so.6 => /lib/libc.so.6 (0x557bb000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x558f1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x559ae000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x559b6000)
libdl.so.2 => /lib/libdl.so.2 (0x55e61000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

# glxgears
3384 frames in 5.0 seconds = 676.800 FPS
3920 frames in 5.0 seconds = 784.000 FPS
4000 frames in 5.0 seconds = 800.000 FPS
4000 frames in 5.0 seconds = 800.000 FPS

# glxgears32
3460 frames in 5.0 seconds = 692.000 FPS
3920 frames in 5.0 seconds = 784.000 FPS
4000 frames in 5.0 seconds = 800.000 FPS
4000 frames in 5.0 seconds = 800.000 FPS

# export __GL_FORCE_DIRECT=1
# glxgears
2480 frames in 5.0 seconds = 496.000 FPS
3967 frames in 5.0 seconds = 793.400 FPS
4058 frames in 5.0 seconds = 811.600 FPS
4060 frames in 5.0 seconds = 812.000 FPS

# glxgears32
Error: glXCreateContext failed

Think I'll hit submit before a real test, just in case....

eswan 12-30-03 07:39 PM

...and it was a good idea. Haven't seen a spontaneous reboot in quite a while.
Tried the postal2mp demo again after the boot and no blowup, but now I'm getting-

Postal 2
Copyright 2003 Running With Scissors, Inc.
Unreal Engine
Copyright 2001 Epic Games, Inc.
GL_EXT_bgra not supported - bailing out.

History:

Exiting due to error
........

And sure enough, glxinfo32 is missing a big chunk of OpenGL extensions.
Ahhhh- switching back to the 4496 x86-32bit libs brings back the extensions. Weird, must be too big a mismatch between 5328 and 4499. Try, try again.

eswan 12-30-03 09:45 PM

So far:
postal2mpdemo - segfaults
wolfenstein - segfaults
ut2003demo - segfaults
ssamtse - works! mostly. Getting segfaults if I change too much from the defaults. Haven't nailed down exactly where yet.
And of course: tuxkart 32bit version works perfectly.

Switching to my singlehead 1024x768 xf86config I'm getting 1700-1750 glxgearmarks on both 64 and 32 bit versions. Not sure if the segfaults are because of the 4496-x86 <-> 4499-AMD64 mismatch or (quite likely) the default installed x11-32bit compatible libs not getting along with my recompiled x11-64bit environment. I'll have to try recompiling X11-32bit next.

eswan 12-31-03 06:58 PM

Recompiled X11 for 32-bit and merged in the libraries over the default install and now wolfenstien and postal2mp demo are running! ut2003demo is telling me that I'm missing the s3 texture compression extension, sigh. People running with a default distribution-installed version of X11-64/32 shouldn't have to recompile X, I just like to live that smidgen over the edge that keeps computing interesting :). Off to play...


All times are GMT -5. The time now is 03:44 AM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.