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

[illwieckz]

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/...r-quality.html

https://pl.dolphin-emu.org/blog/2013...all-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.

For history, at Quake3 time (around 1999) id Software made an assumptions things worked like Nvidia did. Later it was reported the code wasn't working on ATi so a fix was implemented and named an ATi fix. It turned out there was a bug in the Nvidia driver and the code should not work on Nvidia to begin with. It's now hard to find information about this but here is some summary from 2003:

This is not an issue with the ATI drivers. The ATI drivers implement an OpenGL compliant texture clamp. NV used to have a bug in their drivers where they did not clamp correctly. Applications came to work around the problem by just using the broken way of clamping. If you force the NV drivers to be compliant, you get the skybox. ATI is compliant. So are most drivers out there. It really should be the application that corrects itself, since it's doing something wrong.
-- sireric https://www.rage3d.com/board/showthr...age_1331727573

If I'm right here is an example of bug fix from 2005: https://www.quake3world.com/forum/viewtopic.php?t=10535

Even today if you look at the help of the q3map2 level compiler from NetRadiant level editor, you'll read this:

$ q3map2 -help -bsp | grep sky
-skyfix Turn sky box into six surfaces to work around ATI problems

This is decade-old legacy text is pretending “to work around ATI problems” but the truth was that Nvidia driver was buggy and provided the expected results even if the game engine was faulty and asked something else. As you see, people implemented fixes in authoring tools so the game data can be produced to workaround the engine bug relying on an Nvidia driver bug. They literally modified the game data to workaround the engine wrongly asking drivers to do something else while Nvidia provided the expected result.

More recently, it happened Nvidia provided buggy drivers that claimed an extension is supported but is not, so the game will enable the related code path and break. Since their driver code is closed source and the bug is still there in the latest version of this driver and they phase out the related hardware range, the bug is there forever and games have to implement driver detection to really disable the extensions falsely said at available:

Daemon!370@8bc6f016

It happens that with Nvidia you need to rewrite some code to do the same thing in another way because suddenly code that worked before started to produce garbage on newer driver version, rewriting the code to do things in another way is just a way to workaround some internal bugs in Nvidia driver by walking with foot right then foot left instead of foot left then foot right to avoid an hidden trap:

Daemon!479@df1feaa4

Also Nvidia is super shady as they name GPU range as GPU models and people get confused. For example there had been three variants named GeForce 8400 GS released between 2007 and 2010 with different architectures, one of these being affected by the driver bug falsely advertising as available a GL extension that is not available. So basically knowing the card is named GeForce 8400 GS is not enough to workaround the driver bug. This is not a model name, this is a product range name to capitalize on a successful name to sell newer cards thanks to previous one's reputation.

There are seven models named GeForce GTX 1060 released between 2016 and 2018. This is not a model name, this is a product range name. This is a clever marketing strategy as people would recommend to buy GTX 1060 and people would buy GTX 1060 for years, but the one recommending and the one buying don't have the same hardware. You may have noticed the GTX 1060 tops the steam Survey with 6 or 7% since years? You may want to divide that number by seven.

The Nvidia proprietary driver is the worst OpenGL driver. The best OpenGL driver is Mesa radeonsi (r600 is also pretty good). Vendor lock-in (Nvidia CUDA) is the only reason to buy Nvidia.

[Quppa]

It's great to see Linux being so competitive with graphics rendering. I'm looking forward to seeing the gaming benchmarks (particularly for Steam Play titles).

AMD's WDDM 3.1 driver is in Windows 11 22H2 (build 22621), which has hit RTM (but hasn't been rolled out to the general public yet).

[agd5f]

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

Not really? They are just a list of some potentially useful non-core extensions. If they were really important, they would have been implemented already. Some depend on hardware features that are not present. Others are just not commonly used.

[arQon]

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?

Things have varied quite a lot over the years, but no, that is absolutely not true in any way, shape, or form. It sounds, at best, very much like someone repeating a comment they heard but didn't understand, didn't get right, and accidentally turned into a lie as a result.

There were several *years* around the start of the ARB ASM era where the ATI driver wasn't even conformant on the critical path of 99% of game code at the time (didn't support locking arrays properly). To claim that it was somehow "more insistent on correctness" is laughable.

The kindest guess I can make is that your "anonymous source" was referring to the fact that the ATI driver did, at least, actually honor the filtering mode it was told to use. nvidia OTOH, at one point, would silently downgrade trilinear filtering to bilinear to cheat on benchmarks. As a result, ATI cards generally produced better-looking screenshots (but got reamed in reviews over supposedly-relative performance, obviously).

[arQon]

It's now hard to find information about this but here is some summary from 2003:

I don't remember much of the detail beyond what's already covered in the stuff you linked, but yeah: Q3 was using the wrong wrap mode, but since nvidia's CLAMP_TO_EDGE wasn't implemented correctly it looked fine there, so the bug stayed in the source for quite a few years. (There were a couple of other pieces that should really have been using TO_EDGE too, like the unmipped textures used for icons, but they all got fixed at the same time).

I do want to stress though that a minor (if annoying) cosmetic glitch is nowhere near on the same scale as failing to implement critical core functionality correctly, which is the problem ATI drivers had at the time. It's like comparing apples to orangutans.

[Awesomeness]

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.

Maybe it's just me being not a native speaker but I have trouble understanding what he's trying to say. So it's a Frankenstein of the Windows driver and the FOSS (Mesa's OpenGL's?) back-end?

Still don't understand why they invest resources into a driver no distribution, not even SteamOS, ships.

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.

Don't get me wrong: AMDVLK is 1000% better than the whitewashing NVidia is doing and can serve a purpose even if it's just a reference implementation RADV can look at and perhaps copy code.

Unless a deal mandated that AMDVLK must be different to Mesa, I still don't get it. Sure, as a quick stop-gap solution to get something in place similar to radeonhd back in the day, it could have been useful but every deal partner must see that a transition to RADV with AMD contributions is the better long-term solution.

[Vermilion]

Maybe it's just me being not a native speaker but I have trouble understanding what he's trying to say. So it's a Frankenstein of the Windows driver and the FOSS (Mesa's OpenGL's?) back-end?

Still don't understand why they invest resources into a driver no distribution, not even SteamOS, ships.

If I understood correctly, he's saying they're already investing resources into a closed source multi OS driver (presumably covers Windows, Linux and maybe consoles like PS/Xbox) and they're also investing in the LLVM-Based Pipeline Compiler (LLPC) used in ROCm, so releasing AMDVLK is not much work on its own.

every deal partner must see that a transition to RADV with AMD contributions is the better long-term solution.

Don't underestimate the weird corporate requirements, maybe an AMD partner already certified and used amdvlk in a deployed product and now they require continued support from AMD.

[Awesomeness]

If I understood correctly, he's saying they're already investing resources into a closed source multi OS driver (presumably covers Windows, Linux and maybe consoles like PS/Xbox) and they're also investing in the LLVM-Based Pipeline Compiler (LLPC) used in ROCm, so releasing AMDVLK is not much work on its own.

Contributing to RADV would be even less work but whatever. Things won't change in the near future anyway.