Announcement

Collapse
No announcement yet.

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

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

  • #11
    I'm at about the same level - jalapenos are a staple, I use habaneros/scotch bonnets but carefully... (not carefully enough, apparently)

    One of my neighbors started growing Naga Jolokias (not sure why, she doesn't like spicy food and her husband won't go near the Nagas) so I have a bunch and am not really sure what to do with them yet. Thinking about mixing up a batch of *really* hot jerk paste (I normally use 6-8 scotch bonnets) but not sure what I'm going to end up with if I grind up a couple of Naga Jolokias instead. One of my friends also picked up a bottle of Blair's 3AM Reserve, which is supposed to be around 3 million scoville units. It's sitting on my kitchen counter and I haven't opened it yet.

    Regarding the jump to 600g for new GPU support, the problem is that getting a new GPU running involves a relatively small amount of time writing the initial code and a relatively large amount of time figuring out why the damn thing doesn't work. If you don't start with a 100% known good code base then things get exponentially more complicated. When we started working on Evergreen even 300g wasn't at the point where it felt completely ready to use as the base for new GPU support, but obviously a lot has changed since then. It wasn't a question of knowing the code as much as the framework being ready to "bet the farm" on.

    The choice for Evergreen is pretty simple -- we'll probably stay with whatever has the best chance (if any) of getting into the fall distro releases until the code is generally useable (which is probably 600c) then jump to 600g and never look back. Most of the distros are going with somewhat older code so there's probably some backporting required anyways - what we need to look at is whether backporting is feasible or not. If not, then we jump to 600g anyways and make sure everything is shiny for the spring distro releases.

    Any new GPU support is going to miss the fall distros anyways so there we have more flexibility and I think going with 600g from day one is going to be the right answer.
    Test signature

    Comment


    • #12
      When you talk about fall ... which year it is ?

      Comment


      • #13
        "...we aren't sharing more news right now on Valve's Steam/Source Linux client that's still coming..."

        Okay, now you're just doing this on purpose, Michael! (we see what you did there, superb trolling, etc.)

        Damn, I just refrained from buying an Evergreen board the other day. Then again, my R600 still isn't really working all that great; switching would be silly I suppose.

        Comment


        • #14
          Originally posted by Xavier View Post
          When you talk about fall ... which year it is ?
          He's talking about this year. Ubuntu 10.10 for example will be released in a month on October 10.

          Comment


          • #15
            Originally posted by Silverthorn View Post
            He's talking about this year. Ubuntu 10.10 for example will be released in a month on October 10.
            And it won't include stable classic Mesa driver for Evergreen. So maybe it's a good idea to focus on r600g with Evergreen and prepare it for Ubuntu 11.04 and openSUSE 11.4 (March 2011)?

            Comment


            • #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:


                    (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

                      Working...
                      X