Open-Source Radeon Vulkan Driver "RADV" Demonstrated On Windows

[Ladis]

I already have a hardware accelerated Linux Mesa GPU driver on one my ancient PC. It's for S3 Virge. Unlike the original Windows driver, it adds 1) windowed mode and 2) OpenGL. The original driver is only for fullscreen Direct3D games. Even Quake 1 runs well with it (well, texture filtering must be disabled - but I still have hires and 16bit colors).

[stormcrow]

Im talking about GLonD3D12. It is in mainline mesa. the GL quality is abysmal with regular bugs, this is from a year ago, but still an issue that occurs. The issue does not occur when using zink, however at the time of when I tested, it would crash on AMD.

There's a number of long standing bugs in the AMD OpenGL default driver in Mesa. They don't exist in the Zink GL to Vulkan rewrite. Took a long time to find out where the bugs were and what terms to even use to help track down the problem with a project I was trying to help trace the problem.

We found out that AMD (and only AMD) has its shading on alpha textures reversed. Dark areas are lit while areas that should be lit are dark. That's the most visible bug, but there's others. The work around is to tell the system to use the Zink driver instead of the default driver. These bugs have been in the system for years and no one has fixed them. Yeah, it's open source and theoretically they could be fixed by anyone. The reality is that the only people that know the software and hardware under it well enough are the only people that can actually fix it. And none of them have. They rewrote it instead. The rewrite isn't the default anywhere so people end up with a poor experience all around (games, graphics manipulation, compute) with anything more than basic desktop graphics on AMD GPUs.

Nope, none of that's the case on Windows (those same bugs ruining my experience on Linux don't exist and at least basic compute works without a high end GPU). I don't know what game devs are running into with AMD drivers on Windows that they aren't with Nvidia and Intel, but from what I've seen peripherally they're probably justified for being miffed, if only in different aspects.

I'm sincerely considering Nvidia hardware next time around simply because the user experience with AMD GPUs for my use cases has been so poor once I started adding in the lack of functional GPU compute for Blender to the mix.

I also want to point out that somehow Ubuntu and all the distros that have been borrowing Ubuntu's graphics stack either broke, or removed (inadvertently or otherwise) Zink in a recent update. So now that workaround I noted above doesn't work in Mint nor MXLinux nor from what I've read, Ubuntu 24.xx. Supposedly Mesa made Zink the default earlier this year, but something broke somewhere cuz all that happened is things just completely fudged once it trickled down to some distros. Kinda ended up being the last straw and I nuked my Linux installs from high orbit cuz I'm just fed up with the whole experience.

[Leopard]

Not on Windows, but on Linux they use it just fine. They just have two separate teams for Linux and Windows. AMD could do that too btw, but even better - they don't have to if radv can work on Windows properly. That removes the need for this pointless split on Linux and uses objectively better option everywhere.

ANV is not fine.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/8210#note_1956426

This is just an example, you can find many other examples but when Intel's Windows VLK driver beats ANV that big; i wouldn't call it "fine"

[cl333r]

I really like the idea of open source drivers on Windows, this would also probably allow AMD to ditch their own closed source Vulkan driver in the long term. As a user, I'd love to build RADV for Windows with more advanced compiler flags, get more bugs fixed and get better functionality.

I would also love to pet a real pony under a rainbow, it would feel really well.

In reality we need to make the Linux desktop much better and the window$ problem will solve itself.

[Rovano]

I already have a hardware accelerated Linux Mesa GPU driver on one my ancient PC. It's for S3 Virge. Unlike the original Windows driver, it adds 1) windowed mode and 2) OpenGL. The original driver is only for fullscreen Direct3D games. Even Quake 1 runs well with it (well, texture filtering must be disabled - but I still have hires and 16bit colors).

API wars those times!
It was good for you when you already had the 3D accelerator.

[ms178]

In reality we need to make the Linux desktop much better and the window$ problem will solve itself.

This solution works for me as well. But having tinkered with Linux since Caldera in the 90s, I honestly don't know which one is coming over the finish line first.

[Venemo]

That isn't open source drivers on windows though, it is open source userspace. They are running the open Mesa Userspace on top of the proprietary driver.

