Announcement

Collapse
No announcement yet.

Mesa 7.5 Release Candidate 1 Now Available

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

  • Mesa 7.5 Release Candidate 1 Now Available

    Phoronix: Mesa 7.5 Release Candidate 1 Now Available

    Mesa 7.5 was supposed to be released in early April, but just a few days before that release the plans had changed. David Airlie really wanted to get his Radeon driver rewrite merged sooner rather than later, and some other changes were pending that also held up the Mesa 7.5 release.A change to the version numbering convention for the Mesa releases was proposed and accepted as well...

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

  • #2
    I'm really eager for a gallium3D-aware radeon driver !
    Hope this will happen soon, the radeon-rewrite branch is already full of promesses !

    Time has come to finally taste what the Xorg Guys have been working on for the last couple of years !
    Last edited by MPF; 05-08-2009, 08:05 PM.

    Comment


    • #3
      Or rather taste the end of xorg. That stupid thing is like an unkillable god or a troll. It keeps resurrecting and resurrecting. Knowing we need to do something different but it's just sooo easy to resurrect it. It's going to be so weird saying things like. Linux is the graphics king. You'll have to practice taking the smirk off your face for a while.

      Comment


      • #4
        Anything interesting for R200?

        Comment


        • #5
          I was always wondering how well Gallium3D drivers worked with R500 ATI graphics cards, which don't have many shader units.
          Does G3D do all computing by shaders or is it still possible to access the fixed-function pipeline for simple tasks?

          Comment


          • #6
            Oops:

            and the even numbered releases being stable (i.e. Mesa 7.2 and Mesa 7.5)

            Comment


            • #7
              We actually took the fixed function pipeline out in R300. R100 was fixed pipe only, R200 had both fixed and programmable pipe, R300 and up was all programmable shaders.

              When running graphics programs which need a fixed function pipeline, the driver loads simple vertex shader programs which emulate the traditional fixed function transform/clip/light pipeline.

              Gallium3D is a good fit with R300 and up, since it also assumes programmable shaders only.

              Comment


              • #8
                I have one doubt, please someone help me to figure out. Is Gallium3D a further layer between the Xserver and a driver? A sort of HAL? Ok... I know it is good for faster and simpler driver development... but my question is: permormance and optimisation will be affected?
                Last edited by TeoLinuX; 05-09-2009, 06:07 AM.
                Netrunner Linux - Rolling Release ; Nexus 5 ROM Chroma 5.1 ; NAS 6TB on FreeNAS

                Comment


                • #9
                  Originally posted by TeoLinuX View Post
                  I have one doubt, please someone help me to figure out. Is Gallium3D a further layer between the Xserver and a driver? A sort of HAL? Ok... I know it is good for faster and simpler driver development... but my question is: permormance and optimisation will be affected?
                  It might not be the best solution for your GPU, but, as all efforts will benefit to almost everyone, you can expect an better optimisation and a lot more features than what you would have got with the current effort on your GPU family. (Hope it is clear :s).

                  Even if we get a 10% slow down compared to fglrx, we are likely to get a lot of opengl functions that will speed up what is currently done in software in our FOSS drivers.


                  BTW, I just recompiled the latest mesa and xf86-video-ati from git/master. I'm now able to play smokin guns smoothly (FPS in a range [19, 60]) in 1024*768 ! It is a real milestone and a bit unexpected for me
                  Last edited by MPF; 05-09-2009, 06:44 AM.

                  Comment


                  • #10
                    Originally posted by TeoLinuX View Post
                    I have one doubt, please someone help me to figure out. Is Gallium3D a further layer between the Xserver and a driver? A sort of HAL? Ok... I know it is good for faster and simpler driver development... but my question is: permormance and optimisation will be affected?
                    Think about the X server; you have a big chunk of device-independent code, and a smaller chunk of device dependent code (the DDX, or X driver) for each GPU family.

                    Mesa is like that as well; you have a big chunk of device independent code plus a device-dependent driver for each GPU family. With X drivers you have a separate tree for each driver, but all the Mesa drivers are managed inside the mesa source tree (in src/mesa/drivers/dri/) :

                    http://cgit.freedesktop.org/mesa/mes...sa/drivers/dri

                    From a 3D perspective, Gallium3D drivers replace the traditional drivers inside Mesa, ie the Mesa code is modified to use Gallium3D rather than the traditional HW drivers. In that sense, Gallium3D is a *replacement* for the existing HAL that already existed inside Mesa.

                    Gallium3D and its drivers are also stored in the Mesa tree, but at a different location :

                    http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium

                    There are two interesting things about Gallium3D. One is that the "driver model" is designed around modern shader-based GPUs rather than the fixed-function pipeline that was standard when Mesa hardware acceleration was first implemented. The second is that the API was designed in a way that made it potentially useful for other things than 3D acceleration. This is one of the reasons that the Gallium3D source is "further up the tree" than the classic Mesa hardware drivers.

                    So, when we talk about "Gallium3D vs Classic Mesa" we're really talking about "Mesa using the Gallium3D HAL" vs "Mesa using the current fixed-function HAL", where both HALs are inside the Mesa source tree.

                    From a performance and optimization point of view the primary benefits of Gallium3D involve the ability to move some additional code from device-dependent drivers to device-independent code, allowing the entire stack to move more quickly with the available development resources. It's easy to trivialize the benefit of improved development efficiency, but since the performance levels of the open 3D drivers are almost entirely driven by the amount of available developer time anything that allows more sharing and re-use of driver code can make a big difference in the performance and useability of the resulting drivers.
                    Last edited by bridgman; 05-09-2009, 11:33 AM.

                    Comment


                    • #11
                      is there any documentation/how to on writing G3D drivers (or state trackers) ???

                      not that i have the skills but just want to go through it if it exists

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        Think about the X server [...]
                        Many thanks John, the explanation was enlightening!

                        BTW I use this occasion to add that I really appreciate all the tech docs drops by AMD...
                        I left my nVidia for a radeon3650 last year. Well, during this time I noticed so many improvements on fglrx... but I have to admit they're not perfect yet.

                        Citing *X* files.... "I want to believe"

                        Ciao!
                        Netrunner Linux - Rolling Release ; Nexus 5 ROM Chroma 5.1 ; NAS 6TB on FreeNAS

                        Comment


                        • #13
                          David Airlie's clone?

                          This is David Airlie's latest blog entry :

                          So Gia, Isabel and I are off to Ireland for 3 weeks from the 7th -> 31st of May.

                          Radeon KMS is all I've been doing lately and my feeling is the F11 driver is in a fairly good state, a lot better than F10. 3D seems to be working okay, however we have some speed regressions that I will be attempting to track down in earnest on my return. AGP cards got hit a bit lately as a fix for a real bug slowed an optimisation I previously made down.

                          For mesa I'd really like to merge radeon-rewrite to master already, but I expect I should wait until I get back as I need to be more reactive to fixing regressions in it.
                          It seems that there are two David Airlie ;-)

                          Comment

                          Working...
                          X