RADV Remains Competitive To AMD's Radeon Vulkan Windows Driver, Linux OpenGL Dominates

[phoronix]

Phoronix: RADV Remains Competitive To AMD's Radeon Vulkan Windows Driver, Linux OpenGL Dominates

I'm currently working on a fresh comparison of the Windows vs. Linux performance for Intel's Alder Lake hybrid processors due to a number of readers inquiring how the OS support has evolved. In the process of carrying out those tests I also ran some fresh Windows vs. Linux tests with the AMD Radeon RX 6800 XT for how the OpenGL and Vulkan driver performance stands...

https://www.phoronix.com/scan.php?page=news_item&px=RX6800XT-Linux-Windows-Mid-22

[M@GOid]

Over a decade ago, before AMD's opensource driver was a thing, some people used to say that the ATI/AMD proprietary OpenGL driver wasn't bad per se, just it needed the game developer to code to exactly OpenGL specifications, while the Nvidia driver was more lenient with bad code.

Is that true, or the driver was really bad and that was only fanboy talk?

[skeevy420]

Over a decade ago, before AMD's opensource driver was a thing, some people used to say that the ATI/AMD proprietary OpenGL driver wasn't bad per se, just it needed the game developer to code to exactly OpenGL specifications, while the Nvidia driver was more lenient with bad code.

Is that true, or the driver was really bad and that was only fanboy talk?

I only had about a year or two with it before AMDGPU came out, used NVIDIA before then, but for me the biggest issue with Catalyst was needing to intentionally hold back things like Mesa or the kernel for long swaths of time which could lead to dependency hell with updates. Arch People Problems. My $128 R7 260x from back then isn't the best GPU in the world to tell you how good or bad the driver performed, only the overall experience of using it which was basically "Games play well enough for me. Dammit, I didn't see Mesa update and I broke my display again. I miss NVIDIA and faster updates. This AMDGPU shit better pan out."

Seeing as how I upgraded to my current RX 580 and I'm trying to hold out for a mid-level 7000 series I'd say that AMDGPU shit panned out.

[M@GOid]

I only had about a year or two with it before AMDGPU came out, used NVIDIA before then, but for me the biggest issue with Catalyst was needing to intentionally hold back things like Mesa or the kernel for long swaths of time which could lead to dependency hell with updates. Arch People Problems. My $128 R7 260x from back then isn't the best GPU in the world to tell you how good or bad the driver performed, only the overall experience of using it which was basically "Games play well enough for me. Dammit, I didn't see Mesa update and I broke my display again. I miss NVIDIA and faster updates. This AMDGPU shit better pan out."

Seeing as how I upgraded to my current RX 580 and I'm trying to hold out for a mid-level 7000 series I'd say that AMDGPU shit panned out.

Well, that is from a end-user point of view. What I intended was a opinion from a game developer point of view.

I remember one Phoronix forum member commenting about how you could get the driver to perform, IF your code actually followed the OpenGL specs to the letter, while on the Nvidia side, shitty code had a easier time getting the fps desired.

I believed that because, on Windows, every single AAA bastard game needed a driver fix from Nvidia and AMD, otherwise it would perform poorly or refuse to work at all (I'm looking at you id's Rage...).

[Guest]

Windows 11 Dev currently has an AMD graphics driver with notably improved OpenGL performance. As far as I know, this driver isn't released anywhere else (it's not in any of the 22.5.2 drivers or 22.6.2, and it's very likely WU is delivering something much older), and it has to come from a Dev build, or https://forums.guru3d.com/threads/am...re-uwp.437511/

The latest AMD driver on Windows that has the OpenGL changes is 31.0.12001.2008

[piotrj3]

Well, that is from a end-user point of view. What I intended was a opinion from a game developer point of view.

I remember one Phoronix forum member commenting about how you could get the driver to perform, IF your code actually followed the OpenGL specs to the letter, while on the Nvidia side, shitty code had a easier time getting the fps desired.

I believed that because, on Windows, every single AAA bastard game needed a driver fix from Nvidia and AMD, otherwise it would perform poorly or refuse to work at all (I'm looking at you id's Rage...).

http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html

https://pl.dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/

Keep in mind this is from times when OpenGL didn't have many conformance tests, and Nvidia in 2014 started sharing it with Khnosos group.

[Awesomeness]

I don't get the point of AMDVLK. It's not like AMD ever worked on upstreaming it to Mesa.

[Guest]

I don't get the point of AMDVLK. It's not like AMD ever worked on upstreaming it to Mesa.

I imagine it exists for cases that need stability and expected version numbers/changes.

Basically, I couldn't tell you at all what actually changed with RADV when my distro ships an updated Mesa package, and I have to dig through commit numbers across different sites if I want to try to figure it out. But AMDVLK explains the changes nicely with a release version: https://github.com/GPUOpen-Drivers/A...ag/v-2022.Q2.3

Doesn't AMDVLK also use LLVM? That seems like a better choice for general applications, vs ACO's gaming focus. I don't know how different either are nowadays, but I heard ACO wasn't passing some tests that LLVM did. Although I'm not sure if there's a difference between AMDVLK and RADV when forced to LLVM instead?

[M@GOid]

http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html

https://pl.dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/

Keep in mind this is from times when OpenGL didn't have many conformance tests, and Nvidia in 2014 started sharing it with Khnosos group.

Well, that was illuminating. So there was some truth about everything:

- AMD's old driver did performed better if your app follow OpenGL specs, but was still very buggy and basically hopeless;

- Nvidia's driver was more lenient with bad game code so it worked well for all game developers, although it wasn't perfect by any means. And their (Nvidia) developers would do what they could to sabotage the competition, if let loose with a developers game code, while AMD's where more neutral.

[microcode]

It'd be interesting, as a qualitative measure, to look at "maximum number of dropped frames in a second at 60/120/144Hz vsync" rather than just minimum framerate. Sometimes a game will have one or two really long frames at a point that doesn't matter; but otherwise will be GPU bound or GPU driver bound.

I think something like this would give a better comparison, since it can tell you that a game is choppy, or roughly perfect, at a given display refresh rate. Obviously it makes it hard to compare very similar GPUs, but you could collate the similarities in the comparison and say "all these titles at these settings work great at 144Hz, now here's where they differ". I think this would also be a good tool for prioritizing work on the driver: “did I experience choppiness in any title?" is the more meaningful measure of driver quality vs "did most titles run really really ‘fast’?".