Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 43

Thread: Radeon "R600g" Gallium3D Driver Merged To Master

  1. #21
    Join Date
    Nov 2008
    Posts
    77

    Unhappy

    Quote 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...

  2. #22
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote 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.

  3. #23
    Join Date
    Jan 2009
    Posts
    598

    Default

    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?

  4. #24
    Join Date
    May 2010
    Location
    Uppsala, Sweden
    Posts
    3

    Default

    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?

  5. #25
    Join Date
    Nov 2008
    Posts
    77

    Default

    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

  6. #26
    Join Date
    May 2010
    Location
    Uppsala, Sweden
    Posts
    3

    Default

    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.

  7. #27
    Join Date
    Dec 2009
    Location
    Italy
    Posts
    174

    Default

    Quote 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

  8. #28
    Join Date
    May 2010
    Location
    Uppsala, Sweden
    Posts
    3

    Default

    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

  9. #29
    Join Date
    Dec 2009
    Location
    Italy
    Posts
    174

    Default

    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

  10. #30
    Join Date
    Jan 2009
    Posts
    598

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •