AMDGPU-PRO 17.10 vs. Mesa 17.1 RADV/RadeonSI Performance

[M@yeulC]

Thank you bridgman for your comment(s), I can't imagine the amount of BS you are going trough in a daily basis.

Regarding the article, that's some impressive OpenGL performance,and there is probably still a bit of headroom; congrats devs!

[bridgman]

Thanks.

I wasn't able to view the graphics (just the text and pictures) on either Linux/Firefox or my Windows/IE admin system. Is anyone else having problems ?

[Michael]

Thanks.

I wasn't able to view the graphics (just the text and pictures) on either Linux/Firefox or my Windows/IE admin system. Is anyone else having problems ?

Should be working fine. Can you access http://openbenchmarking.org/ directly?

[Marc Driftmeyer]

With respect, it seems that you may not have not been following things for the last couple of years. What you describe is exactly what we have been doing (other than the admitting defeat part):

- AMDGPU-PRO has always been the workstation driver, but it was a useful stopgap until we could get Mesa GL up to 4.5 to meet consumer/gaming needs)

- AMD developers have been working on the open source driver (kernel, X and Mesa) for >9 years now (along with community developers); what you are seeing in the open source drivers is the cumulative result of that work

- work is proceeding on open sourcing the Vulkan driver so it can become part of the open source stack

- the OpenCL driver has been rewritten to use the open source ROCm stack and LLVM-based shader compiler; all pre-requisites to open sourcing OpenCL itself

- Marek & Nicolai have been working on open source OpenGL performance for a good part of the last year; prior to that they were focusing on extending the GL support level up to 4.5 so that the modern games could run

I'm trying to fathom the lunacy of people demanding you admit defeat when your modernized code that has been open to more eyes has improved the original stack, albeit now in an officially FOSS capacity.

It's not FOSS that made it possible, but the collective efforts of LLVM/Clang and all the companies maturing that stack, to third party OEMs directly and indirectly pitching in. Only after the Legal Team has signed off on this stack does it get pushed out.

No group of renegade pirates rewrote the stack. The combined efforts of talent developers made it possible. Your efforts and insights on the proprietary stack avoided on the non-proprietary made it possible.

[Morbis55]

bridgman yes I know it's AMDs devs that are working on Mesa but why not conentrate only on that?
Benchmarks clearly show Mesa is superior to AMDGPU-Pro.
So why would I use it instead of Mesa? Well because only with AMDGPU-pro I can use FreeSync - and not even as good as under Windows.
E.g. where is the option to cut frames over 144fps? Correct, that is windows only ...
Also you cant use AMDGPU-pro with a non LTS version. No Support for 16.10 / 17.04

[muncrief]

No Man's Sky is actually a native OpenGL game, even on windows. Similar to Doom 2016. In both cases it's clear the games were developed around the windows proprietary drivers.



You can try setting this environment variable to see if it works: MESA_GL_VERSION_OVERRIDE=4.5COMPAT

I think it doesn't work with Doom because the game actually uses some compat features, but maybe No Man's Sky would.

Thank you for the suggestion, but I've tried that and it fails in numerous ways. Depending upon the Mesa override Wine Steam often won't even start, but there are usually tricks to make it get that far. But I've never had any games work when using the various Mesa overrides. I've spent many man weeks, stretching into months, trying to get a working game installation on my Xubuntu 16.04.2 but as I said for the most part I've given up. And I'm talking compiling everything from custom kernels to custom wine installations, to trying every trick and suggestion I can find to get the limited number of games I have working. I'm an embedded systems designer with over three decades of experience designing hardware, firmware, and software so I'm not without skills. It's just that at this point I'm out of ideas.

As others have said it's certainly not true that all of the gaming problems with Wine are the fault of AMDGPU-PRO. However on the other hand it's counterproductive to insist that nothing is the fault of AMDGPU-PRO. As I said, and I don't mean to insult those who are working hard on it, the fact is that the state of AMDGPU-PRO today is abysmal, at best. And as I've also said before, pulling stable AMD support from Linux at the same time a giant push for Linux gaming was being forwarded by Steam is absolutely befuddling.

