Announcement

Collapse
No announcement yet.

(R500, radeon, x64) games segfaulting

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • (R500, radeon, x64) games segfaulting

    Hey folks, i'm not sure if this is the right forum to post, but my research has led me to believe that. If it should turn out that this i just forgot to switch on some obscure options, or it is actually the games' bugs, then feel free to move this thread.
    I'm currently running Ubuntu Jaunty with stock kernel (2.6.28-15, x64) and opensource radeon drivers & graphics stack from the xorg-edgers ppa, on a 64-bit system with a Radeon X1600 w/ 256 MB RAM.
    Openarena, compiz and the demos of ballistics and Postal 2 work like a charm, but the game that brought me to the whole thougt of playing on linux is hanging
    When i try to start the demo version of LGP's X2 port, i see the loading screen, then it turns blank, i hear the sounds of LGPs "intro movie", then silence and blank screen for 1-4 seconds, and then the game segfaults with a message like this:
    Code:
    x2-demo 1.4.05, built for i386
    Segmentation Fault: What do you mean mind the asteroid? What astero
    
    This is a BUG, please report it to http://support.linuxgamepublishing.com
    Stack dump:
    {
    	[0xf7f44400]
    	/usr/lib32/libGL.so.1 [0xf73dd9ad]
    	/usr/lib32/libGL.so.1 [0xf73dd5ce]
    	x2_demo [0x80f51b6]
    	x2_demo [0x80b7d87]
    	x2_demo(vfprintf+0x2aed) [0x805195d]
    	x2_demo(vfprintf+0x3830) [0x80526a0]
    	x2_demo [0x81009cf]
    	/lib32/libc.so.6(__libc_start_main+0xe5) [0xf7cb5775]
    	x2_demo(XMapRaised+0x31) [0x804ff91]
    }
    for two times in my hours of random trying, i achieved to see the following loading screen before the segfault. LGPs testtool gives some interesting results, though:
    Code:
     Testing installation... OK, installed at /usr/local/games/testtool
    Base system Test
    ----------------
    Testing architecture of system... 64 bits
    Testing system CPU... 2794MHz
    Testing CPU flags... MMX SSE SSE2 
    Testing system memory... -298MB
    
    Graphics Test
    -------------
    Looking for OpenGL library
    Rejecting /usr/lib/libGL.so.1 - wrong architecture
    Rejecting /usr/lib/libGL.so.1.2 - wrong architecture
    Accepting /usr/lib32/libGL.so.1
      Card detected as DRI R300 Project Mesa DRI R300 (RV530 71C3) 20090101  TCL
      Direct Rendering: No
      Card memory detected as 256MB
      Card antialiasing level 0x
      Card anisotropic level 16x
      Card shader level 2.0
    note the "direct rendering: No", whereas glxinfo returns
    Code:
    wirrbel@Datenschaufel:~$ glxinfo | grep direct
    direct rendering: Yes
    .
    the syslogs also show nothing suspicious. Results are the same with stock graphics stack.
    I think i have installed all the necessary libraries for running 32-bit apps on 64-bit systems, as well as all the old libraries required by LGPs installers (the script getlibs was a great help).
    However, the demo runs fine (well, at slideshow-speed, but playable) on my EEE pc 4G, which has its integrated Intel graphic chip, an even older kernel and a 32-bit system.

    My questions now are:
    1. From my limited knowledge, a segfault often points to a memory problem. Could a custom compiled 2.6.31 kernel with enabled GEM/TTM bring help?
    2. Could this segfault be a result of some animosity between 32-bit app and 64-bit system? i have 8 GB RAM installed, so perhaps there lies a source of trouble.
    3. Could it be that the drivers' OpenGL implementation (somewhere at OpenGL v. 1.4 IIRC) just not yet fulfils the games' needs?
    4. Might there be some arcane option in the xorg.conf or elsewhere, for direct rendering, shadowfb or something else? currently my xorg.conf has no customized entries.

    Any hint is appreciated

    wirrbeltier

  • #2
    I'm guessing here too, but in the "Graphics Test" portion of your second quote it looks like the "normal" libGL is being skipped in favor of one in lib32. What I'm not sure is if that means you're skipping the nice new (64-bit) mesa you installed from the edgers ppa and picking up an old 32-bit mesa, or if the ppa gave you a 32-bit lib as well and the libGL.so files being skipped are old junk from a previous installation.

    My guess is the first option, ie that this has something to do with 64 vs 32 bit.

    Have you reported it to linuxgamepublishing ?

    Comment


    • #3
      Code:
      dpkg-deb -c libgl1-mesa-glx_7.6.0+git20090906.97787317-0ubuntu0tormod~jaunty_amd64.deb | grep GL
      -rw-r--r-- root/root    523048 2009-09-06 01:01 ./usr/lib/libGL.so.1.2
      lrwxrwxrwx root/root         0 2009-09-06 01:01 ./usr/lib/libGL.so.1 -> libGL.so.1.2
      So this is the lib that xorg-edgers ships and which should be used on a 64-bit system. I have no experience with 64 bit and I am not sure what should happen when you run 32-bit apps on them though. Where is the other lib coming from?
      Code:
      dpkg -S /usr/lib32/libGL.so.1
      For your question (1) about the kernel: Why don't you just install the newest Karmic kernel? You can keep the old, and choose between them at boot.

      Comment


      • #4
        Originally posted by wirrbeltier View Post
        Hey folks, i'm not sure if this is the right forum to post, but my research has led me to believe that. If it should turn out that this i just forgot to switch on some obscure options, or it is actually the games' bugs, then feel free to move this thread.
        I'm currently running Ubuntu Jaunty with stock kernel (2.6.28-15, x64) and opensource radeon drivers & graphics stack from the xorg-edgers ppa, on a 64-bit system with a Radeon X1600 w/ 256 MB RAM.
        Openarena, compiz and the demos of ballistics and Postal 2 work like a charm, but the game that brought me to the whole thougt of playing on linux is hanging
        When i try to start the demo version of LGP's X2 port, i see the loading screen, then it turns blank, i hear the sounds of LGPs "intro movie", then silence and blank screen for 1-4 seconds, and then the game segfaults with a message like this:
        Code:
        x2-demo 1.4.05, built for i386
        Segmentation Fault: What do you mean mind the asteroid? What astero
        
        This is a BUG, please report it to http://support.linuxgamepublishing.com
        Stack dump:
        {
        	[0xf7f44400]
        	/usr/lib32/libGL.so.1 [0xf73dd9ad]
        	/usr/lib32/libGL.so.1 [0xf73dd5ce]
        	x2_demo [0x80f51b6]
        	x2_demo [0x80b7d87]
        	x2_demo(vfprintf+0x2aed) [0x805195d]
        	x2_demo(vfprintf+0x3830) [0x80526a0]
        	x2_demo [0x81009cf]
        	/lib32/libc.so.6(__libc_start_main+0xe5) [0xf7cb5775]
        	x2_demo(XMapRaised+0x31) [0x804ff91]
        }
        for two times in my hours of random trying, i achieved to see the following loading screen before the segfault. LGPs testtool gives some interesting results, though:
        Code:
         Testing installation... OK, installed at /usr/local/games/testtool
        Base system Test
        ----------------
        Testing architecture of system... 64 bits
        Testing system CPU... 2794MHz
        Testing CPU flags... MMX SSE SSE2 
        Testing system memory... -298MB
        
        Graphics Test
        -------------
        Looking for OpenGL library
        Rejecting /usr/lib/libGL.so.1 - wrong architecture
        Rejecting /usr/lib/libGL.so.1.2 - wrong architecture
        Accepting /usr/lib32/libGL.so.1
          Card detected as DRI R300 Project Mesa DRI R300 (RV530 71C3) 20090101  TCL
          Direct Rendering: No
          Card memory detected as 256MB
          Card antialiasing level 0x
          Card anisotropic level 16x
          Card shader level 2.0
        note the "direct rendering: No", whereas glxinfo returns
        Code:
        wirrbel@Datenschaufel:~$ glxinfo | grep direct
        direct rendering: Yes
        .
        There are many problems that might have same results as your. testtool is 32bit app.

        First of all, /usr/lib32/libGL.so.1 might not seek dri drivers in /usr/lib32/dri but only in /usr/lib/dri.
        You can try to fix it by setting this:
        LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri
        eg.
        Code:
        LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri /usr/local/games/testtool
        But 32bit glxinfo might be better.

        I think it might be your problem, but I'm not sure.

        Second, /usr/lib32/dri/r300_dri.so (and/or /usr/lib32/libGL.so.1) might be just to old/incompatible with rest of the system.
        Solution is to install newer one.
        Less likely, as library looks(from testtool output) quiet new, but still possible.

        In debian I have 32bit mesa installed
        Code:
        LANG=C ia32-apt-cache policy ia32-libgl1-mesa-glx
        ia32-libgl1-mesa-glx:
          Installed: 7.5-3~22
          Candidate: 7.5.1-1~22
          Version table:
             7.5.1-1~22 0
                400 http://ftp.pl.debian.org unstable-i386/main Packages
         *** 7.5-3~22 0
                100 /var/lib/dpkg/status
             7.0.3-7~22 0
                400 http://ftp.pl.debian.org testing-i386/main Packages
        
        Now I use mesa from git, but earlier I have used package.
        Snippet from apt-cache:
        Code:
        ia32-apt-cache search mesa libgl ia32
        ia32-libgl1-mesa-dev - A free implementation of the OpenGL API -- GLX development files
        ia32-libgl1-mesa-dri - A free implementation of the OpenGL API -- DRI modules
        ia32-libgl1-mesa-dri-dbg - Debugging symbols for the Mesa DRI modules
        ia32-libgl1-mesa-glx - A free implementation of the OpenGL API -- GLX runtime
        ia32-libgl1-mesa-glx-dbg - Debugging symbols for the Mesa GLX runtime
        (more...)
        Third, radeon.ko doesn't support compat ioctl(no 32bit ioctls for 32bit binaries on 64bit kernel) while KMS is enabled. I have only found It on KMS-enabled kernels(2.6.31) eg. KMS must be running. Like I said only on 2.6.31.

        And many more.

        Easiest way to find source of you problem is to get 32bit version of glxinfo and run it:
        LIBGL_DEBUG=verbose glxinfo 1>/dev/null
        Output should include only debug info.
        You might also want to try LIBGL_DRIVERS_PATH trick.
        Comparing full output of 32bit glxinfo with 64bit one might be also useful.

        Originally posted by wirrbeltier View Post
        the syslogs also show nothing suspicious. Results are the same with stock graphics stack.
        I think i have installed all the necessary libraries for running 32-bit apps on 64-bit systems, as well as all the old libraries required by LGPs installers (the script getlibs was a great help).
        getlibs is not a tool that you want to use.
        I bet Ubuntu have a tool to install 32bit libraries alongside 64bit ones(debian have). Use it.

        Originally posted by wirrbeltier View Post
        My questions now are:
        1. From my limited knowledge, a segfault often points to a memory problem. Could a custom compiled 2.6.31 kernel with enabled GEM/TTM bring help?
        From my personal experience if you want to run 32bit opengl binaries on 64bit kernel, 2.6.31 kernel with GEM/TTM/KMS enabled, is not what you looking for.

        Originally posted by wirrbeltier View Post
        2. Could this segfault be a result of some animosity between 32-bit app and 64-bit system? i have 8 GB RAM installed, so perhaps there lies a source of trouble.
        I don't think so.

        Originally posted by wirrbeltier View Post
        3. Could it be that the drivers' OpenGL implementation (somewhere at OpenGL v. 1.4 IIRC) just not yet fulfils the games' needs?
        With git mesa(maybe 1.5 OpenGL dri1) I was able not only to start game but also fly in ship a bit.
        I didn't tested it more due to lack of time.

        Originally posted by wirrbeltier View Post
        4. Might there be some arcane option in the xorg.conf or elsewhere, for direct rendering, shadowfb or something else? currently my xorg.conf has no customized entries.
        If there is one I don't know about it.

        I assume that you have fully updated X2.

        Comment


        • #5
          Right, so tormod & folks should now go on packaging new versions of ia32-libgl1-mesa-* too?

          Comment


          • #6
            Originally posted by nanonyme View Post
            Right, so tormod & folks should now go on packaging new versions of ia32-libgl1-mesa-* too?
            Can the ia32-libs-tools package be of help?
            Description: Tools for converting i386 debs for amd64 and ia64
            On amd64 and ia64 the kernel is capable of executing i386
            binaries. For that to work with dynamically linked binaries the
            required 32bit libraries need to be available as well. This package
            contains tools to convert native i386 binary packages for use under
            amd64 or ia64.
            "32 bits ought to be enough for anyone"

            Comment


            • #7
              Originally posted by tormod View Post
              Can the ia32-libs-tools package be of help?


              "32 bits ought to be enough for anyone"
              Higher level tool, like ia32-apt-get is more useful than direct use of ia32-libs-tools. With one command you can install selected library or binary.

              ia32-apt-cache show ia32-apt-get
              Code:
              Package: ia32-apt-get
              Status: install ok installed
              Priority: extra
              Section: devel
              Installed-Size: 148
              Maintainer: Debian ia32-libs Team <pkg-ia32-libs-maintainers@lists.alioth.debian.org>
              Architecture: all
              Source: ia32-libs-tools
              Version: 22
              Depends: debconf (>= 0.5), ia32-libs-tools (>= 16)
              Recommends: fakeroot
              Conflicts: ia32-libs, ia32-libs-gtk
              Conffiles:
               /etc/apt/apt.conf.d/00ia32-apt-get 6a029c3534fc152548520ea796ff3493
              Description: Apt-get, aptitude and dpkg wrapper for on-the-fly conversion
               On amd64 and ia64 the kernel is capable of executing i386
               binaries. For that to work with dynamically linked binaries the
               required 32bit libraries need to be available as well. This package
               contains wrappers for apt-get, aptitude and dpkg that will enable you
               to install i386 packages and convert them as they are being installed.
              Installation of 32bit library comes down to typing:
              Code:
              ia32-aptitude install ia32-libgl1-mesa-dri ia32-libgl1-mesa-glx
              But only if there is ia32(normal i486 package) package available in repository.

              Comment


              • #8
                Originally posted by sobkas View Post
                Easiest way to find source of you problem is to get 32bit version of glxinfo and run it:
                LIBGL_DEBUG=verbose glxinfo 1>/dev/null
                Output should include only debug info.
                You might also want to try LIBGL_DRIVERS_PATH trick.
                Comparing full output of 32bit glxinfo with 64bit one might be also useful.
                I'm having the same issue with 32-bit programs using Ubuntu64 9.10 (I'm not using any 32-bit 3D programs, so the issue is purely academic right now). On Ubuntu, a lot of the Debian ia32 packages are combined into 'ia32-libs' package. I have this package installed and it provides 32-bit versions of mesa libGL and the DRI drivers (the DRI drivers are installed in /usr/lib32/dri).

                Even with the driver path trick, I cannot get 32-bit glxinfo to use direct rendering, and it seems like glxinfo doesn't even look in /usr/lib32:
                Code:
                $ LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri
                $ LIBGL_DEBUG=verbose ~/Desktop/glxinfo 1>/dev/null
                libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0)
                libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so
                libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
                libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: wrong ELF class: ELFCLASS64)
                libGL error: unable to load driver: r600_dri.so
                libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
                libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
                libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: wrong ELF class: ELFCLASS64)
                libGL error: unable to load driver: swrast_dri.so
                libGL error: reverting to indirect rendering
                Note that I have an RV710 and I'm using agd5f's DRM, so maybe my output isn't relevant here :\

                EDIT: I'll also add:
                Code:
                $ ldd glxinfo 
                	linux-gate.so.1 =>  (0xf7f82000)
                	libGL.so.1 => /usr/lib32/libGL.so.1 (0xf7eef000)
                	libm.so.6 => /lib32/libm.so.6 (0xf7ec7000)
                	libc.so.6 => /lib32/libc.so.6 (0xf7d6e000)
                	libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7c3f000)
                	libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7c2f000)
                	libXxf86vm.so.1 => /usr/lib32/libXxf86vm.so.1 (0xf7c29000)
                	libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf7c26000)
                	libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf7c20000)
                	libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf7c13000)
                	libpthread.so.0 => /lib32/libpthread.so.0 (0xf7bf9000)
                	libdl.so.2 => /lib32/libdl.so.2 (0xf7bf5000)
                	/lib/ld-linux.so.2 (0xf7f83000)
                	libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7bd7000)
                	libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7bd3000)
                	librt.so.1 => /lib32/librt.so.1 (0xf7bc9000)
                	libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7bc4000)
                Last edited by DanL; 09-06-2009, 04:02 PM.

                Comment


                • #9
                  It's still trying to load the 64bit libraries for you... Also the original issue was with r500 and is unrelated to yours. Also you must be doing the driver path wrong considering where it's looking for the driver.

                  Comment


                  • #10
                    Originally posted by DanL View Post
                    I'm having the same issue with 32-bit programs using Ubuntu64 9.10 (I'm not using any 32-bit 3D programs, so the issue is purely academic right now). On Ubuntu, a lot of the Debian ia32 packages are combined into 'ia32-libs' package. I have this package installed and it provides 32-bit versions of mesa libGL and the DRI drivers (the DRI drivers are installed in /usr/lib32/dri).

                    Even with the driver path trick, I cannot get 32-bit glxinfo to use direct rendering, and it seems like glxinfo doesn't even look in /usr/lib32:
                    Code:
                    $ LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri
                    $ LIBGL_DEBUG=verbose ~/Desktop/glxinfo 1>/dev/null
                    libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0)
                    libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so
                    libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
                    libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: wrong ELF class: ELFCLASS64)
                    libGL error: unable to load driver: r600_dri.so
                    libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
                    libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
                    libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: wrong ELF class: ELFCLASS64)
                    libGL error: unable to load driver: swrast_dri.so
                    libGL error: reverting to indirect rendering
                    Note that I have an RV710 and I'm using agd5f's DRM, so maybe my output isn't relevant here :\
                    You are making small mistake, that is unfortunately fatal. If you want to use shell variable, like you used above, you must export it first:

                    Code:
                    $ export LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri
                    $ LIBGL_DEBUG=verbose ~/Desktop/glxinfo 1>/dev/null
                    you can also put everything in one line:

                    Code:
                    LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri LIBGL_DEBUG=verbose ~/Desktop/glxinfo 1>/dev/null
                    In my example:
                    Code:
                    LIBGL_DRIVERS_PATH=/opt:/usr/lib32/dri:/usr/lib/dri LIBGL_DEBUG=verbose ia32-glxinfo 1>/dev/null
                    libGL: OpenDriver: trying /opt/tls/r300_dri.so
                    libGL: OpenDriver: trying /opt/r300_dri.so
                    libGL error: dlopen /opt/r300_dri.so failed (/opt/r300_dri.so: cannot open shared object file: No such file or directory)
                    libGL: OpenDriver: trying /usr/lib32/dri/tls/r300_dri.so
                    libGL: OpenDriver: trying /usr/lib32/dri/r300_dri.so
                    You can see that "/opt" and "/usr/lib32/dri" dirs are searched.

                    Comment


                    • #11
                      Upon further Reading of The F'ing Manual (c), the environment variable is named LIBGL_DRIVER_DIR, right?: http://dri.sourceforge.net/doc/UserDoc.html
                      Also the original issue was with r500 and is unrelated to yours.
                      My apologies if I thread-jacked and thanks to those who enlightened me.

                      Ok:
                      Code:
                      $ ~/Desktop/glxinfo 
                      name of display: :0.0
                      libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0)
                      libGL: OpenDriver: trying /usr/lib32/dri//tls/r600_dri.so
                      libGL: OpenDriver: trying /usr/lib32/dri//r600_dri.so
                      libGL error: dlopen /usr/lib32/dri//r600_dri.so failed (/usr/lib32/dri//r600_dri.so: cannot open shared object file: No such file or directory)
                      libGL error: unable to load driver: r600_dri.so
                      libGL: OpenDriver: trying /usr/lib32/dri//tls/swrast_dri.so
                      libGL: OpenDriver: trying /usr/lib32/dri//swrast_dri.so
                      display: :0  screen: 0
                      direct rendering: Yes

                      Comment


                      • #12
                        You probably didn't compile a 32bit dri library.

                        Comment


                        • #13
                          Originally posted by DanL View Post
                          Upon further Reading of The F'ing Manual (c), the environment variable is named LIBGL_DRIVER_DIR, right?: http://dri.sourceforge.net/doc/UserDoc.html
                          Wrong.
                          LIBGL_DRIVER_DIR isn't even in your link, LIBGL_DRIVERS_DIR is, but It didn't worked for me(actually it did, I just unset LIBGL_DRIVERS_PATH to make it). I'm sure that LIBGL_DRIVERS_PATH is working.
                          Originally posted by DanL View Post
                          My apologies if I thread-jacked and thanks to those who enlightened me.
                          Your problems looks similar, it doesn't mean that it will turn out to be similar. It can be completely different, but for now there is no data to say it is in one way or another.
                          After all OP might lack /usr/lib32/dri/r300_dri.so or libGL.so.1 wasn't searching for it there.

                          Originally posted by DanL View Post
                          Ok:
                          Code:
                          $ ~/Desktop/glxinfo 
                          name of display: :0.0
                          libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0)
                          libGL: OpenDriver: trying /usr/lib32/dri//tls/r600_dri.so
                          libGL: OpenDriver: trying /usr/lib32/dri//r600_dri.so
                          libGL error: dlopen /usr/lib32/dri//r600_dri.so failed (/usr/lib32/dri//r600_dri.so: cannot open shared object file: No such file or directory)
                          libGL error: unable to load driver: r600_dri.so
                          Install 32bit mesa that have r600 driver.

                          Originally posted by DanL View Post
                          Code:
                          libGL: OpenDriver: trying /usr/lib32/dri//tls/swrast_dri.so
                          libGL: OpenDriver: trying /usr/lib32/dri//swrast_dri.so
                          display: :0  screen: 0
                          direct rendering: Yes
                          http://www.phoronix.com/forums/showp...93&postcount=3
                          On Ubuntu, a lot of the Debian ia32 packages are combined into 'ia32-libs' package. I have this package installed and it provides 32-bit versions of mesa libGL and the DRI drivers (the DRI drivers are installed in /usr/lib32/dri).
                          I didn't saw this when I first time read your post. So I will answer it here. ia32-libs is old and definitely doesn't have R600 driver: r600_dri.so.
                          Install 32bit mesa that have r600 driver.
                          Last edited by sobkas; 10-10-2009, 11:41 PM.

                          Comment


                          • #14
                            That's assuming there's any packages that have support for r600... Otherwise you have to do --enable-32-bit to force building of 32bit libraries on a 64bit platform or however the build process for multilib goes...

                            Comment


                            • #15
                              Hooray, it works!
                              basically, sobkas' trick with pointing to /usr/lib32/dri did the trick for me:
                              First of all, /usr/lib32/libGL.so.1 might not seek dri drivers in /usr/lib32/dri but only in /usr/lib/dri.
                              You can try to fix it by setting this:
                              LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri
                              eg.
                              Code:
                              Code:
                              LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri /usr/local/games/testtool
                              now testtool outputs
                              Code:
                              Graphics Test
                              -------------
                              Looking for OpenGL library
                              Rejecting /usr/lib/libGL.so.1 - wrong architecture
                              Rejecting /usr/lib/libGL.so.1.2 - wrong architecture
                              Accepting /usr/lib32/libGL.so.1
                                Card detected as DRI R300 Project Mesa DRI R300 20060815 x86/MMX+/3DNow!+/SSE2 TCL
                                Direct Rendering: Yes
                                Card memory detected as 256MB
                                Card antialiasing level 0x
                                Card anisotropic level 16x
                                Card shader level 2.0
                              , notice the changed card capabilities and the direct rendering
                              I had to experiment a bit with some libraries (ia32-apt-get didn't work for me; the program wouldn't show up after installation, however the lists were fetched with the normal apt-get, and some mismatch error message was given. I suppose that has to do with some debian repositories that ia32-apt-get seemingly introduced into the repository-list. I didn't bother to investigate deeper and removed it again; the ia32-tools convert didn't work for me either).
                              After reinstalling ia32-libs, i could start the x2_demo and it worked. I'm trying to figure out what exactly prevented it in the first place, but as for now i suppose that some tinkering with getlibs previous to my first post here caused the stress.

                              Now, dpkg -S shows that all libs in /usr/lib32 i looked into came from ia32-libs (such as libGL, r300_dri, libdrm), and i look forward to buying the full game

                              The updated kernel from the xorg-edgers ppa didn't seem to have changed anything with regard to these games.

                              If i find out what caused the games to (mal) function, i'll also post it in this thread.

                              Comment

                              Working...
                              X