Announcement

Collapse
No announcement yet.

20-Way NVIDIA/AMD Vulkan Linux Gaming Performance Comparison

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

  • 20-Way NVIDIA/AMD Vulkan Linux Gaming Performance Comparison

    Phoronix: 20-Way NVIDIA/AMD Vulkan Linux Gaming Performance Comparison

    For those curious about the current performance state for the recent wave of Vulkan-powered Linux games, which so far are primarily Linux game ports from Feral Interactive, aside from Valve's Dota 2 and Croteam's games, here are some fresh benchmarks using twenty different graphics cards on the latest drivers.

    http://www.phoronix.com/vr.php?view=26640

  • brauliobo
    replied
    Michael could you please include Raven Ridge GPUs in those benchmarks?

    Leave a comment:


  • Qaridarium
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • Qaridarium
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • Qaridarium
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    Originally posted by IreMinMon View Post
    That's cool, what I meant though is who owns the "copyright" on proprietary compiler you were talking about, if not AMD?
    Ahh... all of the proprietary compiler code is AMD-authored (so we hold copyright), but because we use it across a number of OSes it builds on header files derived from files whose copyright is held by those OS vendors. Over the years it also accumulates content from various custom and semi-custom projects we have done for customers over the years, and our ability to use that content usually requires that it stay closed.

    On the other hand the LLVM back end we originally developed for Mesa GL is already the go-to shader compiler for a lot of new AMD projects, including our compute stack and AMDVLK.
    Last edited by bridgman; 07-28-2018, 12:10 PM.

    Leave a comment:


  • duby229
    replied
    Originally posted by tildearrow View Post

    The GTX 1070 is beating itself!
    "Stop hitting yourself" I used to do that to my brothers when I was a kid, that's silly...

    Leave a comment:


  • IreMinMon
    replied
    Originally posted by bridgman View Post

    I'll just tweak your question a bit to separate "license" from "copyright".

    The source code files are almost entirely X11-licensed (sometimes called "MIT license" but there are apparently over 50 different MIT licenses).

    Each contribution can have a different copyright holder (either the developer or the company that paid them to do the work, depending on local laws), so in practice the answer is "copyright is held by a bunch of individuals and companies". I imagine AMD is the largest contributor but a number of other companies and individuals are also actively contributing, and each holds copyright on their contributions.

    If developer A writes some code then they (or their employer) hold copyright on it. If developer B modifies that code (or uses portions of it for something else) then both developers (or their employers) hold copyright on the resulting code. Pretty soon you have hundreds of different entities holding copyright on something in the driver, and at that point it's basically the license and the maintainers that guide what happens from there.

    Pretty much all of the new HW support comes from AMD in-house developers, but new features (and fixes) come from a much broader range of people/companies including distro teams, game developers/porters and volunteers. 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.

    Our developers are scattered around the world (for a while it was pretty much "six developers, six countries") although the majority of the developers these days work in the Markham or Shanghai offices.
    That's cool, what I meant though is who owns the "copyright" on proprietary compiler you were talking about, if not AMD?

    Leave a comment:

Working...
X