NVIDIA vs. Radeon Linux 5.0 + Mesa 19.0 Drivers - 14-Way Gaming GPU Comparison

[darkbasic]

BTW someone mentioned earlier that the developers only test on NVidia... is that for WINE/Linux only ?

I was not talking about the developers, I was talking about the user base: emulators running on Wine has been used mainly on Nvidia cards for a long time, because anybody serious about it had to use Nvidia in order to get a satisfying user experience.

[darkbasic]

We are able to get more deeply involved in native games, and so that's where you have seen most of the improvements...

Unfortunately native games are just a small portion of what you can actually play on Linux using Wine.
And sometimes even when native ports are available we still prefer to use Wine because it runs faster.

[dungeon]

I was briefly pleased to notice that the cemu.info site says that CEMU runs well on AMD hardware, but that was before I realized they were talking about Windows only.

Well it uses OpenGL, so if it works on Windows with AMD OpenGL, it is safe to assume how it should work on AMDGPU-PRO OpenGL, isn't it.

Now if AMDGPU-PRO OpenGL on Linux works also with CEMU, it is clearly issue in opensource driver.

.Or maybe it uses GL 4.6 path on AMD OpenGL there, since it mentioning "OpenGL 4.1 minimum (4.6 is used if available)"

[geearf]

It does matter if the application is relying on the undefined behavior of one vendor rather than another. It's hard to know what undefined behavior the application is depending on, especially if the application is closed source. Apps that run over wine further complicate things.

I honestly don't understand why it matters, freezing the system should just not be allowed (outside of stuff like infinite loops of course), but you definitely know better so I'll trust you on this. I take it back!

But where is a trace that hang these systems, i don't see it?

https://bugs.freedesktop.org/show_bug.cgi?id=108720

Here they are asking developers to run Mario Kart 8 in an CEMU to reproduce an issue

Well perhaps there is more than just this one bug you are looking at.
I know I have posted traces that others have verified.
Yes asking the devs to run through an emulator is not best, I agree...

Anything that involves AMD developers helping to troubleshoot code that emulates our customers platforms gets into murky territory, and so we generally stay away from it. Same for anything emulating Windows or DX.

We are able to get more deeply involved in native games, and so that's where you have seen most of the improvements... and in a number of cases we have the added benefit of game engine developers/porters not only testing on our HW but being able to work through the open source driver code to debug and optimize even more effectively.

Unfortunately CEMU seems to have everything stacked against it in terms of us being able to help - it emulates a customer platform, it's closed source (so only its developers know what happens between driver calls), and it is a Windows program running over WINE.

Oh indeed I did not think about the facts that all these consoles are using your chips, it's probably best not to help officialy indeed.
It wouldn't be too horrible though to have, hem hem, *unrelated bugs*, hem hem, investigated, which happen to magically solve these issues though
I know one of my wine-based bugs took about a year and a half to be resolved, and it ended being a legit issue that also plagued native games.
Maybe the Valve guys have more leeway there since they are not AMD employees wouldn't get you in trouble?
Of course I am no lawyer, so no idea what is proper and what is not.

Now if the problem is more with closed source emulators and Wine, no need to worry for there is also issues using native old Dolphin emulator!

[TheYoshiGuy]

Anything that involves AMD developers helping to troubleshoot code that emulates our customers platforms gets into murky territory, and so we generally stay away from it. Same for anything emulating Windows or DX.

BTW someone mentioned earlier that the developers only test on NVidia... is that for WINE/Linux only ?

Well, the Wii U isn't being produced anymore, and the current console (Nintendo Switch) has a Nvidia GPU, so Nintendo isn't really AMD's customer anymore
The Cemu developers do a lot of work for AMD as well, lots of AMD-specific bug fixes in their changelogs.
But yes, almost all their testing is Windows-only, since currently, Windows is the only official supported platform. When working version 1.14, they did ask us Linux+amdgpu users to run some specific tests though.

