Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 43

Thread: Radeon "R600g" Gallium3D Driver Merged To Master

  1. #11
    Join Date
    Nov 2008
    Posts
    77

    Exclamation This time they really do mean not ready...

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

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

    Default

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

  3. #13
    Join Date
    May 2007
    Posts
    314

    Default

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

  4. #14
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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

  5. #15
    Join Date
    Nov 2007
    Posts
    1,024

    Default

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

  6. #16
    Join Date
    Dec 2009
    Posts
    15

    Default

    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 :-)

  7. #17
    Join Date
    Sep 2008
    Posts
    270

    Default

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

  8. #18
    Join Date
    Aug 2009
    Posts
    122

    Default

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

  9. #19
    Join Date
    Dec 2009
    Posts
    12

    Default

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

  10. #20
    Join Date
    Jul 2009
    Posts
    19

    Default

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

Posting Permissions

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