Announcement

Collapse
No announcement yet.

Radeon "R600g" Gallium3D Driver Merged To Master

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

  • #11
    This time they really do mean not ready...

    Originally posted by Melcar View Post
    So what if it's not ready? Has that ever stopped someone from using something? I don't see why the xorg-edgers ppa wouldn't consider offering a build of the driver in it's current state just for testing purposes.
    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...

    Comment


    • #12
      Originally posted by Jonno View Post
      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...
      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...

      Comment


      • #13
        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...
        It sort of goes against a virus goal if you crash the host machine beyond use. A virus job is to propogate first generally.

        If you want to write a useful virus against a graphics driver, just use nvidia.ko or fglrx.ko to get root.

        Dave.

        Comment


        • #14
          Funny viruses are awesome. Destructive ones are not.

          Can't wait for the 'eject disc drive for use as a cupholder' exploit :P

          Or pherhaps they framebuffer hardlock where the text "Arf! Arf! Arf! Gotcha!" keeps being displayed until you shutdown hard and unplug the powercable xD

          Comment


          • #15
            Originally posted by airlied View Post
            It sort of goes against a virus goal if you crash the host machine beyond use. A virus job is to propogate first generally.
            A lot of them propagate for a fixed time period and self-destruct later. Especially the ones written less for the purpose of making a botnet and more just to be a dickhole.

            Comment


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

                      Working...
                      X