Company of Heroes 2 Is The Latest Linux Game Showcasing AMD's Performance Wreck With Catalyst

[duby229]

I know this has already been said, but the facts are that nVidia, OpenGL implementation on linux is not exactly conformant to the standards. We all know this, we've known it for years. Add in the fact that so many dumbasses only test on nVidia hardware and there's part of the problem. Even though nVidia's driver is not standards compliant, it's not the fault really. It's game devs relying on that behavior that is the real problem. Too many companies and projects know that behavior they rely on is not standards conformant and they do it anyways, so it's their own damn fault.

EDIT: and yes Catalyst sucks, but that's not news. At this point AMD simply dropping Catalyst totally on linux would be the best thing they could do for their image, but that's not going to happen, so just stop bitching about it. If it irks you so badly don't use it. The OSS drivers are way better anyways, there is no point in even trying to use Catalyst.

I can point out numerous occasions where AMD devs have said that Catalyst is not intended for linux desktop users. So benchmarking in scenarios where it is used by desktop users is wrong. In every desktop use case the OSS driver is the -ONLY- relevant linux driver for AMD hardware. Bitching about use cases that Catalyst isn't intended for is part of the problem. If you are benchmarking games, that's a desktop usage scenario, you should -ONLY- use the OSS drivers.

[artivision]

I know this has already been said, but the facts are that nVidia, OpenGL implementation on linux is not exactly conformant to the standards. We all know this, we've known it for years. Add in the fact that so many dumbasses only test on nVidia hardware and there's part of the problem. Even though nVidia's driver is not standards compliant, it's not the fault really. It's game devs relying on that behavior that is the real problem. Too many companies and projects know that behavior they rely on is not standards conformant and they do it anyways, so it's their own damn fault.

EDIT: and yes Catalyst sucks, but that's not news. At this point AMD simply dropping Catalyst totally on linux would be the best thing they could do for their image, but that's not going to happen, so just stop bitching about it. If it irks you so badly don't use it. The OSS drivers are way better anyways, there is no point in even trying to use Catalyst.

I can point out numerous occasions where AMD devs have said that Catalyst is not intended for linux desktop users. So benchmarking in scenarios where it is used by desktop users is wrong. In every desktop use case the OSS driver is the -ONLY- relevant linux driver for AMD hardware. Bitching about use cases that Catalyst isn't intended for is part of the problem. If you are benchmarking games, that's a desktop usage scenario, you should -ONLY- use the OSS drivers.

When you people will understand. Radeon GPUs on OpenGL fail with two different drivers (AMD, Gallium). Geforce GPUs work great on OpenGL with two different drivers (Nvidia, Gallium at 85% when full reclocking). Radeon has "near good" performance on D3D (including Gallium Nine, at 75%), Nvidia has more. We will see for low level APIs. Conclusion: You don't buy AMD for OpenGL regardless of the driver you want to use. You buy AMD for OpenCL and D3D, at least till Nouveau has full reclocking for the "big" and the "new" GPUs.

[duby229]

When you people will understand. Radeon GPUs on OpenGL fail with two different drivers (AMD, Gallium). Geforce GPUs work great on OpenGL with two different drivers (Nvidia, Gallium at 85% when full reclocking). Radeon has "near good" performance on D3D (including Gallium Nine, at 75%), Nvidia has more. We will see for low level APIs. Conclusion: You don't buy AMD for OpenGL regardless of the driver you want to use. You buy AMD for OpenCL and D3D, at least till Nouveau has full reclocking for the "big" and the "new" GPUs.

When will you realize that all the nVidia only validation you do hurts everyone. Whether you like it or not AMD products do exist and they will continue to exist. So you go right ahead and continue nvidia only testing of the code you write, but all those people using your code on AMD hardware hurts because of you. Validation is not an end users choice, that's your responsibility. Everytime you choose to ignore the needs of people using your code you screw them over. Code needs tested, you know that better than most people do, so deciding to not validate your code is your fault.

