Announcement

Collapse
No announcement yet.

Radeon "R600g" Gallium3D Driver Merged To Master

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

  • #21
    Originally posted by netkas View Post
    with 2.6.34 from radeon-testing branch it doesnt hardlock on glxgears
    I just tried this, and you're right, it doesn't hard lock the gpu. It will crash the entire system instead...

    I also retested using my old 2.6.32.9 kernel, wich still hard locks the graphics. I also tested my current 2.6.32.13 kernel with drm from 2.6.33.4, which gave me a system crash.

    Please note that I have a Radeon HD 2600 Pro. If you have a different GPU model you might have more luck than me...

    Comment


    • #22
      Originally posted by thalience View Post
      You seem to be saying that the CS checker should do more analysis than it currently does. While it may be possible to teach it to guard against the instruction pattern that causes this particular lockup, there are probably many others that fubar the GPU just as bad. The problem is analogous to determining if an x86 binary will segfault before you run it, AKA the halting problem.
      I'm not going to assume it's that complicated, though perhaps it is. For all we know, though, it's just a small set of commands that can cause such a hard lock, or something that's otherwise easy to check for.

      It seems to me (being uneducated in the inner workings of the hardware, of course) that this is more like a random program that can hard lock the kernel through a combination of syscalls rather than a program that just crashes itself. Or even worse, that a regular process could hard lock the entire CPU with some sequence of instructions. That would be total crap.

      If you told me a program could send a series of GPU commands that would crap out that rendering context but which the kernel could recover from, I wouldn't be too terribly worried. Only indirect rendering would suffer from a serious security flaw in that case, and then only if the GL library exposed such a weakness through the GLX API directly. However, if all processes have the ability to access the DRM through a library without going through another process (which is what we have here), and some particular stream of commands completely hard locks the GPU, then we have the situation where any process can hard lock the GPU either by accident or intent. That blows.

      If it can't be fixed with the command stream checker in the DRM, then in all honesty this may be a very strong argument for graphics drivers in kernel space or at least pushing towards a higher-performance pure-indirect-rendering approach. If the only capability that user processes have is to tell the graphics framework which high-level operations to perform and only privileged code can actually construct command sequences then the hardware security holes are not exploitable by user code. All of the arguments for keeping graphics code out of kernel space pretty much come down to the idea that having that code in user space is more secure and more stable; if that's blatantly not true, then the argument against in-kernel graphics drivers mostly evaporates. That is all a big "if" of course, dependent on the (unknown to me) specifics of what exactly can cause these hard locks.

      Comment


      • #23
        Pretty much any undefined or invalid GPU state may cause a hardlock. Yeah, in-kernel GPU drivers would help, but that would pretty much mean moving a large chunk of Mesa into kernel and I think there are licensing issues so it won't happen. There is a way out of this crap though: a locked GPU can be reset and reinitialized. I think there's even an r6xx lockup recovery in upstream kernel, 2.6.34 I guess?

        Comment


        • #24
          How do I test this?

          I have an Amilo Notebook Pa 3553 with ATi Mobility Radeon HD 3470 GPU
          and updated Fedora 13 with radeon.modeset=1

          After

          > ./autogen.sh --enable-gallium-radeon --enable-gallium-r300 --enable-gallium-r600 --disable-gallium-intel --with-dri-drivers=swrast,radeon,r300,r600
          > make

          I get in ...mesa/lib/gallium

          14408511 Jun 3 06:33 r600_dri.so
          15699789 Jun 3 06:33 radeong_dri.so
          15115557 Jun 3 06:33 swrastg_dri.so

          For r300_dri (which is not for my hardware) I would do in ...mesa/lib

          > cp gallium/radeong_dri.so ./r300_dri.so

          (or an equivalent linking).

          For r600_dri I did in ...mesa/lib

          > cp gallium/r600_dri.so ./r600_dri.so

          After this glxinfo crashes. Is this because I did wrong, or gallium
          r600 doesn't work for glxinfo yet?

          Comment


          • #25
            StephanB: No neeed to copy or link anything, just set the appropriate ennvironment variables. You ned to include the dir with libGL.so in LDPATH and set LIBGL_DRIVERS_PATH to the dir with the gallium r600_dri.so.
            env LDPATH="$SRCDIR/lib:$LDPATH" LIBGL_DRIVERS_PATH=$SRCDIR/lib/gallium glxinfo
            Replace $SRCDIR with the directory you checked out mesa in.

            For the record, my autogen.sh call looks like this, based upon the configure call in the gentoo ebuild, but this is probably overkill...
            ./autogen.sh --prefix=/usr/local --mandir=/usr/local/share/man --infodir=/usr/local/share/info --datadir=/usr/local/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/local/lib --disable-option-checking --with-driver=dri --disable-glut --without-demos --disable-debug --disable-glw --disable-motif --enable-glx-tls --enable-xcb --enable-asm --with-dri-drivers=swrast,r600 --enable-gallium --with-state-trackers=glx,dri --enable-gallium-swrast --enable-gallium-r600
            gmake

            Comment


            • #26
              Thanks for the reply.

              Hmm, doesn't work for me...

              After

              > export LIBGL_DRIVERS_PATH=/home/scb/Progs/mesa/lib
              > glxinfo|grep OpenGL

              gives me

              OpenGL vendor string: Advanced Micro Devices, Inc.
              OpenGL renderer string: Mesa DRI R600 (RV620 95C4) 20090101 TCL DRI2
              OpenGL version string: 2.0 Mesa 7.9-devel
              OpenGL shading language version string: 1.10
              OpenGL extensions:

              which is the normal mesa r600 driver, but a newer version than is default in Fedora 13, and it works fine with glxgears, gtkperf, ...

              After

              > export LIBGL_DRIVERS_PATH=/home/scb/Progs/mesa/lib/gallium

              glxinfo crashes.

              Comment


              • #27
                Originally posted by StephanB View Post
                Thanks for the reply.

                Hmm, doesn't work for me...

                After

                > export LIBGL_DRIVERS_PATH=/home/scb/Progs/mesa/lib
                > glxinfo|grep OpenGL

                gives me

                OpenGL vendor string: Advanced Micro Devices, Inc.
                OpenGL renderer string: Mesa DRI R600 (RV620 95C4) 20090101 TCL DRI2
                OpenGL version string: 2.0 Mesa 7.9-devel
                OpenGL shading language version string: 1.10
                OpenGL extensions:

                which is the normal mesa r600 driver, but a newer version than is default in Fedora 13, and it works fine with glxgears, gtkperf, ...

                After

                > export LIBGL_DRIVERS_PATH=/home/scb/Progs/mesa/lib/gallium

                glxinfo crashes.
                Given the immaturity of r600g, it seems quite reasonable for it to crash even with the simplest tests. By the way, does glxinfo print anything before crashing? Could you try running this (x86) or this (x64) and post the output? (It's just a simpler version of glxinfo, you can get the source from here and build it with
                gcc -lX11 -lGL -O2 test.c -o ginfo
                if you want). Thanks

                Comment


                • #28
                  Thanks again. Both glxinfo and ginfo-x64 print before their crash

                  name of display: :0.0
                  <<
                  VERT
                  DCL IN[0]
                  DCL IN[1]
                  DCL OUT[0], POSITION
                  DCL OUT[1], COLOR
                  0: MOV OUT[0], IN[0]
                  1: MOV OUT[1], IN[1]
                  2: END
                  --------------------------------------------------------------

                  BTW, in Fedora I have to

                  > export LD_LIBRARY_PATH="/home/scb/Progs/mesa/lib"

                  (not LDPATH) to get

                  > ldd /usr/bin/glxinfo
                  ...
                  libGL.so.1 => /home/scb/Progs/mesa/lib/libGL.so.1 (...

                  But glxinfo and ginfo-x64 crash with both libGL.so from Fedora 13 as well as latest libGl when LIBGL_DRIVERS_PATH points to gallium with r600_dri

                  Comment


                  • #29
                    Ok, so that's definitely a driver issue. It seems to print some sort of debug but it doesn't make much sense to me. It seems you will have to wait a bit

                    Comment


                    • #30
                      Seriously, don't try it now. It's so immature that it even shouldn't work...

                      Comment

                      Working...
                      X