Announcement

Collapse
No announcement yet.

Did Hell Just Freeze Over? Here's Evergreen On Gallium3D!

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

  • #16
    Lol@chili food xD

    Man at this rate you guys are catching so quickly! You're working faster than new GPU releases ^^,

    Broadcom going open, SystemD... (Steam?,) Rage, Duke Nukem Forever (not Linux, mind you!)...

    2011 is gonna rock!

    Comment


    • #17
      I would guess the bed is already pretty much made wrt fall releases. If you guys can find a consensus within the dev community for skipping classic mesa on the next generation of AMD GPUs, I'm thinking you can convince the distro vendors as well. Everyone understands this is the way things are heading.

      What percentage of bugs in writing r600g have come down to gallium and how many are also evident in classic? Has work on r300g state trackers contributed to a reduction in workload for devs?

      I bet those peppers could be mixed into a really eye watering berbere. I've always found siga wot quite good for pushing my limits of pain. That hot sauce sounds a little much, though. Close to the potency of capsicum ammunition? Wow!

      Comment


      • #18
        AFAIK, all benchmarks presented here so far shows Gallium3D drivers to be much slower comparing to "traditional" Mesa closed source drivers. And difference usually looks pretty big. Is there any chance of closing this gap? Is there fundamental architectural problem in G3D? Ordinary users will hardly celebrate architectural perfection of AMD G3D drivers if performance is 3x worse all of a sudden for them.

        Comment


        • #19
          Originally posted by mirza View Post
          AFAIK, all benchmarks presented here so far shows Gallium3D drivers to be much slower comparing to "traditional" Mesa closed source drivers. And difference usually looks pretty big. Is there any chance of closing this gap? Is there fundamental architectural problem in G3D? Ordinary users will hardly celebrate architectural perfection of AMD G3D drivers if performance is 3x worse all of a sudden for them.
          It's interesting that you should mention that, there was a recent discussion about the pros and cons of G3D. Marek wrote about performance and overhead in r300g:
          http://lists.freedesktop.org/archive...er/002840.html

          (The whole thread is an interesting read).

          Comment


          • #20
            Originally posted by mirza View Post
            AFAIK, all benchmarks presented here so far shows Gallium3D drivers to be much slower comparing to "traditional" Mesa closed source drivers. And difference usually looks pretty big. Is there any chance of closing this gap? Is there fundamental architectural problem in G3D? Ordinary users will hardly celebrate architectural perfection of AMD G3D drivers if performance is 3x worse all of a sudden for them.
            The problem is a this time g3d is mainly cpu bound because of bad userspace buffer management. There is an existing library inside mesa which adresses this problem but it has to be backed by some work on the individual drivers. Work in that direction is under way in most g3d drivers. The performance drop you see compared to the classic drivers is not an unsolvable problem. Stay tuned for future work.

            Comment


            • #21
              Originally posted by mirza View Post
              AFAIK, all benchmarks presented here so far shows Gallium3D drivers to be much slower comparing to "traditional" Mesa closed source drivers. And difference usually looks pretty big. Is there any chance of closing this gap? Is there fundamental architectural problem in G3D? Ordinary users will hardly celebrate architectural perfection of AMD G3D drivers if performance is 3x worse all of a sudden for them.
              First of all, Mesa is not closed source, it is open source.

              r300g is already faster than r300c, so I don't think that this is an architectural issue.

              The problem with r600g is that it is really really new and immature, and it is also missing a decent shader compiler. I expect it to catch up with, and overtake r600c eventually.

              If you are talking about the proprietary Catalyst drivers (which have nothing to do with Mesa), it's a different story, and the proprietary drivers are likely to stay faster for a long time, probably forever. There are many reasons for this.

              On the other hand, the performance of the open source drivers (most likely the Gallium-based ones) will approach the speed of the proprietary drivers, but this will take some time.

              Comment


              • #22
                Yep. Right now the maximum performance of a Gallium3D driver is a bit lower than the maximum performance of a classic driver simply because the upper level code is still written for classic drivers then uses an interface layer to work with Gallium3D drivers, but (a) that will go away over time and (b) the 300g code has already demonstrated that other improvements in the driver can more than make up for the (temporary) extra overhead of the interface layer.

                Comment


                • #23
                  Damn this is great news. Exciting times ahead. I'm glad I had the guts to buy a laptop with Evergreen chip a couple of months ago.

                  Comment


                  • #24
                    Very interesting development to say the least!

                    This really makes me think (and hope) that the next AMD GPU generation (6xxx) will start with Gallium rather then classic mesa! I just hope it starts of stable and preferably with kernel mode setting.

                    Perhaps a little to much to hope for?

                    Anyway a good job so far, AMD!

                    Comment


                    • #25
                      Gallium drivers all require KMS, and I'm pretty sure that AMD won't waste time building a UMS code path for new hardware.

                      But The development is really good, and it's nice to have (more or less) functioning G3D drivers for all released hardware. That's a very impressive development, considering pretty much all of it was started 3 years ago, when the latest two generations were not even released, and most of the released ones only had very basic support for anything (all running with UMS)!

                      Here's the hoping that the Jerome's shader compiler makes good progress, and that r600g makes similar improvements to those observed with r300g.

                      Comment


                      • #26
                        Originally posted by markg85 View Post
                        Very interesting development to say the least!

                        This really makes me think (and hope) that the next AMD GPU generation (6xxx) will start with Gallium rather then classic mesa! I just hope it starts of stable and preferably with kernel mode setting.

                        Perhaps a little to much to hope for?
                        Yeah, "starting off stable" (i.e., the initial git commit being stable and 100% usable) is definitely too much to hope for. It's open source; it's supposed to have community help. They push out the rough bits that barely get things working, then leave it up to community devs to fix the "edge cases" (i.e. the 40% of the stuff that doesn't work).

                        If you wanted the initial support to be stable and 100% functional, you'd have to give them a full year (or more) of additional in-house development before making the initial push to freedesktop.org. That wouldn't benefit anyone; the (few) community developers wouldn't be able to contribute to it at all during that time, and the AMD guys would quickly fall behind the stride of hardware releases if they spent all their time polishing the driver in-house. There isn't enough manpower as it is; it's better to get the few community devs involved as early on as possible to further accelerate the progress. Case in point, Dave Airlie and others have been doing great with evergreen on gallium, but I don't think the AMD devs have touched it at all. They've just been working on classic mesa.

                        Comment


                        • #27
                          Originally posted by allquixotic View Post
                          There isn't enough manpower as it is; it's better to get the few community devs involved as early on as possible to further accelerate the progress. Case in point, Dave Airlie and others have been doing great with evergreen on gallium, but I don't think the AMD devs have touched it at all. They've just been working on classic mesa.
                          Who says there isn't enough manpower? They've been building drivers faster than they're building new hardware! If that wasn't the case, they couldn't possibly have been able to catch up to FIVE YEARS OF BACKLOG (as well as two new hardware generations) in just THREE years.

                          As for Dave Airlie and co... red hat, etc... contributing to the drivers early on... you can clearly see that RH works closely with AMD on this. Don't you don't think that it might be possible for RH to get a few engineering samples early on to hack on? Up until now it hasn't been such a major requirement since the work has all been on EXISTING and RELEASED hardware, but it is very likely that AMD would be happy to spread around some samples earlier than release.

                          Comment


                          • #28
                            The developers do all stay in constant communication, and there's a lot of "ok, I'll work on this, you work on that, and when they both sorta work we'll put them together" decision making going on all the time.

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              Yep. Right now the maximum performance of a Gallium3D driver is a bit lower than the maximum performance of a classic driver simply because the upper level code is still written for classic drivers then uses an interface layer to work with Gallium3D drivers, but (a) that will go away over time and (b) the 300g code has already demonstrated that other improvements in the driver can more than make up for the (temporary) extra overhead of the interface layer.
                              So can we expect the 300g/600g drivers to get close(r) to the closed source driver performance in the next year or two? Or is that out of the picture for at least a couple of years?

                              Comment


                              • #30
                                Yep, I think the developers are starting to approach the point where the basic functionality will be there and improving performance will be a good use of time. You'll know when 90% of the posts stop being about functionality/bugs and start being about performance

                                The main point I was trying to make was that it's not the simple fact of being a Gallium3D driver that will make the 300g/600g drivers go faster, it's that the code is smaller/cleaner which will make some of the performance work easier in the future.

                                That said, a lot of the performance work is probably going to have to be done outside of the "Mesa HW driver" / "Gallium3D HW driver" anyways - either in the upper layers of Mesa or in the lower level libdrm/drm code - and both of those are common to classic and Gallium3D drivers anyways.

                                Comment

                                Working...
                                X