20-Way NVIDIA/AMD Vulkan Linux Gaming Performance Comparison

[brauliobo]

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

[bridgman]

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.

[bridgman]

sure,,, but many people read roadmaps...

True, but what I said isn't even a roadmap - it only has "today" on it

[bridgman]

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.

[duby229]

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...

[IreMinMon]

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?

[bridgman]

Excuse a noobish question, but who owns the licenses on AMD's drivers? I would have thought that AMD develops all of this in-house. If that's not the case, who does this? Is it private contractors (from India or Europe or whatever), is it maybe researchers from public sector (universities, institutes etc.) or maybe somebody else?

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.

[bridgman]

this really sounds good :-) [email protected] should write a news article for this alone.

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

[IreMinMon]

I don't know if it will be "the next few months" but our goal is to get the LLVM-based compiler speed up to the point where it can replace the current proprietary compiler in all applications.

Excuse a noobish question, but who owns the licenses on AMD's drivers? I would have thought that AMD develops all of this in-house. If that's not the case, who does this? Is it private contractors (from India or Europe or whatever), is it maybe researchers from public sector (universities, institutes etc.) or maybe somebody else?

[bridgman]

I am guessing that shader compiler is one of the reasons that in Windows AMD always beats Nvidia at Vulkan. Hopefully amdvlk can come up to that level in the next few months.

I don't know if it will be "the next few months" but our goal is to get the LLVM-based compiler speed up to the point where it can replace the current proprietary compiler in all applications.