Looking forward to this, so that at least I won't have to reset my entire computer each time I build a new mesa, kernel or install a new Cemu version and try testing MK8:

https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-GPU-Reset-Recover-Def

[bridgman]

Well it uses OpenGL, so if it works on Windows with AMD OpenGL, it is safe to assume how it should work on AMDGPU-PRO OpenGL, isn't it.

Now if AMDGPU-PRO OpenGL on Linux works also with CEMU, it is clearly issue in opensource driver.

Yes-ish... the bottom part of the stack is obviously different between Linux & Windows so that's probably not a completely safe assumption, but if the app/WINE stack DID work on AMDGPU-PRO OpenGL that would definitely be useful information.

I haven't seen anyone say that yet though.

[TheYoshiGuy]

Yes-ish... the bottom part of the stack is obviously different between Linux & Windows so that's probably not a completely safe assumption, but if the app/WINE stack DID work on AMDGPU-PRO OpenGL that would definitely be useful information.

I haven't seen anyone say that yet though.

Would me installing a compatible distro (afaik, the pro driver only supports a few distros, not arch) on an external drive and installing/testing actually increase the chance of the bug being fixed?

[dungeon]

Would me installing a compatible distro (afaik, the pro driver only supports a few distros, not arch) on an external drive and installing/testing actually increase the chance of the bug being fixed?

Any more info about this is good

Basically if this Windows app (in this case that is CEMU) works on Windows with AMD OpenGL, then try same thing with AMDGPU-PRO on Linux and WINE... as that is 99% the same-ish OpenGL driver. If both works similar, that way you could claim it as not an WINE issue.

The best is if you could also make a trace that reproduce hang and that is it, that because not everyone have same games and could easely run same games... what is easy for you isn't so easy for somebody else

Ands then say, this trace works fine on Windows, works fine with AMDGPU-PRO on Linux, but hanging machine with opensource driver.

That way developer more or less could see what is really this issue about

[darkbasic]

Would me installing a compatible distro (afaik, the pro driver only supports a few distros, not arch) on an external drive and installing/testing actually increase the chance of the bug being fixed?

I also suggest you to post a trace. That way there won't be anything preventing developers to fix it.

[TheYoshiGuy]

Or are you just saying "the emulator devs aren't going to care about anything but NVidia HW so AMD is going to have to do the work" ?

Oh I just saw this one. The Cemu devs definitely care about AMD hardware. Some of the more recent releases have been almost entirely related to amd gpu specifc bugfixes. This is one of the main reasons they're planning to add a Vulkan backend (although it looks like it's still a good year away). Part of the reason they added the multi-core compiler was so that Ryzen CPUs could run BOTW at full speed, rather than just Intel.
You might have heard they don't care about amd cards on reddit, but that's just frustrated people seeing their RX580's being beaten by GTX750ti's.

Yes-ish... the bottom part of the stack is obviously different between Linux & Windows so that's probably not a completely safe assumption, but if the app/WINE stack DID work on AMDGPU-PRO OpenGL that would definitely be useful information.

I haven't seen anyone say that yet though.

I'm downloading Ubuntu 18.04.1 and the amdgpu-pro 18.50 driver and will see if MK8 locks the system. I think there's some confusion with the different bug reports. I just closed this one as it seems like a duplicate, and is not of a very high quality (why can I even resolve other people's bugs?? lol): https://bugs.freedesktop.org/show_bug.cgi?id=108720

I created this one here last year, without submitting enough information: https://bugs.freedesktop.org/show_bug.cgi?id=107612 and after that, I replied in here and started working with Andrey to get more information: https://bugs.freedesktop.org/show_bug.cgi?id=105251#c17

So since 105251 has the most data, should I just close 107612 and mark it as a duplicate of 105251, then post any further traces, testing results in 105251 ?

P.S. From what I can tell, there's no issue with running these emulators, provided you purchase the games and dump them yourself (which is what we've been doing).
Sony even used an opensource ps1 emulator for their Playstation Classic console (https://arstechnica.com/gaming/2018/...plug-and-play/)