Announcement

Collapse
No announcement yet.

NVIDIA Slaughters AMD Catalyst On Linux In OpenGL 4.x Micro-Benchmarks

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

  • #31
    Originally posted by dungeon View Post
    Apitest use OpenGL 4.2+ and only ARB extensions, that is part of any 4.2 implementation .

    Shader draw parameters is just over a year old so you seem to be wrong, didn't check the rest, it might work with older versions but i doupt it is in all opengl implementations included jet.

    If your read the extension description, you would surely see at it requires either features of OpenGl 4.3 and up or NV_extension or/while the ARB extension with the same functions from the name is ready to be part of core profile 4.5/5. So I wouldn't be that shure it works with all 4.2 implementations.

    Yep that is why i say _their_ implementation .
    shure, just to make it clear to the ones that won't understand what you want ot say with it, but my post got many spelling faults, but there is no way to correct them.

    Comment


    • #32
      Originally posted by _ONH_ View Post
      Shader draw parameters is just over a year old so you seem to be wrong, didn't check the rest, it might work with older versions but i doupt it is in all opengl implementations included jet.
      Apitest query for the following extensions and draw parameters is there
      Code:
      gHasExtension_ARB_map_buffer_range
      gHasExtension_NV_bindless_multi_draw_indirect
      gHasExtension_ARB_sparse_texture
      gHasExtension_ARB_shader_draw_parameters
      gHasExtension_NV_shader_buffer_load
      gHasExtension_ARB_multi_draw_indirect
      gHasExtension_ARB_texture_storage
      gHasExtension_ARB_timer_query
      gHasExtension_ARB_internalformat_query
      gHasExtension_EXT_texture_array
      gHasExtension_ARB_sync
      gHasExtension_ARB_uniform_buffer_object
      gHasExtension_ARB_base_instance
      gHasExtension_NV_vertex_buffer_unified_memory
      gHasExtension_ARB_shader_storage_buffer_object
      gHasExtension_ARB_bindless_texture
      gHasExtension_ARB_buffer_storage
      gHasExtension_ARB_debug_output
      gHasExtension_ARB_vertex_array_object
      If your read the extension description, you would surely see at it requires either features of OpenGl 4.3 and up or NV_extension or/while the ARB extension with the same functions from the name is ready to be part of core profile 4.5/5. So I wouldn't be that shure it works with all 4.2 implementations.
      I just note 4.2+ is as what they say on these slides .
      Last edited by dungeon; 06-15-2014, 07:59 AM.

      Comment


      • #33
        Originally posted by dungeon View Post
        Apitest query for the following extensions and draw parameters is there
        Code:
        gHasExtension_ARB_map_buffer_range
        gHasExtension_NV_bindless_multi_draw_indirect
        gHasExtension_ARB_sparse_texture
        gHasExtension_ARB_shader_draw_parameters
        gHasExtension_NV_shader_buffer_load
        gHasExtension_ARB_multi_draw_indirect
        gHasExtension_ARB_texture_storage
        gHasExtension_ARB_timer_query
        gHasExtension_ARB_internalformat_query
        gHasExtension_EXT_texture_array
        gHasExtension_ARB_sync
        gHasExtension_ARB_uniform_buffer_object
        gHasExtension_ARB_base_instance
        gHasExtension_NV_vertex_buffer_unified_memory
        gHasExtension_ARB_shader_storage_buffer_object
        gHasExtension_ARB_bindless_texture
        gHasExtension_ARB_buffer_storage
        gHasExtension_ARB_debug_output
        gHasExtension_ARB_vertex_array_object


        I just note 4.2+ is as what they say on these slides .
        The NV extensions are used for the GLBindless tests, which obviously wont even run on AMD hardware. The rest is using ARB extensions.

        This explains (partially) the issue with:
        "in several of the cases the AMD Catalyst driver couldn't even handle the tests"

        Comment


        • #34
          Originally posted by log0 View Post
          The NV extensions are used for the GLBindless tests, which obviously wont even run on AMD hardware. The rest is using ARB extensions.

          This explains (partially) the issue with:
          "in several of the cases the AMD Catalyst driver couldn't even handle the tests"
          And for several of these exists a patch to make it work on AMD 280X. But it didn't got merged in the last 25 days the patch exist.
          Stupid to test per definition a SW that is obvious incompatible with some of the tested HW.
          If you look at github. the author compares AMD hardware as followed AMD is 6000% slower than Nv.
          Then if someone surely expect him to write a somewhat objective test.
          I wouldn't, it isn't the case that if there would stand that AMD HW has 3% of the tested NV cards performance would look better for the AMD HW.
          He is an Nv crook, who even doesn't know how calculation with percentages works, so it is even worse he works for valve now.

          Comment


          • #35
            Originally posted by _ONH_ View Post
            And for several of these exists a patch to make it work on AMD 280X. But it didn't got merged in the last 25 days the patch exist.
            Stupid to test per definition a SW that is obvious incompatible with some of the tested HW.
            If you look at github. the author compares AMD hardware as followed AMD is 6000% slower than Nv.
            Then if someone surely expect him to write a somewhat objective test.
            I wouldn't, it isn't the case that if there would stand that AMD HW has 3% of the tested NV cards performance would look better for the AMD HW.
            He is an Nv crook, who even doesn't know how calculation with percentages works, so it is even worse he works for valve now.
            Look up "ad hominem", try harder.

            Comment


            • #36
              Vendor B can't update its driver without breaking something. They will send you updates or hotfixes that fix one thing but break two other things. If you single step into one of this driver's entrypoints you'll notice layers upon layers of cruft tacked on over the years by devs who are no longer at the company. Nobody remaining at vendor B understands these barnacle-like software layers enough to safely change them.
              AMD's driver is pure garbage and AMD fanboys here can't accept the bitter truth.

              Comment


              • #37
                i agree

                Originally posted by GT220 View Post
                AMD's driver is pure garbage and AMD fanboys here can't accept the bitter truth.
                i give up from amd because their garbage drivers, with nvidia everything works well is the truth with amd nothing works even in windows

                Comment


                • #38
                  Originally posted by Daktyl198 View Post
                  Is this really news, though? Based on what I've heard...

                  NVidia's driver:
                  - Clean and uber fast on Windows. Uses some extreme cheating for performance's sake sometimes... (I've heard some bad things about what this does to the OpenGL "compatibility")
                  not really cheating just optimized for best perf on their hw possibly at expense of rote opengl compliance which really isn't a problem for consumer cards...
                  - Linux port is amazing, confirming clean code etc etc
                  - A normal sized team, probably a similar number to the Windows driver (definitely smaller, though).

                  AMD's driver:
                  - Pretty fast but buggy on Windows. It tries to stick more closely to API specs
                  - Linux port is utter shit. Porting buggy Windows code probably isn't easy, and I feel sorry for them... more so because -
                  - Tiny team (comparatively), not that they can help it. Half of their would-be members are working on the FOSS driver since AMD can't fucking pick a side.

                  Now do the same tests, but with OGL 3.x, and AMD using both Catalyst and FOSS drivers. That's what I'm interested in.
                  can't disagree with the rest, but frankly I couldn't give a rat's --- about opengl < 4

                  [EDIT]
                  as top ATI opengl, well when you only have .25-.5 guys working on yer shitty drivers you don't have time to spin pro and consumer variants of yer drivers beyond a check to see which kind it is, let alone produce anything worthwhile...
                  [/EDIT]

                  Comment


                  • #39
                    Originally posted by log0 View Post
                    It tests driver overhead, not raw gpu power.
                    But isn't the benchmark testing frames per second? How is 750ti dishing out more frames than 780ti?

                    Comment


                    • #40
                      Originally posted by GT220 View Post
                      AMD's driver is pure garbage and AMD fanboys here can't accept the bitter truth.
                      You know I felt the same when I upgraded from a GT 630 to an R7 260X starting of the year. However I soon realized that it's got a lot to do with the games as well. I have all of the source games from valve and they work exceptionally well on my AMD card but when I run games from other vendors (Metro LL for example) they seem to be crap. Instead of people being so quick on pointing figures at AMD, should instead try and answer the question, why do games from valve span so perfectly on the entire GPU spectrum while most games from other vendors behave horribly? Valve clearly took their time to port their games and it clearly shows! I can say the same thing about games build using unity.

                      Comment


                      • #41
                        Originally posted by tusharkant15 View Post
                        But isn't the benchmark testing frames per second? How is 750ti dishing out more frames than 780ti?
                        This test is not intended to benchmark different vendors/ gpus. It reflects a specific problem and a couple of solutions to achieve the best performance (least driver overhead).
                        This blog post is basically click bait.

                        Comment


                        • #42
                          Hi,

                          I am just going to be the ugly kid in the corner with the humpback and the protruding eyes who has not learned to run with the pack, and never will.

                          The benchmark is a great opportunity! One to learn from how to write better code and to measure existing code so it can be improved further. And it is of use to everyone - for Nvidia, for AMD, for Intel, for the Open Source community, any developer really. And what leads to better code leads to happier end users.

                          I will now go back to my corner and let the experts name and shame the heck out of the benchmark and the results. I do know why you are really doing it (so you can make sense of it ).

                          Comment


                          • #43
                            Originally posted by andyprough View Post
                            I had multiple system-wide crashes on a daily basis the last time I tried an AMD card. Spent parts of a couple of weeks debugging with engineering assistance - all problems consistently pointed to the card. Switched it out for an Nvidia card and never had a problem again. I don't even run games or graphics intensive software under Linux - just some simple business stuff. Nvidia and Intel are smooth as silk - I figure why should I put myself through the misery with AMD? However, I respect them for trying, and I know AMD has a lot of fans for good reason. I just won't be one of them anytime in the near future.
                            Same story. Replaced AMD 7950 with GTX 780, and core hangups have stopped. Now I can have month+ uptime easily. And games work flawlessly now.

                            Comment


                            • #44
                              Originally posted by tusharkant15 View Post
                              You know I felt the same when I upgraded from a GT 630 to an R7 260X starting of the year. However I soon realized that it's got a lot to do with the games as well. I have all of the source games from valve and they work exceptionally well on my AMD card but when I run games from other vendors (Metro LL for example) they seem to be crap. Instead of people being so quick on pointing figures at AMD, should instead try and answer the question, why do games from valve span so perfectly on the entire GPU spectrum while most games from other vendors behave horribly? Valve clearly took their time to port their games and it clearly shows! I can say the same thing about games build using unity.
                              The fact most people don't grasp what you have tells me how ignorant they are regarding the chain of responsibility from hardware to driver to application. Pissing on a device company when the talent writing the game is either geared for a specific vendor to leverage marketing advantage, or neither and it is just a lack of actual game programming talent, truly shows a lack of both understanding and maturity on the parts of the shills proclaiming one vendor over the other is crap.

                              Comment


                              • #45
                                Originally posted by flim View Post
                                This test is not intended to benchmark different vendors/ gpus. It reflects a specific problem and a couple of solutions to achieve the best performance (least driver overhead).
                                This blog post is basically click bait.
                                Exactly.

                                Comment

                                Working...
                                X