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

[darkbasic]

I switch from Nvidia to AMD last year when the Vega64 came out, after reading how great AMD are on Linux now. Worst PC hardware decision I've ever made.

The problem is that those softwares are niche and they have only been tested on Nvidia hardware for a long time: bugs are expected. The only sad part about this whole story is that after a year nobody from AMD bothered to fix it. We really need developers to care about non-performance related issues, otherwise doing a few more fps in some games will be simply useless if the system doesn't render or simply crashes.

[bridgman]

The problem is that those softwares are niche and they have only been tested on Nvidia hardware for a long time: bugs are expected. The only sad part about this whole story is that after a year nobody from AMD bothered to fix it.

Have the problems been investigated and shown to be driver issues ? As a general rule when something is only tested on NVidia hardware it's just as likely that the problem is NVidia-specific API usage.

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" ?

We really need developers to care about non-performance related issues, otherwise doing a few more fps in some games will be simply useless if the system doesn't render or simply crashes.

If you look through the commits I think you'll find that more work goes into bug fixes than performance improvements... or are you saying there should be zero work on performance improvements until all bugs have been investigated ?

[darkbasic]

Have the problems been investigated and shown to be driver issues ? As a general rule when something is only tested on NVidia hardware it's just as likely that the problem is NVidia-specific API usage.

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" ?

No, I'm simply saying that after one year it should be clear whatever is the driver or the emulator to cause this issue.
Also that user reported a couple of bugs where the whole system gets unresponsive: whatever the emulator is doing the driver shouldn't crash the whole system.

If you look through the commits I think you'll find that more work goes into bug fixes than performance improvements... or are you saying there should be zero work on performance improvements until all bugs have been investigated ?

I'm simply saying that having a fast driver won't help you if your favorite applications crash your system. I'm not saying that you shouldn't do performance optimizations, I'm simply saying that having the software working is more important in my opinion.
Maybe there are simply not enough resources to get everything fixed, but still I find it sad that after one year we still didn't get a fix considering how fare we've gone on the performance front in that timeframe.

Please don't take it personally, because it isn't. I really appreciate your work and my opinions about this won't change that.

[pete910]

The Vega64 is doing quite well, shame its not a 250W card tho.
Wish AMD would limit their TDP to 250W, 300W is just silly IMO because you end up with allot of heat and a very large card and heatsink with no small form factor options.

Also I think the RTX2060 performs better under windows last time I checked, it was on the heels of the 2070! Maybe NVIDIA needs to do some work with the linux drivers for that card?



So those specific emulators has issues with the card? and you know for damn sure that VRM/CORE/Memory isn't overheating?

There cards are limited to 220 for the ref under linux and 264 for the llc variant

I only know this due to ahving flashed the LLC bois to ny ref card and noticed the difference

amdgpu-pci-0c00
Adapter: PCI adapter
vddgfx:       +0.84 V 
fan1:           0 RPM  (min =  400 RPM, max = 3300 RPM)
GPU:          +24.0°C  (crit = +74.0°C, hyst = -273.1°C)
power1:       12.00 W  (cap = 264.00 W)

[dungeon]

No, I'm simply saying that after one year it should be clear whatever is the driver or the emulator to cause this issue.

If you read these two bugs, you would notice that 107612 bug is Vega specific, while 108317 bug seems to be Polaris specific.

So, it is an driver issue for specific hardware according to the comments there.

[agd5f]

Also debugging and testing emulators has potential legal implications which makes them hard for developers to get involved in.

[geearf]

Have the problems been investigated and shown to be driver issues ? As a general rule when something is only tested on NVidia hardware it's just as likely that the problem is NVidia-specific API usage.

When the system freezes/crashes, I think it becomes irrelevant if upstream devs are using Nvidia-specific stuff or not, unlike performance/visual issues.

Also debugging and testing emulators has potential legal implications which makes them hard for developers to get involved in.

Are traces as dangerous since they include visuals from the games or would they be safer?
I'm sure we would all be happy to run whatever debugging tool we could to get the needed info without providing endangering material.

[agd5f]

When the system freezes/crashes, I think it becomes irrelevant if upstream devs are using Nvidia-specific stuff or not, unlike performance/visual issues.

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.

[dungeon]

Are traces as dangerous since they include visuals from the games or would they be safer?

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

[bridgman]

Are traces as dangerous since they include visuals from the games or would they be safer?
I'm sure we would all be happy to run whatever debugging tool we could to get the needed info without providing endangering material.

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.

TheYoshiGuy did a lot of work to try to narrow the problem down to specific API calls (ie something that we could work on) and and Andrey/Marek put a lot of work into supporting / improving the debug/logging tools but looks like they were never able to capture enough info at driver level to figure out what was going on. At first glance it's probably going to take someone outside AMD to do some logging at WINE or application level to narrow the problem down to a specific set of API calls and a more reproducible test case.

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.

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