Announcement

Collapse
No announcement yet.

Superposition Shows How Far RadeonSI Gallium3D Has Evolved vs. AMDGPU-PRO

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

  • #11
    Originally posted by andre30correia View Post
    again?! why AMD continues with two official drivers? Why they don't simply give up from closed one? and put more ppl working with open ones?
    Because of lag i guess, as literally this bench require GL4.5 > for which radeonsi user need llvm 4.0 > which in turn is released just month ago While AMD Catalyst and PRO drivers have GL 4.5 since 2 years ago, blah, blah

    That for gamers only catchup happens, and if we can ignore enterprise GL use that blobs have (compatability profiles, vendor extensions and more), very good performing Vulkan, OpenCL, etc... then answer is right there
    Last edited by dungeon; 04-12-2017, 10:59 AM.

    Comment


    • #12
      Originally posted by babai View Post

      Hey! AMD employs many RadeonSI OSS driver developers! Which is exactly why you see boost in performance in the last two years.
      I'm a AMD fan for sure, buying only AMD CPUs, and video cards. I've been pretty disappointed with their drivers support. Spotty at best. They are finally putting some effort
      behind their linux drivers but only on the newer generation of cards. Even though my HD7870 was a good card for 1080p, would have to replace it because the support is nil.
      I was never able to make it work correctly with the driver provided.
      But over all for me it isn't a deal breaker. I make a living using linux powered PCs. In the off hours I game on a windows PC. That is about all windows is good for.

      Comment


      • #13
        Originally posted by dungeon View Post

        Because of lag i guess, as literally this bench require GL4.5 > for which radeonsi user need llvm 4.0 > which in turn is released just month ago While AMD Catalyst and PRO drivers have GL 4.5 since 2 years ago, blah, blah

        That for gamers only catchup happens, and if we can ignore enterprise GL use that blobs have, very good performing Vulkan, OpenCL, etc... then answer is right there
        Catch up happened because for years AMD (rather it was ATi at that time) only half assed supported an OSS driver and then for many years didn't support an OSS driver at all. That changed in 07 when AMD officially started supporting OSS drivers in a more sane manner. That was ten years ago, and it took nearly that long to get to this point with OpenGL. But on the other hand Vulkan was is only a little over a year old and radv technically is younger than that even. But here we are with less than a year later and Vulkan is already largely working. 10 years for OpenGL, less than one for Vulkan.

        Don't blame the time scale on the driver, blame the time scale on the API the driver needed to implement.
        Last edited by duby229; 04-12-2017, 11:06 AM.

        Comment


        • #14
          Originally posted by andre30correia View Post
          again?! why AMD continues with two official drivers? Why they don't simply give up from closed one? and put more ppl working with open ones?
          Because they need to provide support Compatibility Contexts for professional software. Mesa deliberately ignores them.

          Common trait of professional software? Code base from the 90s with a few semi-modern features stacked on top with every new version.

          Comment


          • #15
            Originally posted by VikingGe View Post
            Because they need to provide support Compatibility Contexts for professional software. Mesa deliberately ignores them.
            Mesa saw that OS_X does not support that, so they said OK MS drivers does but Apple does not do it... so we won't, it is optional and is simplier

            By that logic they should implement Metal because Apple does it and also be stuck with GL4.2 or whatever they are stuck at now

            And for real it is not Mesa, but Intel since they don't play on workstation GPU space
            Last edited by dungeon; 04-12-2017, 11:56 AM.

            Comment


            • #16
              Originally posted by VikingGe View Post
              Because they need to provide support Compatibility Contexts for professional software. Mesa deliberately ignores them.

              Common trait of professional software? Code base from the 90s with a few semi-modern features stacked on top with every new version.
              Exactly, compatibility contexts and workstation apps are the biggest reason. Moreover, it's not like dropping the closed driver on Linux would translate into lots more developers for mesa. The closed OGL team supports multiple OSes that still need OGL support.

              Comment


              • #17
                Originally posted by agd5f View Post

                Exactly, compatibility contexts and workstation apps are the biggest reason. Moreover, it's not like dropping the closed driver on Linux would translate into lots more developers for mesa. The closed OGL team supports multiple OSes that still need OGL support.
                So in other words, Use amdgpu-pro for OpenGL support only when the app you use requires compatibility profiles. And also because of that AMD is forced to spend huge amounts of resources pooling developers from other OS drivers in order to support that, which as you say doesn't benefit Linux at all, not even a tiny little bit.

                Why doesn't AMD instead decide to take the financial and human resources it wastes on proprietary drivers and use them to assist it's customers in modernizing their codebases to actually work with correct modern drivers? It seems like that -would- actually benefit linux and AMD and foremost their customers.

                Comment


                • #18
                  Well, Vulkan is also for workstations Just to aware people of that... it is not gaming-only API could be used for computations only. Vulkan is both graphic and compute API, just one part of potentional usage are games So making one VK game run, does not mean you are on par with blob implementation... it is the same as with GL...

                  We are all app driven, if Mesa can't do what blob can... basically use blob or the opposite if Mesa do all you need then you don't need blob It is up to user and per usage scenario to decide.
                  Last edited by dungeon; 04-12-2017, 12:26 PM.

                  Comment


                  • #19
                    Originally posted by duby229 View Post
                    So in other words, Use amdgpu-pro for OpenGL support only when the app you use requires compatibility profiles. And also because of that AMD is forced to spend huge amounts of resources pooling developers from other OS drivers in order to support that, which as you say doesn't benefit Linux at all, not even a tiny little bit.
                    I'm not sure I follow. Windows is still a large percentage of the PC market. We still need to support that market. The OGL driver used for windows supports compatibility profiles and has a lot of optimizations for workstation apps. With relatively little effort, we can leverage that driver on Linux as well to support those markets.

                    Originally posted by duby229 View Post
                    Why doesn't AMD instead decide to take the financial and human resources it wastes on proprietary drivers and use them to assist it's customers in modernizing their codebases to actually work with correct modern drivers? It seems like that -would- actually benefit linux and AMD and foremost their customers.
                    What waste are you talking about? There aren't huge separate closed source Linux teams. There is a closed source OGL driver supported by a single team that supports multiple OSes. The thing is, there are a lot of workstation customers that want to use our GPUs to run workstation apps on Linux today.

                    Comment


                    • #20
                      Originally posted by agd5f View Post

                      I'm not sure I follow. Windows is still a large percentage of the PC market. We still need to support that market. The OGL driver used for windows supports compatibility profiles and has a lot of optimizations for workstation apps. With relatively little effort, we can leverage that driver on Linux as well to support those markets.



                      What waste are you talking about? There aren't huge separate closed source Linux teams. There is a closed source OGL driver supported by a single team that supports multiple OSes. The thing is, there are a lot of workstation customers that want to use our GPUs to run workstation apps on Linux today.
                      Which is what you said in the last post. But if the fundamental problem is that those apps are using compatibility profiles, and that compatibility profiles are the wrong thing to do, then doesn't it make more sense for AMD, Linux and, AMD's customers, to eliminate the compatibiliy profile requirements from those broken apps?

                      I mean after all they -are- your customers. Don't you think it makes better sense to ensure your customers use correct code so that their app and your drivers can function on linux according to standards?

                      Waste is obvious. Where is the open source OpenCL, Vulkan, etc? Still not open source. Still developed behind closed doors. Still no communication. And by every account there at least dozens of developers working on it internally at AMD. That's plainly obvious massive waste.
                      Last edited by duby229; 04-12-2017, 12:49 PM.

                      Comment

                      Working...
                      X