Since the last 10+ years on both Linux and Windows, there is a separate kernel and userspace driver. The kernel driver is responsible for memory management, scheduling, and submitting tasks to the GPU. The userspace driver is responsible for emitting commands that the GPU understands to implement the graphics API (Vulkan, OpenGL, etc.) as well as for compiling shaders.

Both kernel and userspace drivers are called drivers for a reason, because both have significant complexity in them. And both of them are pretty much useless without the other. Mesa is already written to be able to communicate with different kernel drivers (although specifically RADV upstream only supports the amdgpu driver in Linux), so this is just adding one more.

[Venemo]

Does anyone still believe in 2024 that "game developers are tired of closed-source drivers"? "They are undebuggable without IHV help"
Does anyone imagine modern Ubisoft, Rockstar, Activion, Rocksteady, EA, Take-Two and others who will dig into the source code of the driver or its compiler? Go get some rest.

It is more common than you think. Like Faith said in the XDC talk, it is usually pretty easy for big and well-known studios to get help from IHVs, but smaller studios and indie developers have very little chance for that. This other XDC presentation can give you some more context on this topic if you're interested: https://www.youtube.com/watch?v=QF-xHTKY4H4

We have seen game (and engine) developers interact with us and/or study the RADV source code to help find bugs with their games and/or understand how the HW works.

[Venemo]

We found out that AMD (and only AMD) has its shading on alpha textures reversed. Dark areas are lit while areas that should be lit are dark. That's the most visible bug, but there's others. The work around is to tell the system to use the Zink driver instead of the default driver. These bugs have been in the system for years and no one has fixed them.

Please open an issue in the Mesa GitLab if you haven't already. If you have, please give us a link to your bug report so we can take a look. Thank you!

Yeah, it's open source and theoretically they could be fixed by anyone. The reality is that the only people that know the software and hardware under it well enough are the only people that can actually fix it. And none of them have. They rewrote it instead. The rewrite isn't the default anywhere so people end up with a poor experience all around (games, graphics manipulation, compute) with anything more than basic desktop graphics on AMD GPUs.

These are misconceptions. Zink isn't a rewrite, especially not a rewrite of RadeonSI, even though the author has a good sense of humor and likes to joke about "copying code". And it mostly isn't developed by the same people (look at the commit logs if you don't believe me). Also, Zink wasn't written "instead" of fixing RadeonSI. They are two separate drivers that coexist in the Mesa repo and both are being developed / maintained.

Nope, none of that's the case on Windows those same bugs ruining my experience on Linux don't exist.

Considering it's a different code base, it of course doesn't have the exact same bugs, but occasionally there are similar problems due to it running on the same hardware after all.

With regards to the compute experience on Linux... yeah, that's a shame. We hope that RustiCL will eventually help resolve that.

I'm sincerely considering Nvidia hardware next time around

Good luck! Let's hope that NVK will soon be a competitive driver so you can enjoy a good open source experience there.

I also want to point out that somehow Ubuntu and all the distros that have been borrowing Ubuntu's graphics stack either broke, or removed (inadvertently or otherwise) Zink in a recent update.

Sadly, distributions can indeed mess up Mesa and can be incredibly difficult to work with. Ubuntu and its derivatives are especially bad at it.

[cb88]

Since the last 10+ years on both Linux and Windows, there is a separate kernel and userspace driver. The kernel driver is responsible for memory management, scheduling, and submitting tasks to the GPU. The userspace driver is responsible for emitting commands that the GPU understands to implement the graphics API (Vulkan, OpenGL, etc.) as well as for compiling shaders.

Both kernel and userspace drivers are called drivers for a reason, because both have significant complexity in them. And both of them are pretty much useless without the other. Mesa is already written to be able to communicate with different kernel drivers (although specifically RADV upstream only supports the amdgpu driver in Linux), so this is just adding one more.

I'm well aware of that... but the user land itself is not all driver. That was my point. There is a lot of userland there that has nothing to do with being a driver... a compiler is not a diver a library that gets complied by that compiler to run on the GPU is not a driver. The definition of a driver is something that controls or manages that piece of hardware.

Everything they talkeda bout porting runs on top of AMDs proprietary driver as an open user land for that card... but it doesn't manage the card at all.

If I plug an arduino into my USB port the Arduino toolchain is NOT a driver (Except for the USB port driver). The same goes for all the stuff they ported its the toolchain for the card but it isn't the driver.