Your numbers are entirely made up. The fact is that mesa is really heavily CPU bound, even on the best drivers on the best hardware. There is no chance that any high end hardware will be capable of getting near 100% of it's potential. That means that right now, AMD has the very best support across the widest range of available hardware.

EDIT: Nvidia's proprietary driver is not standards compiant. Every single time you optimize for nVidia you're writing broken code. Which is fine because that's the point. But, you should be doing -exactly- the same thing for AMD, and when you don't that's your own fault. You are to blame for writing broken code optimized for nvidia and not doing your due diligence for AMD. The people using your code deserve that much. Whether you like it or not AMD users will continue to exist.

Just run conformancy tests on nvidias driver, go ahead and see for yourself.

[artivision]

When will you realize that all the nVidia only validation you do hurts everyone. Whether you like it or not AMD products do exist and they will continue to exist. So you go right ahead and continue nvidia only testing of the code you write, but all those people using your code on AMD hardware hurts because of you. Validation is not an end users choice, that's your responsibility. Everytime you choose to ignore the needs of people using your code you screw them over. Code needs tested, you know that better than most people do, so deciding to not validate your code is your fault.

Your numbers are entirely made up. The fact is that mesa is really heavily CPU bound, even on the best drivers on the best hardware. There is no chance that any high end hardware will be capable of getting near 100% of it's potential. That means that right now, AMD has the very best support across the widest range of available hardware.

EDIT: Nvidia's proprietary driver is not standards compiant. Every single time you optimize for nVidia you're writing broken code. Which is fine because that's the point. But, you should be doing -exactly- the same thing for AMD, and when you don't that's your own fault. You are to blame for writing broken code optimized for nvidia and not doing your due diligence for AMD. The people using your code deserve that much. Whether you like it or not AMD users will continue to exist.

Just run conformancy tests on nvidias driver, go ahead and see for yourself.

No you are wrong. There is nothing wrong with Drivers (closed or open), and there is nothing wrong with OpenGL games. There is nothing to be fixed to run better on Radeon. I wish you were right and game devs are prefer Nvidia, but you are not, sorry.

http://www.phoronix.com/scan.php?pag...318_blob&num=2

Look at GF650 full recloacking. With Kernel 4.3 and newer Mesa will be even better.

[duby229]

No you are wrong. There is nothing wrong with Drivers (closed or open), and there is nothing wrong with OpenGL games. There is nothing to be fixed to run better on Radeon. I wish you were right and game devs are prefer Nvidia, but you are not, sorry.

http://www.phoronix.com/scan.php?pag...318_blob&num=2

Look at GF650 full recloacking. With Kernel 4.3 and newer Mesa will be even better.

You posted a benchmark that just shows overhead in mesa and that's it that's all it shows. What it doesn't show is that nvidia's proprietary driver is not compliant with OpenGL standards, Every game that optimizes for that driver optimizes for non-compliance. Nvidia's driver exposes behavior on linux that only it exposes. Any code that gets written like that will not run well on anything else. That is exactly what the problem is for a number of games. Validation is not an end users responsibility. That's something that the game devs need to do themselves. AMD products exist and they will continue existing, get used to it and deal with it. Not for your sake, but for the sake of the people that use your code.

When you write code that relies on behavior that only nvidia's driver exhibits then tell me how is that anyones fault but your own?

Just run conformance tests on nvidias driver and you can see that for yourself.

[vadimg]

Can the game perform a shader cache ? Which, since compiled without sb, are then now reused every time even if sb is re-enabled ? I don't now if an app can do this. And I don't remember Gallium has a shader cache implemented.

AFAIK, no, mesa doesn't support the extensions to get a shader binary, so the game can't save and reuse them. Mesa's own cache patches are not pushed yet as well, unless I've missed it. So no shader cache at all currently (AFAIK).

[vadimg]

