Announcement

Collapse
No announcement yet.

Gaming With The Open-Source R500 Driver

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

  • Gaming With The Open-Source R500 Driver

    Phoronix: Gaming With The Open-Source R500 Driver

    From the release of Mesa 7.1 Release Candidate 1 to Multi-Pointer X being merged to master to the R500 3D milestone, it's been an exciting past 24 hours for the X.Org community. With the open-source 3D support for the Radeon X1000 "R500" GPUs now reaching a parity with the Mesa support for earlier ATI Radeon product families, more Linux users can now consider turning to an open-source driver (xf86-video-ati or xf86-video-radeonhd) for their video driver needs. In this article we are looking at what Linux games work thanks to this latest Mesa R500 support.

    http://www.phoronix.com/vr.php?view=12402

  • #2
    Not bad for the first try. Did not expect it yet, but nice to see. I do not own R500 (nor R600) to try this, but for some basic uses fglrx will be soon obsolete like compiz. I would compare it against Intel G33/G35 however when you start benchmarking after the rendering problems got fixed. One huge problem with Intel onboard is the missing GLSL support (somebody mentioned that it could work with 965G but can not verify this).

    Comment


    • #3
      This is probably a very sensitive subject, but I really wished they used more meaningful driver names.

      Radeon,RadeonHD, and something with ATi...

      What not something like amdgpu? As AMD is going to open all their GPU's.

      Comment


      • #4
        there is already "amd" x.org driver for some integrated amd video chips. ( xf86-video-amd )

        bsically there is xf86-video-ati aka radeon for all ati cards
        and radeonhd for >=r500 cards.

        that's simple enough for me.

        Comment


        • #5
          Driver names are like coding standards; it's hard to agree on a change but it's easy to agree to keep doing what you're doing today

          ati is a wrapper which automatically loads radeon, r128 or mach64 depending on the PCI ID. All three drivers used to be in the -ati tree; r128 and mach64 have been split out, and at some point -ati might get renamed to -radeon but not sure it's worth the effort and resulting confusion.

          radeonhd is a separate driver, but many distros pick them both radeonhd and radeon.

          re: AMD vs ATI, the GPUs are sold as ATI products so renaming to AMD didn't seem necessary. We also have the added delight that there is already a -amd X driver, for the graphics subsystem in the Geode processor.

          Comment


          • #6
            Well, I am confused never the less

            But perhaps it is not so important what the drivers are called, as long the user doesn't have to make a discussion what to use.

            I see the point in AMD><ATi. I bet AMD is saving the AMD brand for the fusion CPU's.

            About Gallium 3D. Are there any time frame when the new drivers will be ported over?

            Comment


            • #7
              Originally posted by Louise View Post
              About Gallium 3D. Are there any time frame when the new drivers will be ported over?
              Once we have basic 6xx 3D running, which shouldn't be long, I expect that most of the 3D effort will shift to Gallium. We'll need a good memory manager in the drm driver first (see TTM/GEM discussion), so I imagine that will be the first task.

              The hardware changes from 5xx to 6xx are larger than from 4xx to 5xx, but the recent work on 5xx will be a huge help because the devs are now (painfully ) familiar with Mesa code and know what needs to be done for 6xx. We're also trying to dig up some sample code to help speed up the initial 6xx work.

              Comment


              • #8
                Originally posted by bridgman View Post
                Once we have basic 6xx 3D running, which shouldn't be long, I expect that most of the 3D effort will shift to Gallium. We'll need a good memory manager in the drm driver first (see TTM/GEM discussion), so I imagine that will be the first task.

                The hardware changes from 5xx to 6xx are larger than from 4xx to 5xx, but the recent work on 5xx will be a huge help because the devs are now (painfully ) familiar with Mesa code and know what needs to be done for 6xx. We're also trying to dig up some sample code to help speed up the initial 6xx work.
                This is surely exciting stuff

                What is not quite clear to me is will Gallium completely replace Mesa, sort of xorg replacing xfree86?

                Btw. Is the main purpose of switching to Gallium to move some of the driver code into the kernel? Or is performance the driving force?

                Comment


                • #9
                  is ati planning to devote some extra paid developers to work on gallium/mesa once ttm/gem and gallium api dust settles?

                  Comment


                  • #10
                    Gallium is really a new standard for implementing the hardware acceleration parts of Mesa. As far as I know the resulting code will still be called Mesa, just "the new, improved, post-Gallium Mesa"

                    I'm probably missing a key benefit or two (sorry guys) but the main benefits seem to be :

                    - the code which used to be required for a Mesa driver is being split into three parts (state tracker, driver, winsys) and only one of those parts will need to change from one GPU to the next

                    - the driver structure is designed for modern shader-based GPUs, while the current Mesa structure is designed around the GPUs of the time, which implemented a full fixed-function OpenGL pipeline

                    - the new structure will make support of OpenGL 2.x and higher easier since it won't be tied as strongly to the fixed-function pipeline

                    - it's new and cool and everyone wants to work on it

                    Gallium itself does not really move any code into the kernel.

                    Comment


                    • #11
                      Originally posted by yoshi314 View Post
                      is ati planning to devote some extra paid developers to work on gallium/mesa once ttm/gem and gallium api dust settles?
                      No "extra" paid developers but the ones we have will shift from "Classic Mesa" to Gallium. Most of the knowledge gained by working on the current Mesa will carry right over to Gallium.

                      TTM/GEM implementation will be a pre-requisite for Gallium (and lots of other things) so that will be the first task.
                      Last edited by bridgman; 05-28-2008, 05:00 PM.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        Gallium is really a new standard for implementing the hardware acceleration parts of Mesa. As far as I know the resulting code will still be called Mesa, just "the new, improved, post-Gallium Mesa"

                        I'm probably missing a key benefit or two (sorry guys) but the main benefits seem to be :

                        - the code which used to be required for a Mesa driver is being split into three parts (state tracker, driver, winsys) and only one of those parts will need to change from one GPU to the next

                        - the driver structure is designed for modern shader-based GPUs, while the current Mesa structure is designed around the GPUs of the time, which implemented a full fixed-function OpenGL pipeline

                        - the new structure will make support of OpenGL 2.x and higher easier since it won't be tied as strongly to the fixed-function pipeline

                        - it's new and cool and everyone wants to work on it

                        Gallium itself does not really move any code into the kernel.
                        I really love the Linux spirit. If it isn't broken, open it, and fix it

                        Thanks for explaining Gallium to me. I had it mixed up with kernel-based mode-setting

                        ... Which is guess is a separate project to move some of the Gallium code in to the kernel...?

                        Comment


                        • #13
                          Originally posted by Louise View Post
                          I really love the Linux spirit. If it isn't broken, open it, and fix it
                          It's sort of become broken over the years; the GPUs changed completely but the driver model did not keep up. Gallium seems to fix that nicely.

                          Originally posted by Louise View Post
                          Thanks for explaining Gallium to me. I had it mixed up with kernel-based mode-setting

                          ... Which is guess is a separate project to move some of the Gallium code in to the kernel...?
                          Kernel based modesetting moves modesetting (display-related) code from the X driver to the kernel (aka drm)

                          TTM/GEM moves memory management from the X driver to the kernel (drm) and makes it mo' better

                          DRI2 moves everything around a little bit between X driver, drm and mesa but the general direction seems to be kernel-ward again.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            Kernel based modesetting moves modesetting (display-related) code from the X driver to the kernel (aka drm)

                            TTM/GEM moves memory management from the X driver to the kernel (drm) and makes it mo' better

                            DRI2 moves everything around a little bit between X driver, drm and mesa but the general direction seems to be kernel-ward again.
                            It's very impressive! Who keeps track of what and when to do it?

                            Does AMD have a roadmap/"prioritized list" of what they would like to see done and when?

                            Comment


                            • #15
                              I am wondering...

                              Is is possible to play movies with these drivers at this state? If, what output device in MPlayer would be the recommended?

                              In regards to power consumption. Nouveau is planning on adding "Power Saving". Will that be possible in the OSS ATi 3D drivers? If, how many procent are we talking about? Approx of course

                              /HyggeMonster/

                              Comment

                              Working...
                              X