Announcement

Collapse
No announcement yet.

Radeon Gallium on ubuntu

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

  • #91
    Yeah...that's what I meant

    Comment


    • #92
      -gallium package in xorg-edgers

      We now also have gallium packages in the main xorg-edgers PPA. The way it works here is a bit different than the radeon gallium PPA: The normal libgl1-mesa-dri contains only the classic mesa drivers. The libgl1-mesa-dri-gallium is an extra, optional package with gallium drivers. The libGL search path is set up so that the gallium drivers are loaded if the -gallium package is installed (Robert's clever idea).

      Note that the -gallium package in xorg-edgers also ship nouveau and intel gallium drivers.

      Comment


      • #93
        DRM version is 1.32.0 but this driver is only compatible with 2.x.x

        I tried using the xorg edgers PPA with the libgl1-mesa-dri-gallium package
        to test this driver with my Radeon 9800 PRO (R350) but I get this message when I run glxinfo:

        Code:
        glxinfo
        name of display: :0.0
        do_ioctls: DRM version is 1.32.0 but this driver is only compatible with 2.x.x

        Comment


        • #94
          Ah fixed it, I needed to remove the radeon.modeset=4 from the grub settings.

          Comment


          • #95
            Originally posted by Gerwin View Post
            I tried using the xorg edgers PPA with the libgl1-mesa-dri-gallium package
            to test this driver with my Radeon 9800 PRO (R350) but I get this message when I run glxinfo:

            Code:
            glxinfo
            name of display: :0.0
            do_ioctls: DRM version is 1.32.0 but this driver is only compatible with 2.x.x
            How is Gallium working on your card?
            I have Radeon 9600 (RV350) and X300 (RV370) and I'm thinking about giving a try of Gallium.

            Comment


            • #96
              Using libgl1-mesa-dri-gallium gives lots of artifacts on my r580. The corruption seems to show up only on GTK elements like the menus, text, toolbars.


              I have been testing r300g prior with xorg-edgers before this but using export LIBGL_DRIVERS_PATH. It worked with no artifacts when I put the export line in ~/.bashrc. When I tried putting the line in /etc/profile I got the same corruption that I do now. I discovered that for some reason symlinking to the radeong_dri.so directly in /usr/lib/dri results in no graphical corruption or artifacts.

              Comment


              • #97
                Damn edit times...


                To be clear, I forgot to mention that when I was using the LIBGL_DRIVER_PATH variable that I was compiling r300g as per the instructions in the second post.

                Comment


                • #98
                  Originally posted by rob2687 View Post
                  Using libgl1-mesa-dri-gallium gives lots of artifacts on my r580. The corruption seems to show up only on GTK elements like the menus, text, toolbars.


                  I have been testing r300g prior with xorg-edgers before this but using export LIBGL_DRIVERS_PATH. It worked with no artifacts when I put the export line in ~/.bashrc. When I tried putting the line in /etc/profile I got the same corruption that I do now. I discovered that for some reason symlinking to the radeong_dri.so directly in /usr/lib/dri results in no graphical corruption or artifacts.
                  Can you try moving /usr/lib/dri away and renaming dri-gallium/ to dri/ ? Using LIBGL_DRIVERS_PATH (or the compiled-in libGL path) has some limitations. For instance, compiz will not use this PATH unless you put it in the right place, /etc/environment should be safe. The xserver will grab the DRI driver in /usr/lib/dri anyway. It is possible we will do this differently in the future, for instance by having the -gallium package diverting /usr/lib/dri. Note that the radeon gallium PPA ships the gallium drivers in /usr/lib/dri instead of mangling the libGL path so you might try out those packages (on stock lucid).

                  For trying out your different locations of the export line, you can use this to see if compiz picks it up:
                  Code:
                  grep -z LIBGL /proc/$(pidof compiz)/environ

                  Comment


                  • #99
                    Originally posted by xeros View Post
                    How is Gallium working on your card?
                    I have Radeon 9600 (RV350) and X300 (RV370) and I'm thinking about giving a try of Gallium.
                    I noticed no differences, but I only tried Blender and that worked fine.

                    I am wondering how I can run this driver at AGP 4x, because running at 1x is slow. Setting AGPMode to 4x in xorg.conf does not seem to work...

                    I installed this driver because it has openGL 2.1 and that is necessary to run webGL. Unfortunately, I am still unable to run a webGL demo with this driver.

                    Comment


                    • Originally posted by tormod View Post
                      Can you try moving /usr/lib/dri away and renaming dri-gallium/ to dri/ ? Using LIBGL_DRIVERS_PATH (or the compiled-in libGL path) has some limitations. For instance, compiz will not use this PATH unless you put it in the right place, /etc/environment should be safe. The xserver will grab the DRI driver in /usr/lib/dri anyway. It is possible we will do this differently in the future, for instance by having the -gallium package diverting /usr/lib/dri. Note that the radeon gallium PPA ships the gallium drivers in /usr/lib/dri instead of mangling the libGL path so you might try out those packages (on stock lucid).

                      For trying out your different locations of the export line, you can use this to see if compiz picks it up:
                      Code:
                      grep -z LIBGL /proc/$(pidof compiz)/environ


                      Renaming dri-gallium to dri worked with no graphical corruption. I tried putting the LIBGL path in /etc/environment but it still shows the same graphic corruption. I checked the compiz pid in /proc and it picks up the LIBGL path too.

                      Comment

                      Working...
                      X