No you are wrong. There is nothing wrong with Drivers (closed or open), and there is nothing wrong with OpenGL games. There is nothing to be fixed to run better on Radeon. I wish you were right and game devs are prefer Nvidia, but you are not, sorry.

There is a lot wrong with NV drivers, otherwise mesa wouldn't need a lot of drirc config hacks just to support broken non-compliant apps, e.g. Unigine benchmarks. And there is a lot wrong with the games, just imagine you write a game using the extensions supported by NV to optimize everything, and then you run it on a non-NV hardware that supports a different set of extensions due to the hardware and the driver differences. Surely it will work bad, if it will work at all. There are games that work fine with catalyst, and it proves that AMD drivers are good enough, you just need to test and optimize the game for them in the same way as you do it for NV. If you don't do it, it's your fault, not AMD's, because AMD hardware doesn't have to support the same set of extensions (and driver bugs) as NV.

[artivision]

There is a lot wrong with NV drivers, otherwise mesa wouldn't need a lot of drirc config hacks just to support broken non-compliant apps, e.g. Unigine benchmarks. And there is a lot wrong with the games, just imagine you write a game using the extensions supported by NV to optimize everything, and then you run it on a non-NV hardware that supports a different set of extensions due to the hardware and the driver differences. Surely it will work bad, if it will work at all. There are games that work fine with catalyst, and it proves that AMD drivers are good enough, you just need to test and optimize the game for them in the same way as you do it for NV. If you don't do it, it's your fault, not AMD's, because AMD hardware doesn't have to support the same set of extensions (and driver bugs) as NV.

Define non-compliant apps. I you say that OGL games use extensions that only Nvidia has, then you are wrong, there are not such extensions. If you mean the way that each driver accepts them, then you speak for something that doesn't exist. SM4-5 are not prefixed but fully programmable, there are not non-compliant SM4-5 apps. So any compute shader can fail for example in a non-capable hardware. Nouveau (Gallium) has almost the performance of Nvidia-driver when reclocked. Its not the drivers or the game, if there was they would have fix it. I propose to AMD to start with new MIMD hardware and smaller units.

[bridgman]

Define non-compliant apps.

Apps which use combinations of API calls and/or shader code which do not comply with the OpenGL spec. For example :

This is a bug in Unigine's engine. It's supposed to request that functionality by one of these options:

1. Specifying #version 130 (it doesn't, so it gets 110, which is mandatory spec behavior)

2. Specifying #extension GL_EXT_texture_array : require

Since it does neither of those, we don't offer the functionality. Which is correct behavior, and not a problem with any other applications.

That said, we did put in a workaround for their apps (our first ever). You simply need to install a drirc. This should happen on 'make install', but you can also copy src/mesa/drivers/dri/common/drirc to either /etc/drirc or ~/.drirc. That automatically detects Unigine binary names and applies the two necessary workarounds:

1. force_glsl_extensions_warn - let them use extensions without asking, but warn on use

2. disable_blend_func_extended - disable the ARB_blend_func_extended extension, which at least Heaven completely misuses in a way that can't possibly work.

https://bugs.freedesktop.org/show_bug.cgi?id=43477 (the bug ticket is actually about the driver workaround not being implemented yet)

There are a lot of others (sometimes the game devs fix them, sometimes driver devs have to work around them) but you get the idea. Not picking on Unigine here, this just happened to be the first example I found.

[artivision]

Apps which use combinations of API calls and/or shader code which do not comply with the OpenGL spec. For example :



https://bugs.freedesktop.org/show_bug.cgi?id=43477 (the bug ticket is actually about the driver workaround not being implemented yet)

There are a lot of others (sometimes the game devs fix them, sometimes driver devs have to work around them) but you get the idea. Not picking on Unigine here, this just happened to be the first example I found.

Then why Nouveau (Gallium) and Intel (Mesa), smashes r600 and RadeonSI (Gallium), with smaller and cheaper hardware?