Announcement

Collapse
No announcement yet.

Gallium3D Now In Mainline Mesa Code-Base!

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

  • #11
    Originally posted by bridgman View Post
    The "pipe" driver is the primary hardware-dependent code, so tuning a cell or intel pipe driver wouldn't affect radeon. On the other hand, under Gallium3D the amount of hardware-dependent code is smaller, and really is a good match with the stuff that is different from one GPU to the next.

    The "winsys" driver used to be a mix of hardware-dependent (command submission) and hardware independent (window interface) functions, but AFAIK that has now been broken up to isolate the hw-dependent code in a separate module from the rest.
    well, if someone tunes let's say the opengl-implementation in mesa or the state tracker (don't know whether i'm right, mean opnecl-, openvg-, 2d-modul in gallium3d on top of the pipe driver), than you'll gain, too. so you could "move" all your tuning action from the fglrx-codebase to gallium/trackers

    Comment


    • #12
      Yes and no. That would work if we had a large Linux-specific performance team, or if we used Gallium3D and Mesa for our Windows and MacOS drivers, but we don't do either of those today.

      What we do instead is share big chunks of code across multiple OSes, so that tuning work done for one OS benefits users of the other OSes as well. If we had a completely separate code base for Linux drivers then the arguments about "dumping fglrx and concentrating on open source drivers" would make a lot more sense.
      Last edited by bridgman; 02-11-2009, 02:46 PM.

      Comment


      • #13
        hm and fglrx's move to gallium3d? are there already plans? do you already have a strategy how/when to do this? it's going to be difficult to share code, isn't it? perhaps than, the time for a full os-driver will come..

        however, some day we have to thank intel that the via/nouveau/ati-driver is that fast...

        Comment


        • #14
          People wanting performance are more interested in a fglrx with less bugs. If I say "fglrx doesn't support this and that" they say "use the open source drivers". But then I say "they suck ass; they're slow" and we're back to square 1. If all they can do is utilizing only 70% of my 300$ card, then no thanks.

          Comment


          • #15
            We moved our 3D stacks onto something similar Gallium3D a few years ago; the big 3D performance jump in September '07 came from the new OpenGL stack hitting the fglrx driver. I don't think there would be any real benefit to changing again.

            Comment


            • #16
              Originally posted by RealNC View Post
              People wanting performance are more interested in a fglrx with less bugs. If I say "fglrx doesn't support this and that" they say "use the open source drivers". But then I say "they suck ass; they're slow" and we're back to square 1. If all they can do is utilizing only 70% of my 300$ card, then no thanks.
              I guess the question is whether you can see the difference between 175 and 225 frames per second on your 60 Hz display

              Comment


              • #17
                Originally posted by bridgman View Post
                I guess the question is whether you can see the difference between 175 and 225 frames per second on your 60 Hz display
                You know there'll always be games that'll bring any graphics cards to it's knees, try setting GTA IV to maximum if you don't know what I'm saying. Or they could have bought a cheaper card than they did. Still, so you got one or two FPS games that DO need the full 100%, it's not more than a reboot away. Not playing, playing older games, whatever that would do just fine. Chances are that on most brand new games you'll be booting into Windows a while anyway while WINE tries to figure out some new fixes anyway. To me it seems like focusing on this point is blowing it completely out of proportion.

                Comment


                • #18
                  Originally posted by bridgman View Post
                  I guess the question is whether you can see the difference between 175 and 225 frames per second on your 60 Hz display
                  I can't.

                  But I CAN tell one between 20 and 30. And trust me, it's a BIG one

                  Comment


                  • #19
                    I doubt there is anything that could bring your $300 4870 to 20-30 fps on Linux.

                    In fact, my 4850 has managed to breeze through everything I could throw at it on Linux *or* Windows (well, except for GTAIV, but that game didn't stay installed for more than 15 minutes.) I've forced VSync, because nothing comes even close to 85Hz - everything is running silk-smooth here.

                    Comment


                    • #20
                      @bridgman

                      i registered here, cos I just want to ask you something. You always say that OS drivers can get around 60-70% of fglrx performance. But what makes you think it? I mean, you guys spend 10 years and your driver is not working on many machines. On the other hand, 1 man spend one year and it just works, even 2D is already faster. What makes you think, that your 3D code is better, its obviously that you cant even write a decent installer, so why should your 3d be better? If I am right you are an AMD employee, so do you know how many people working on linux driver? And do you think they are worth their money?

                      BTW, last time I spend 3 hours to install fglrx on my notebook, and no I am not a Linux noob and I had to use all tutorials available. At the end I dint know any more how and why they started working. After i installed ubuntu 8.10 I didn't even try to install them again, cos I knew I would swear like mad. How much could i earn in this time? Dont you think that AMD owe me thomething?

                      Ah, and my brother has the same notebook as i do, I compared fglrx and radeon with open arena, radeon has already around 60% of fglrx performance.

                      Comment

                      Working...
                      X