Announcement

Collapse
No announcement yet.

Where The Open-Source AMD Driver Is At For Modern GPUs

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

  • #11
    Originally posted by Kano View Post
    For some use cases it seem that oss drivers are not that bad. When you only play browser games up to quake live you can be happy already - depends a bit on the card however.
    Yup, I would definitely buy a HD5830 to play Quake Live. No wait, Quake 3 was working fine on GeForce2... Well, after thinking about it, I think I'll stick to Catalysts.

    Comment


    • #12
      Originally posted by yaji View Post
      Yup, I would definitely buy a HD5830 to play Quake Live. No wait, Quake 3 was working fine on GeForce2... Well, after thinking about it, I think I'll stick to Catalysts.
      You don't need an HD5830 to play QuakeLive, the cheapest card on the market will work just fine. Fanless, even:

      Comment


      • #13
        Originally posted by pingufunkybeat View Post
        It's like GCC vs. ICC. ICC is much faster, but everyone uses GCC anyway, because speed is not everything. We need to cover the needs of the computer users, free software itself is THE killer argument.
        The difference being is that the gap in performance for a vast majority of compiled items is usually about 5-10% if there is a difference at all when it comes to icc vs gcc. Gcc can also be faster on some items again not by much. Also the resulting binary winds up with the same features no matter what compiles it. Comparing compilers to drivers isn't a good comparison.

        Comment


        • #14
          Originally posted by deanjo View Post
          The difference being is that the gap in performance for a vast majority of compiled items is usually about 5-10% if there is a difference at all when it comes to icc vs gcc. Gcc can also be faster on some items again not by much. Also the resulting binary winds up with the same features no matter what compiles it. Comparing compilers to drivers isn't a good comparison.
          Well, if the performance difference is 20% (if there is one at all), like is the case with r300g, then it is indeed a good comparison.

          Sure, the r600+ drivers have some catching up to do, but they did start far too late, and they did catch up a lot already. If the drivers reach the 75% mark (as they are expected to and like r300g did), then it will indeed be a good comparison.

          I also don't see why comparing compilers to drivers is not a good comparison, when a large part of what a modern GPU driver does is actually compiling. In fact, they translate OpenGL code and shaders into a form that the GPU (a processor) can execute.

          Comment


          • #15
            Originally posted by Jimbo View Post
            it seems some type of "architectural" problem.
            Yes it is. As J?r?me Glisse said, there is several points :
            - the amd gpu conception (contrary to nvidia) need that the kernel take time to analyze the command buffer, for security reason. fglrx do not do that.
            - there is some limitation is the API, and it's not easy to fix. Moreover the kernel api is freeze, contrary to nouveau.
            - r600g have a design that is not the best to do what it do.

            To conclude, in fact, the main "problem" with r600g is in the kernel, not really in gallium side.

            Comment


            • #16
              Originally posted by pingufunkybeat View Post
              Well, if the performance difference is 20% (if there is one at all), like is the case with r300g, then it is indeed a good comparison.
              Only if the binary that is produced is time critical. Let's face it an end user is rarely going to care if it takes 54 seconds to encode a mp3 vs 60 seconds and the output would be the same but when you are dealing with real time input / output that is an entirely different matter.

              Comment


              • #17
                If 20% more performance costs $10, then it is as good as unimportant. Especially when dealing with 10-year-old games, which run faster than the refresh rate anyway, which is essentially the Linux situation.

                Comment


                • #18
                  Originally posted by whitecat View Post
                  Yes it is. As J?r?me Glisse said, there is several points :
                  - the amd gpu conception (contrary to nvidia) need that the kernel take time to analyze the command buffer, for security reason. fglrx do not do that.
                  - there is some limitation is the API, and it's not easy to fix. Moreover the kernel api is freeze, contrary to nouveau.
                  - r600g have a design that is not the best to do what it do.

                  To conclude, in fact, the main "problem" with r600g is in the kernel, not really in gallium side.
                  Kernel side is one part of the issue if you want to compete with catalyst. Right now the biggest issue is in r600g itself. Thought given the number of r600g needs i fear that kernel side might also impact it a little bit more than r300g.

                  Comment


                  • #19
                    mmmm Michael maybe is cuz my card is a 4850 but nexuiz in the most extreme preset is always around 50 fps at 1440x900 using mesa-git, natty, drm git, ddx git, 2.6.38 drm next (2.6.39 broke btrfs so i can't boot it), color tiling, swapwait off, st3c support, etc.

                    well im using custom cflags but still those results are creepy slow, maybe pts is missing something?

                    i know you do out of the box benchs but it won't hurt to create some sort of tweaked profile wich is more likely to be closer to the real state of the driver, remember r600 is under heavy development

                    Comment


                    • #20
                      Originally posted by pingufunkybeat View Post
                      If 20% more performance costs $10, then it is as good as unimportant.
                      That is only if you do not have a card in the first place, so replacing a card carries considerably higher price.

                      Comment

                      Working...
                      X