Announcement

Collapse
No announcement yet.

AMD vs NVIDIA drivers, that big difference?

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

  • #31
    Originally posted by bridgman View Post
    Hardware Acceleration on Evergreen/HD5xxx is almost at the same level as 6xx/7xx, with the caveat that acceleration is only supported when running with KMS. As of yesterday there were known issues related to mipmap support and stencil buffer handling.

    Andre just committed a fix related to lodbias (lodbias affects which level of the mipmap is selected when texturing), not sure how much of the mipmap issue that addreses. Looks like the fix should get rid of some unpredictable behaviour, so at worst it will probably make the remaining issues easier to diagnose and fix.
    KMS is work in progress? There's a lot of discussion and topics of disabling KMS for various reasons including getting a black screen on bootup. If there's major revisions of the kernel, is KMS particularly effected?

    I read this:
    http://www.h-online.com/open/feature...s-1065375.html

    I guess that's more open source driver related but for me, I'm wondering about the options of using the binary v.s. open driver. Not a question just stating what I'm mulling over.

    Comment


    • #32
      KMS is work in progress?
      I don't really understand the question about KMS being a work in progress. What I said was that the acceleration code only includes code paths for KMS.

      There's a lot of discussion and topics of disabling KMS for various reasons including getting a black screen on bootup.
      Having the ability to disable KMS and fall back to UMS is handy if a problem with KMS is discovered on a specific system, but the developers would much rather spend their time dealing with KMS issues than duplicating effort to maintain UMS code paths with DRI1 and memory management in the userspace code rather than kernel. When KMS was first launched it only worked on a small set of systems (like all new things) but a year later it is the default for most new distro releases and problems are becoming relatively rare.

      If there's major revisions of the kernel, is KMS particularly effected?
      KMS should be almost completely independent of kernel changes AFAIK -- it's really the memory management and the code that was already in the kernel which is most sensitive to kernel updates.

      The article was a bit off near the end... it talked about the Evergreen code being "still located in various development branches", but there is only one branch (evergreen accel branch of xf86-video-ati, created only because there was a release in progress out of master at the time) and all of the other code is in master for the 3D and kernel drivers. I guess maybe it was saying "the code is scattered across all these projects" but that's just how the open source driver code is managed.

      I guess that's more open source driver related but for me, I'm wondering about ...
      We were talking about the open drivers, so that's fine -- at least I assumed you were talking about the open drivers because of the reference to hardware acceleration. The fglrx driver had hardware acceleration for Evergreen when the family was launched.

      Comment


      • #33
        Originally posted by LinuxID10T View Post
        When I originally tested the first Unigine for linux, tesselation did work on my 4650 or 4350, however, it was BEYOND SLOW. Now, tesselation on those older cards is broken.
        no its just removed because complette incompatible codepath

        and the hd2000-hd4000 code path is totally broken. many graphic effects can't be shown because of this oldscool trueform tesselation unist the unit is just in the wrong place of the chip
        one of the biggest bug is a speed bug you never get any playable fps tesselation speed out of a hd2000-4000

        in my point of view its just microsoft and directX11 they force to get complette incompatible 'NEW' hardware for dx11.

        this 'NEW' makes the old hd2000-4000 tesselation units complette unusable

        Comment


        • #34
          Originally posted by bridgman View Post
          I don't really understand the question about KMS being a work in progress. What I said was that the acceleration code only includes code paths for KMS.

          Having the ability to disable KMS and fall back to UMS is handy if a problem with KMS is discovered on a specific system, but the developers would much rather spend their time dealing with KMS issues than duplicating effort to maintain UMS code paths with DRI1 and memory management in the userspace code rather than kernel. When KMS was first launched it only worked on a small set of systems (like all new things) but a year later it is the default for most new distro releases and problems are becoming relatively rare.
          You answered the question, thanks. I was just speculating whether work on KMS was particularly complicated. I have read here and there of discussion about disabling KMS and I was wondering why it seems to be a task done somewhat often. I was wondering if changes to KMS might result in problems that influence a user into disabling KMS. Glad to hear the current state is one in which problems are rare.

          Originally posted by bridgman View Post
          KMS should be almost completely independent of kernel changes AFAIK -- it's really the memory management and the code that was already in the kernel which is most sensitive to kernel updates.
          Okay, good to know.

          Originally posted by bridgman View Post
          I guess maybe it was saying "the code is scattered across all these projects" but that's just how the open source driver code is managed.
          I was interested in getting an analysis of the article so thanks.

          Originally posted by bridgman View Post
          We were talking about the open drivers, so that's fine -- at least I assumed you were talking about the open drivers because of the reference to hardware acceleration. The fglrx driver had hardware acceleration for Evergreen when the family was launched.
          I think it's safe to say I was aware of that. Yes, we were talking about the open drivers but I thought it was time to include closed drivers in the discussion since we're in the binary section of the forum. I read a post of yours relating to the complexity of having both types of drivers 'installed' at the same time or should I say 'able to co-exist?' I hope this can be accomplished; it would be very convenient for users, right? I'm just mentioning it because there are owners of the card who want certain features and they might have to switch back and forth just because they want a certain feature. Even if the plan is to have the FOSS drivers implement "most" (?) of the features, they might have to wait. I believe I would include myself in that group. It depends on what's working and what I wish to do, of course.

          Thanks for the replies. I hope those are questions that weren't answered before. I also want to assure anyone who's tired of my questions that I'd do my best to contribute if I ultimately buy an ATI card.

          Comment


          • #35
            Originally posted by Glaucous View Post
            I've been using AMD/ATI HD4870 on Kubuntu x64 for a while now, and then I decided to try out (borrowed) NVIDIA GTX 260 - which is a slightly worse card (on Windows). I also tried NVIDIA 8600 GT which is a quite crappy card.

            The results were quite sad, and I'm considering that I failed (Multiple times? Seems odd.) with the AMD/ATI drivers. Please note that glxgears isn't much of a benchmark, but it does show me something.

            fgl_glxgears
            5500 FPS NVIDIA GTX 260
            2100 FPS NVIDIA 8600 GT
            2200 FPS ATI HD4870

            glxgears
            110k frames / 5 seconds - GTX 260
            40k frames / 5 seconds - HD4870 and 8600 GT


            Here sure is a big difference.

            I also tried Wine World of Warcraft, which resulted in about 2-3 times more FPS on GTX 260. And the FPS on 8600 GT was as good or better than HD4870.
            I did try a small particle OpenGL program I wrote, which resulted in about two times more particles at higher FPS - on both NVIDIA cards (CPU bound) compared to HD4870.

            Do anyone else have any experience using ATI and NVIDIA? It feels like the performance on ATI should be better than this - or is this a common problem?
            I'm right now considering buying a NVIDIA Fermi card (as soon as Coolbits is working, and ETA yet?).

            NVIDIA Drivers:
            256.53
            ATI Drivers:
            10.8, 10.7, 10.5.
            Easy:
            nVidia knows how to write decent drivers, while ATI fails miserably at driver implementations. ATI's linux/X drivers are particularly bad, while their Windows drivers are mostly acceptable.

            fglrx has been one long trip to bugginess for me with linux, which means this is my first ATI GPU in almost 10y and the experience has been less than pleasing.

            Comment


            • #36
              Originally posted by cutterjohn View Post
              Easy:
              nVidia knows how to write decent drivers, while ATI fails miserably at driver implementations. ATI's linux/X drivers are particularly bad, while their Windows drivers are mostly acceptable.

              fglrx has been one long trip to bugginess for me with linux, which means this is my first ATI GPU in almost 10y and the experience has been less than pleasing.
              I think you'll find both companies to be as bad or decent as each other.

              Comment


              • #37
                Originally posted by mirv View Post
                I think you'll find both companies to be as bad or decent as each other.
                The guy tested and compared three cards, two Nvidia and one ATI card.

                After the glxgears test, how do you figure the differences are negligible?

                Both companies may be bad or decent but the tests show a considerable difference due to drivers. In Windows, the HD 4870 would smoke the Nvidia 8600 card. It just shows a lack of attention by ATI to Linux drivers. This is shown again and again but no change. Just a lot of talk that things are being 'worked on.'

                Comment


                • #38
                  Originally posted by Panix View Post
                  After the glxgears test, how do you figure the differences are negligible?
                  The difference between 40000fps and 100000fps is negligible. It's an improvement of 0.000015 seconds per frame or a reduction of 0.1% in frame time. Do you understand now why glxgears is not a benchmark? Those huge differences (60000fps OMGOMG!) translate into absolutely nothing.

                  Why? Because fps are non-linear (15 vs 30fps is much more significant than 150 vs 300fps). You need to invert them before you can compare them directly.

                  Comment


                  • #39
                    Originally posted by Panix View Post
                    After the glxgears test, how do you figure the differences are negligible?
                    Because GLXGEARS IS NOT A TEST. It is meaningless.

                    Repeat this 100000 times before you post again. This is obvious trolling now.

                    Comment


                    • #40
                      Originally posted by BlackStar View Post
                      The difference between 40000fps and 100000fps is negligible. It's an improvement of 0.000015 seconds per frame or a reduction of 0.1% in frame time. Do you understand now why glxgears is not a benchmark? Those huge differences (60000fps OMGOMG!) translate into absolutely nothing.

                      Why? Because fps are non-linear (15 vs 30fps is much more significant than 150 vs 300fps). You need to invert them before you can compare them directly.
                      What test is useful then?

                      I just thought it was noteworthy that the result is basically the same as an older inferior Nvidia card.

                      Also, even if Wine is tailored to Nvidia cards, is it still insignificant that the ATI card performs no better than the 8600GT card?

                      Maybe the poster should test with Nexuiz and Unigine? Maybe try Doom 3 and use the Test Suite???

                      Comment


                      • #41
                        Originally posted by Panix View Post
                        What test is useful then?

                        I just thought it was noteworthy that the result is basically the same as an older inferior Nvidia card.
                        It is not. Glxgears tests a very specific part of the hardware that doesn't reflect actual performance.

                        Also, even if Wine is tailored to Nvidia cards, is it still insignificant that the ATI card performs no better than the 8600GT card?
                        Maybe it is, maybe it isn't. If both the Ati card and the 8600GT are getting >100fps then it is insignificant. If they are getting <60fps then it is significant.

                        Maybe the poster should test with Nexuiz and Unigine? Maybe try Doom 3 and use the Test Suite???
                        This would be more useful.

                        Comment


                        • #42
                          Originally posted by Panix View Post
                          What test is useful then?

                          I just thought it was noteworthy that the result is basically the same as an older inferior Nvidia card.

                          Also, even if Wine is tailored to Nvidia cards, is it still insignificant that the ATI card performs no better than the 8600GT card?

                          Maybe the poster should test with Nexuiz and Unigine? Maybe try Doom 3 and use the Test Suite???
                          Unigine is not an real usefull app/game test so its useless.
                          but if they release a real game there wil be a valid ungine based test based on the real game

                          Nexuiz is an outdatet not FBO based energing engine so its useless for modern GPU hardware.
                          Xreal for exampel is a much better engine because of the FBO rendering.

                          DOOM3 can not drop modern gpu hardware unter 60fps means the test is useless.

                          you need an nativ real app/game based on OGL4.1 or 3.3 with high workload on the GPU.

                          you also can test windows apps in wine this dx9/dx10 apps can do much more workload than any linux game.

                          starcraft2 for exampel or crysis or arma2

                          Comment

                          Working...
                          X