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

[piotrj3]

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.

Keep in mind also that Nvidia (except some nitche uses by emulator) was also the most feature rich driver and nvidia was the most willing to work directly with you on optimizing the game. This is quite double edge sword because of course nvidia employees will be automatically looking at your game through prism of their driver - that is the driver they got expierience on. I wouldn't call it sabotage, I would simply call it - the more you participate the more your point of view is taking the place in software you help on.

[Vermilion]

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

According to bridgman:

As far as I know we are not and have never developed a separate open source Vulkan driver - if we had it would look a lot like RADV although it probably would not have ACO yet.

What we are doing is taking the (multi-OS but primarily developed for Windows) closed source driver and periodically sanitizing a snapshot of the code required for a Linux build. The shader compiler code is different from the closed source version but is based on the same back end we use for open source graphics drivers and the ROCm stack.

[smitty3268]

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

I think it's fairly clear AMD signed a contract somewhere stipulating that they'd provide open source drivers. AMDVLK represents the minimum required effort to fulfill that obligation.

Maybe it was with Google relating to the Stadia deal. Or maybe it's some supercomputer deal we don't even know about. In the end it doesn't really matter. From recent NVidia events you can see that the market does value such things.

[Melcar]

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?

You mean the ATI driver, before the AMD take over? Yeah, those were fun days. Performance was indeed bad, like less than 50% of the Windows driver. In the programs that worked anyway. In this particular instance it was because back then almost everyone targeted the nvidia driver, and nvidia was not always fully compliant with the OpenGL spec. Another problem was that the driver was slow to support even stable kernels (yeah, slower than the nvidia blob), so you had to have a fairly stable/old environment to even be able to install the driver (or even under the specific distros that fglrx supported). Yet another issue was the lack of features and optimizations.

[DMJC]

Even today there are 17 unimplemented OpenGL extensions on AMD OpenGL. Are they important? I don't know, will they break someone's code? Probably. It'd be nice if those last few items were completed so we had a completely functional OpenGL driver. Even if they are for crazy edge cases. I've always wondered if that was why NVIDIA always seemed to just work (even though the NVIDIA driver could be a buggy POS).

[agd5f]

Even today there are 17 unimplemented OpenGL extensions on AMD OpenGL. Are they important? I don't know, will they break someone's code? Probably. It'd be nice if those last few items were completed so we had a completely functional OpenGL driver.

Apps are not allowed to use extensions that are not present. That is the whole point of extensions. You have to check if they exist before you can use them. So the lack of a certain extension won't directly break anything unless an application requires a certain extension at which point the app won't run because the extension is not supported. Certain extensions may also require specific hardware that may not even exist on a specific GPU so there is no way to even enable those extensions in the first place.

[gnarlin]

I check mesamatrix.net and all of those 17 extentions that are unimplemented are part of the "Extensions that are not part of any OpenGL or OpenGL ES version".
I'm guessing those aren't an official part of the OpenGL standard? Would be cool though to have a completely clear green list though.

[smitty3268]

Even today there are 17 unimplemented OpenGL extensions on AMD OpenGL. Are they important? I don't know, will they break someone's code? Probably. It'd be nice if those last few items were completed so we had a completely functional OpenGL driver. Even if they are for crazy edge cases. I've always wondered if that was why NVIDIA always seemed to just work (even though the NVIDIA driver could be a buggy POS).

There are hundreds of extensions out there that aren't implemented. The vast majority of them are junk and not implemented for a reason. They may have only been implemented by a single vendor, or obsoleted by newer core GL versions released later.

It's not clear exactly which 17 you are calling out.

[bridgman]

There are hundreds of extensions out there that aren't implemented. The vast majority of them are junk and not implemented for a reason. They may have only been implemented by a single vendor, or obsoleted by newer core GL versions released later.

It's not clear exactly which 17 you are calling out.

I wasn't sure either, but I think I found them. If you go to the mesamatrix page, scroll down to "Extensions that are not part of any OpenGL or OpenGL ES version", then click on the triangle beside "Drivers details" below it you'll get a table that shows the missing extensions in red.

[DMJC]

It is the mesa matrix list I was referring to. I assume those extensions are listed there for a pretty good reason.