Announcement

Collapse
No announcement yet.

Radeon "R600g" Gallium3D Driver Merged To Master

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

  • #16
    Aww, nice work ! It's really great to see some r600+ work materializing again after quite a long time.

    And on gentoo there is a new eselect-mesa ebuild in the x11 overlay which makes switching between classic and gallium drivers a breeze ... wonderful :-)

    Comment


    • #17
      Originally posted by FireBurn View Post
      Calling people who use Ubuntu, Ubuntu folk isn't name calling.

      I'm pretty sure that only Ubuntu uses the term PPA for non-official repositories so I feel my comments were accurate. No one asked for something to be added to RPM fusion, Debian unstable, Mandivia cooker or a gentoo overlay.

      Whether or not you appreciate having your fellow Ubuntu users called out on bazaar (get it?) requests doesn't mean I wasn't right in doing so

      Ah sorry, I thought you called them Ubuntu users because they didn't have the patience to read through the article. I didn't feel attacked or something but I just hate the way newbs are treated by the community in general.

      Comment


      • #18
        Originally posted by Jonno View Post
        Please note that the current state is that it creates a file named "gallium.bof" in the working directory containing the instructions it should send to the gpu, but doesn't becouse they would cause the graphics card to hard lock.

        And when I say hard lock, I really do mean hard lock. A reboot of the system ("shutdown -r now") isn't enough. To get a working display you have to shut down ("shutdown -h now"), then pull out the power cord, wait half a second for all capacitors to run dry, put the cord back in and restart...
        with 2.6.34 from radeon-testing branch it doesnt hardlock on glxgears and many other demos

        also, removed dump of gallium.bof so it doesnt segfaults in ro folders.

        Comment


        • #19
          Originally posted by elanthis View Post
          That is actually damn impressive. Mainly in that commands submitted from a userspace library can actually do that. That's some awesome hardware design tempered with some pretty excellent command stream checking in the DRM layer.

          Someone explain to me again why Linux viruses aren't more common? Sounds like some pretty simple ones could be damn hilarious...
          I too am dismayed by the hardware's inability to recover from error conditions. Hopefully AMD's long-term plans to integrate GPU functions into their CPUs will result in more robust GPUs, rather than CPUs that completely shit themselves with certain instruction sequences.

          However, the kernel's command stream checker is focused on making sure that programs can't use GPU commands to access memory that doesn't belong to them. That doesn't seem to be a problem here.

          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.

          Since it isn't possible to solve the problem with full generality, how much CPU overhead would you accept in your graphics driver for little gain in stability?

          Comment


          • #20
            Originally posted by thalience View Post
            Since it isn't possible to solve the problem with full generality, how much CPU overhead would you accept in your graphics driver for little gain in stability?
            That depends on who you are and what you do.

            Comment


            • #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