Announcement

Collapse
No announcement yet.

20-Way NVIDIA/AMD Vulkan Linux Gaming Performance Comparison

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

  • #21
    Originally posted by bridgman View Post

    At least once we make more progress on it. I'm not a big fan of articles that just say "hey this random AMD guy said they're working on something
    sure,,, but many people read roadmaps... with nothing more in it than similar information "hey this random AMD guy said they're working on something"

    sure on phoronix.com it is news if it really happens.. sure.
    Phantom circuit Sequence Reducer Dyslexia

    Comment


    • #22
      Originally posted by Qaridarium View Post
      sure,,, but many people read roadmaps...
      True, but what I said isn't even a roadmap - it only has "today" on it
      Last edited by bridgman; 07-28-2018, 01:36 PM.

      Comment


      • #23
        Originally posted by bridgman View Post
        I should also mention the radv Vulkan driver, which was developed by non-AMD folks (mostly Dave and Bas) leveraging radeonsi code used for Mesa GL.
        I really recommend to port MesaGL to Windows

        I also recommend to end the closed source AMDGPU-PRO openGL in favor for MesaGL and porting the workstation features to MesaGL.

        In the end AMD sould save money with this move and for the people in the end they should have a better driver support.
        Phantom circuit Sequence Reducer Dyslexia

        Comment


        • #24
          Originally posted by Qaridarium View Post
          I also recommend to end the closed source AMDGPU-PRO openGL in favor for MesaGL and porting the workstation features to MesaGL.
          It depends on how the compatibility profile work goes with the apps that matter today. If it turns out that we can run all the key workstation apps with a clean driver then that is a real option, but if we end up having to add a lot of non-standard behaviour (basically duplicating all the work we had to do in the closed source driver) that becomes unattractive real fast.

          I don't know how it will work out - what makes it worth looking at is a decade of us shipping a driver with a strict API checker:

          "Your driver is crap - my app won't run on it"
          "Your app doesn't follow the OpenGL spec"
          "But it works on <vendor>"
          "It violates the OpenGL spec, see right here ? How is the driver supposed to know your app wanted <vendor-specific behaviour> ?"
          "But it works on... ouch, OK yeah I see"

          If enough of those exchanges ended with the app being fixed eventually this can work, but if the end result in too many cases was us having to hack the driver to implement non-standard behaviour then it probably won't.

          https://cgit.freedesktop.org/mesa/me...src/util/drirc

          The Mesa driver already has a few hacks to accept non-standard GL and I imagine a few more would be acceptable upstream, but some of the changes we had to make for workstation apps developed on other vendors hardware were not pretty - duplicating architectural bugs rather than just relaxing the API checker.

          The good news is that some of the broken apps that were must-have a decade ago have either fallen by the wayside or been updated.
          Last edited by bridgman; 07-28-2018, 03:17 PM.

          Comment


          • #25
            Originally posted by bridgman View Post

            It depends on how the compatibility profile work goes with the apps that matter today. If it turns out that we can run all the key workstation apps with a clean driver then that is a real option, but if we end up having to add a lot of non-standard behaviour (basically duplicating all the work we had to do in the closed source driver) that becomes unattractive real fast.

            I don't know how it will work out - what makes it worth looking at is a decade of us shipping a driver with a strict API checker:

            "Your driver is crap - my app won't run on it"
            "Your app doesn't follow the OpenGL spec"
            "But it works on <vendor>"
            "It violates the OpenGL spec, see right here ? How is the driver supposed to know your app wanted <vendor-specific behaviour> ?"
            "But it works on... ouch, OK yeah I see"

            If enough of those exchanges ended with the app being fixed eventually this can work, but if the end result in too many cases was us having to hack the driver to implement non-standard behaviour then it probably won't.

            https://cgit.freedesktop.org/mesa/me...src/util/drirc

            The Mesa driver already has a few hacks to accept non-standard GL and I imagine a few more would be acceptable upstream, but some of the changes we had to make for workstation apps developed on other vendors hardware were not pretty - duplicating architectural bugs rather than just relaxing the API checker.

            The good news is that some of the broken apps that were must-have a decade ago have either fallen by the wayside or been updated.
            so overall it does not look so bad at all. it sounds like a really good plan.
            Phantom circuit Sequence Reducer Dyslexia

            Comment


            • #26
              Michael could you please include Raven Ridge GPUs in those benchmarks?

              Comment

              Working...
              X