Announcement

Collapse
No announcement yet.

Looking for a brief descirption of the different radeon drivers available.

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

  • Looking for a brief descirption of the different radeon drivers available.

    Hi all,

    My last primarily linux system had an Intel Q35 motherboard (GMA3100 gpu I think) and a Geforce 7900Gt. So I'm fairly clear on the driver situation both open source and bin blob in Intel and nVidia's camp.

    But I'm a little mystified on the Radeon side of things, and it seems all my hardware is Radeon now.

    I'm just trying to get a handle on what drivers exist in Radeon land. So I see AMD releases binary blobs under the Catalyst name. Is that the same thing as the fglrx driver? Or are those two different drivers AMD puts out?

    xf86-video-radeon, xf86-video-radeonhd, xf86-video-ati ! Where do I start? Are all the drivers that start x86-video-* open source? And which ones apply to what?

    My main system runs a 785G chipset (RadeonHD 4200 I think?) with a Radeon 4870 add in card. I probably don't care about the 4200 in that, I'm unlikely to take the 4870 out, but it's nice to know what drivers apply still. This system current has Ubuntu 10.04 with the Catalyst drivers, and it's...okay. This machine dual boots Win7 and spends a lot of it's time in Windows land anyhow.

    My second system is destinited to be a media centre box that I don't want to dual boot if I can avoid it. Probably mythbuntu, but it has no OS at the moment, and I'm not set on that decision. It's an 880G / RadeonHD 4250 board.

    I'm considering adding a 5670 to the box for better performance, and I've heard AMD has had some movement on open source drivers lately. I'm not buying any more hardware for it at the moment, I have access to a 5670 for $0, I just haven't decided to use it yet or not.

    I understand a GeForce GT 430 with binary drivers is probably my best bet for media centre and I may go that way eventually but for now I'm going to tackle life as a Radeon user.

    I would *prefer* open source drivers, thus my interest in the 5670, but I've gone the binary route before if necessary. I'm not overly impressed with the Catalyst drivers at the moment, nVidia's binaries seem pretty good on the functionality end.

    Okay, so that was a long one, sorry for the stream of consciousness. Any input on the Radeon driver situation would be much appreciated.

  • #2
    I little searching these forums would have answered your questions, but I'll try to answer them anyway.

    Originally posted by jemason8 View Post
    I'm just trying to get a handle on what drivers exist in Radeon land. So I see AMD releases binary blobs under the Catalyst name. Is that the same thing as the fglrx driver? Or are those two different drivers AMD puts out?
    Catalyst and fglrx are the same thing. It supports R600+ based video cards.

    Originally posted by jemason8 View Post
    xf86-video-radeon, xf86-video-radeonhd, xf86-video-ati ! Where do I start? Are all the drivers that start x86-video-* open source? And which ones apply to what?
    Yes, they are open source.

    xf86-video-radeon supports R100-Evergreen series cards, and is in active development.
    xf86-video-radeonhd was the first driver to support R600 series cards, but development on this driver has basically stopped, afaik.
    xf86-video-ati is just a wrapper that will choose the appropriate driver for your card (Mach64, Rage128, or Radeon).

    Originally posted by jemason8 View Post
    My main system runs a 785G chipset (RadeonHD 4200 I think?) with a Radeon 4870 add in card. I probably don't care about the 4200 in that, I'm unlikely to take the 4870 out, but it's nice to know what drivers apply still. This system current has Ubuntu 10.04 with the Catalyst drivers, and it's...okay. This machine dual boots Win7 and spends a lot of it's time in Windows land anyhow.

    My second system is destinited to be a media centre box that I don't want to dual boot if I can avoid it. Probably mythbuntu, but it has no OS at the moment, and I'm not set on that decision. It's an 880G / RadeonHD 4250 board.

    I'm considering adding a 5670 to the box for better performance, and I've heard AMD has had some movement on open source drivers lately. I'm not buying any more hardware for it at the moment, I have access to a 5670 for $0, I just haven't decided to use it yet or not.
    Both machines would work with either the radeon or fglrx drivers. Depending on what your priorities are, you may like one over the other.


    Originally posted by jemason8 View Post
    I understand a GeForce GT 430 with binary drivers is probably my best bet for media centre and I may go that way eventually but for now I'm going to tackle life as a Radeon user.
    Yes, I think (no personal experience) that Nvidia drivers are best for media center PCs.

    Originally posted by jemason8 View Post
    I would *prefer* open source drivers, thus my interest in the 5670, but I've gone the binary route before if necessary. I'm not overly impressed with the Catalyst drivers at the moment, nVidia's binaries seem pretty good on the functionality end.
    The OSS radeon driver has excellent 2d, better than fglrx. It also does better at video playback, from what I hear. If 3d is your desire, fglrx is the only way to go at the moment.

    fglrx actually isn't that bad, and it is getting progressively better as time moves forward. I too would prefer OSS drivers, and use radeon on my laptop where 3d is of little importance.

    Comment


    • #3
      fglrx = Catalyst Linux... same thing

      The "ati" driver is a wrapper which looks at the hardware and loads either mach64, r128 or radeon depending on what it finds. All three of those drivers used to be in the -ati project tree but the first two were moved out a couple of years ago, so nowadays you just have the "radeon" driver and the "ati" wrapper" in the -ati project.

      The wrapper was required with old X versions (which IIRC chose a driver based only on PCI vendor ID) but these days you can just run "radeon".

      The "radeonhd" driver was started back in 2007 to kick off a new round of open source driver work... it was the most commonly used driver for r5xx and r6xx hardware but is gradually being replaced by Kernel Modesetting (KMS) code running in the Linux kernel along with the "radeon" driver.

      Today most distros use KMS plus the "radeon" driver. You also need an appropriate version of Mesa (in mesa/mesa, implements 3D acceleration) and libdrm (in mesa/drm).
      Test signature

      Comment


      • #4
        Yeah, I was fairly sure I was being redundant, I was just having trouble figuring out which particular keywords I wanted to be searching for.

        Thanks for humouring me and helping me out.

        Comment


        • #5
          If you want more information, there is a sticky thread in the OSS AMD forum written by Bridgman that is a lot more informative than I was earlier, and may better answer your questions.

          Comment


          • #6
            One caveat is that I have not been able to edit that post for a couple of years, so while the architectural info is still largely valid the "current driver status" should be read as "current in late 2008"
            Test signature

            Comment


            • #7
              That's a lot of the problem I've been having actually. As far as I can tell there's been a lot of movement in Radeon drivers lately, but most of the blog posts and what not I can find about it are well out of date.

              I think I'm getting a handle on it though.

              The open source radeon driver is the mesa/drm/kms one right? And is that the one AMD is supporting for the 5000 series? Or is that a purely community effort? You wrote something about it being mostly reverse engineered, but I know AMD/ATi has had varying degrees of open source support over the years.

              Also, regarding gallium3d, at this point are Radeon gallium drivers completely separate entities (r300g and r600g I believe?) or are those just names for different parts of the driver?

              Comment


              • #8
                OK, here's a mini-version of the sticky, updated...

                You need four open source components to get a complete driver stack :

                1. kernel driver aka drm - in the Linux kernel tree under drivers/gpu/drm - radeon specific code in "radeon" folder

                2. userspace interface library to kernel driver aka libdrm - in the mesa/drm project - radeon specific code in "radeon" folder

                3. X driver aka ddx aka radeon driver - in the xorg/driver/xf86-video-ati project - driver is completely radeon specific (other three components contain common code plus hw-specific subfolders)

                4. 3D driver aka GL driver aka Mesa - in the mesa/mesa tree - mesa supports two different HW driver APIs and 3D engine changes more than the rest of the radeon HW blocks so there are multiple HW driver trees within mesa :

                CLASSIC :

                radeon (r100/rv100/rv200 plus common code)
                r200
                r300
                r600

                GALLIUM3D :

                r300 (referred to as r300g to distinguish from classic r300)
                r600 (referred to as r600g to distinguish from classic r600)

                Classic HW drivers are in src mesa drivers dri, Gallium3D HW drivers are in src gallium drivers (my slash key isn`t working)

                Since there are a bunch of different components, and since the same `driver` may support multiple generations of hardware, and since the priority for our developers is (a) adding support for new hardware and (b) supporting the community developers, and since the word `support` can have many meanings, describing `what we support` is not a trivial task

                The initial r300 support (r300 the GPU family, not r300 the driver) was reverse engineered, but later on we provided documentation and Alex did quite a bit of work on the driver.

                The Gallium3D drivers (r300g, r600g) were written entirely by community developers (ie not by AMD employees), but made use of documentation from AMD and `classic` driver code which was partially written by AMD employees. We added new hardware support for everything up to Evergreen into the `classic` driver code simply because at the time the classic driver was already sufficiently mature for users while the r600g code was not (in fact it didn`t really exist until around the Evergreen timeframe).

                Now that the r600g code has reached approximate parity with the `classic` r600 driver we plan to do all new GPU support on the r600g code base instead of r600.

                Does that help ?
                Test signature

                Comment


                • #9
                  OK, keys are working again now after quitting & restarting browser.

                  The only way for this to be really clear is to poke around in the code a bit, so try the following (in the same order as above) :

                  1. kernel tree : http://git.kernel.org/?p=linux/kerne...radeon-testing

                  2. libdrm tree : http://cgit.freedesktop.org/mesa/drm/tree/

                  3. ddx tree : http://cgit.freedesktop.org/xorg/dri...ideo-ati/tree/

                  4. mesa tree : http://cgit.freedesktop.org/mesa/mesa/tree/

                  Within mesa, classic HW drivers are in src/mesa/drivers/dri while gallium3d HW drivers are in src/gallium/drivers. The mesa tree can be built so that it uses either classic or gallium3d HW driver code.

                  The term "HW driver" in this context refers to the fact that Mesa implements a very complex GL API so it has a large common code layer plus a smaller HW-specific layer. The same approach is used for the drm and libdrm projects; only the X driver projects are completely HW-specific.

                  (bridgman curses the edit time limit two more times)
                  Test signature

                  Comment


                  • #10
                    Hey thanks for the update and the source links.

                    Digging around in some driver code seems like a worthwhile way to spend some time, but it's good to have some road signs before you dive right in.

                    Comment

                    Working...
                    X