Finally, I'm not even that much of a gamer. My goal is simply to see Linux gaming stable enough to ween more of my friends and associates off Windows 10, which I consider nothing more than the worlds first legal botnet.

[Guest]

I'm trying to fathom the lunacy of people demanding you admit defeat when your modernized code that has been open to more eyes has improved the original stack, albeit now in an officially FOSS capacity.

It's not FOSS that made it possible, but the collective efforts of LLVM/Clang and all the companies maturing that stack, to third party OEMs directly and indirectly pitching in. Only after the Legal Team has signed off on this stack does it get pushed out.

No group of renegade pirates rewrote the stack. The combined efforts of talent developers made it possible. Your efforts and insights on the proprietary stack avoided on the non-proprietary made it possible.

You're wrong, as usual. We have much older, mature proprietary stack and quite new Open Source one made by FLOSS developers. The later one is much faster. What stops them from improving proprietary stack and why weren't they able to make it better for last few years? Llvm license? Don't think so. Lack of manpower? Possible. Ps. Those renegade pirates made graphic stack which is light years ahead of os x proprietary crap. The same when comes to compiler, so stop spreading propaganda. FLOSS is the best.

[ElderSnake]

Good to see Mesa doing so well. When I upgraded my desktop some months ago I took the leap to AMD after using NVIDIA GPUs for years.
And I haven't been able regretted it at all. There are some edge cases of things that don't work properly but it seems anything that is coded/optimized properly and has a sane way of doing things work just fine. I bought and played some of Yooka Laylee last night and was pleased to find it runs fine on AMDGPU + Mesa

[dungeon]

Something is very wrong with these charts i think

Dota for example, see here 16.60 from january Dota 4K OpenGL vs Vulkan:

http://www.phoronix.com/scan.php?pag...-60-radv&num=3

Fury 69.70 on Mesa and 58.83 on Pro, and now 69.67 on Pro but 59.23 on Mesa numbers seems permuted or something:

http://www.phoronix.com/scan.php?pag...pro-1710&num=3

Colors are permuted OK but numbers also, can't be that that improvments and regressions between drivers exactly matches there

Joke aside, messy results

[bridgman]

bridgman yes I know it's AMDs devs that are working on Mesa but why not conentrate only on that?
Benchmarks clearly show Mesa is superior to AMDGPU-Pro.
So why would I use it instead of Mesa? Well because only with AMDGPU-pro I can use FreeSync - and not even as good as under Windows.
E.g. where is the option to cut frames over 144fps? Correct, that is windows only ...
Also you cant use AMDGPU-pro with a non LTS version. No Support for 16.10 / 17.04

Let's separate the answers into two piles - short term and longer term.

The longer term reason for keeping the AMDGPU-PRO stack is the workstation market, which is pretty much the last area where compatibility profiles are still required. Our closed GL driver supports compatibility profiles, while Mesa does not and the Mesa developer community is generally opposed to adding support. I agree with that view for what it's worth.

We do periodically look at how many of the key applications in that market still require compatibility profiles and what the outlook is for those apps moving to core profiles (which would allow us to unify on Mesa GL) but so far the feedback has not been promising. There are also a couple of games (Dying Light, probably Minecraft) which require compatibility profiles at the moment.

In the short term, there are a couple of reasons why the AMDGPU-PRO stack is still useful to consumer/gaming customers, all related to either (a) code which is already open sourced but not yet accepted upstream or (b) code which we are in the process of open sourcing:

Most of the display-related features (eg freesync) are already in the open source driver, but we are still making changes to the code in order to have it accepted upstream. In the meantime you can build a kernel from Alex's amd-staging-4.9 (or higher kernel version if it appears) and that will work with the open source userspace and with non-LTS Ubuntu distros.

I *think* someone is already building & packaging that tree for easier use but not 100% sure.

The new DAL code had to be rewritten from scratch in order to make it acceptable to the upstream kernel (and work is still ongoing there) so it might be missing some features relative to Windows but my impression was that it either was at parity already or was close to it. I can ask about the "cutting frames about 144 hz" option, might be just a control panel issue rather than driver, not sure.

The rest of the short term issues are just open sourcing work in process as I mentioned earlier.