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

[DumbFsck]

What kind of jerk tells others to ignore someone else? You some kind of online bully?

> See one person calling another lazy and stupid and other stuff to the point that person is insulted to the point of leaving the conversation.
> Tell them to ignore whoever is throwing insults instead of good points
> Be called a bully

Gz, you're the worst troll I've read today. Back in my day bait used to be believable.

Also, you completely misread what I said about firmware. Or at least pretended to. Feel free to re read it until you get it, then of you have a point I'd be likely to engage. Not 100%, but likely.

Cheers

[cb88]

Honestly, just ignore cb88. Your contributions (to the thread here, not only the driver and your work) are greatly appreciated.

I think if cb88 was to follow his own "logic" to its conclusion he would say that if a firmware is too complex and the driver can't do anything to the physical hardware directly than it is not a driver...



Anyways, what distro do you recommend as in they are easy to work with in case they break something? OpenSUSE ok?


Also, if you ever write that blog post, count on at least me to read it. Cheers.

Firmware isn't a driver... its the embedded software on a board period. And yes that could even include a compiler, in fact many if not most firmwares have included some sort of scripting or low level programming software.

In any other situation, a compiler in the "driver" is not a driver, its SDK or toolchain. What kind of jerk tells others to ignore someone else? You some kind of online bully?

[Martyn]

This is not going to happen. OEM/Hardware market has not learned how to work with Open Source.
If everything were that simple, AMD would have agreed with Valve a long time ago and would not have started making their own AMDVLK.

AMD is thinking 10-15 years ahead. Valve itself does not know what will happen in 2-3 years.

I agree with most of this.

However, AMD isn't thinking of the present, let alone the future. When they rewrote their OpenGL stack for their PRO drivers, they clearly didn't QA professional apps like Rhinoceros which would present black viewports for a whole year, forcing people to choose between non-working software and unfixed bugs the whole time, instead of dynamically switching stacks for games vs. professional apps. They did get to claim to they improved Minecraft performance though. Their Vulkan support has similarly been buggy and lacking for a long time, causing applications like Enscape to crash the entire system in some cases.

Given we're seeing Linux sometimes outperform Windows at gaming with specific games specifically using AMD cards with Linux Vulkan drivers shows that there is some merit to having the community handle the Vulkan side of things. It can't be worse than how things currently are IMHO

[Venemo]

Your contributions (to the thread here, not only the driver and your work) are greatly appreciated.

Thank you for your kind words.

Anyways, what distro do you recommend as in they are easy to work with in case they break something? OpenSUSE ok?

To be honest, I don't want to judge OpenSUSE because I've personally never used it nor know anyone who uses it.

Most people on my team tend to use Fedora or Arch and seem happy with those.

Also, if you ever write that blog post, count on at least me to read it. Cheers.

Thanks!

[DumbFsck]

Well, what a shame that us "stupid" people work on the Linux graphics stack then. Anyway, I just kindly ask you not to tell this to our employers, it would be a shame if they found out that we are "stupid", furthermore we even work on something that "isn't a driver" when they pay us for driver development. /s



Technically, ANGLE is a layered OpenGL implementation. However, from the application's perspective it acts as an OpenGL driver, so you can colloquially call it a driver.



Yes, RADV configures and controls the hardware, it is a driver.



That is correct (and I already agreed on this point), a compiler is NOT a driver, but PART of a driver. Each userspace graphics driver must have a shader compiler, otherwise it would be pretty much useless. For example, in RADV, our compiler is called ACO.

Anyway... jokes aside, I don't appreciate being insulted, so I probably won't participate in this thread anymore. However, I see there is a lot of confusion in the minds of people about how the graphics stack works so I might write a blog post about this eventually to hopefully clear it up. I hope that will help Linux enthusiasts understand more how their system works.

Honestly, just ignore cb88. Your contributions (to the thread here, not only the driver and your work) are greatly appreciated.

I think if cb88 was to follow his own "logic" to its conclusion he would say that if a firmware is too complex and the driver can't do anything to the physical hardware directly than it is not a driver...



Anyways, what distro do you recommend as in they are easy to work with in case they break something? OpenSUSE ok?


Also, if you ever write that blog post, count on at least me to read it. Cheers.

[Venemo]

No it's just lazy to call everything that interacts with a piece of hardware or runs on it "The driver" stupid even.

Well, what a shame that us "stupid" people work on the Linux graphics stack then. Anyway, I just kindly ask you not to tell this to our employers, it would be a shame if they found out that we are "stupid", furthermore we even work on something that "isn't a driver" when they pay us for driver development. /s

Where is it gonna stop is ANGLE in the browser a driver? Come on quit clowning and just follow sane naming conventions.

Technically, ANGLE is a layered OpenGL implementation. However, from the application's perspective it acts as an OpenGL driver, so you can colloquially call it a driver.

Drivers configure and control hardware.

Yes, RADV configures and controls the hardware, it is a driver.

A compiler is NOT a driver that is application software running on the target hardware via a driver.

That is correct (and I already agreed on this point), a compiler is NOT a driver, but PART of a driver. Each userspace graphics driver must have a shader compiler, otherwise it would be pretty much useless. For example, in RADV, our compiler is called ACO.

Anyway... jokes aside, I don't appreciate being insulted, so I probably won't participate in this thread anymore. However, I see there is a lot of confusion in the minds of people about how the graphics stack works so I might write a blog post about this eventually to hopefully clear it up. I hope that will help Linux enthusiasts understand more how their system works.

[cb88]

Yes, the userspace driver controls and manages your hardware in order for it to draw pixels on your screen.



A compiler is indeed not a driver, but it's an important part of every graphics driver. Modern HW literally cannot draw anything without shaders. (When you don't specifiy a shader to a draw, the driver will have to generate one for you.)



I guess if you don't work on the drivers, it can become fuzzy to follow what is running on top of what.

The userspace driver does not run "on top of" the kernelspace driver, but the two pieces of software cooperate.

In the presentation that Faith gave at XDC, she showed RADV (a userspace driver) running alongside of AMD's proprietary kernel driver.



I've been working on RADV for a few years now and I am pretty sure that it "manages" the card... what else would it do.

Maybe the confusion happens because on Windows, the kernelspace driver and various userspace drivers are packaged together, so the distinction is not apparent to most people. The kernel driver alone is not enough to render anything useful. I guess in your words you could say it doesn't "manage" your GPU on its own. Userspace drivers exist because it isn't feasible to solve everything from the kernel.

It is disingenious to argue with driver developers about what a driver is.

No it's just lazy to call everything that interacts with a piece of hardware or runs on it "The driver" stupid even.

Where is it gonna stop is ANGLE in the browser a driver? Come on quit clowning and just follow sane naming conventions.

Drivers configure and control hardware. A compiler is NOT a driver that is application software running on the target hardware via a driver.

[Venemo]

The definition of a driver is something that controls or manages that piece of hardware.

Yes, the userspace driver controls and manages your hardware in order for it to draw pixels on your screen.

a compiler is not a diver a library that gets complied by that compiler to run on the GPU is not a driver

A compiler is indeed not a driver, but it's an important part of every graphics driver. Modern HW literally cannot draw anything without shaders. (When you don't specifiy a shader to a draw, the driver will have to generate one for you.)

Everything they talkeda bout porting runs on top of AMDs proprietary driver as an open user land for that card...

I guess if you don't work on the drivers, it can become fuzzy to follow what is running on top of what.

The userspace driver does not run "on top of" the kernelspace driver, but the two pieces of software cooperate.

In the presentation that Faith gave at XDC, she showed RADV (a userspace driver) running alongside of AMD's proprietary kernel driver.

it doesn't manage the card at all

I've been working on RADV for a few years now and I am pretty sure that it "manages" the card... what else would it do.

Maybe the confusion happens because on Windows, the kernelspace driver and various userspace drivers are packaged together, so the distinction is not apparent to most people. The kernel driver alone is not enough to render anything useful. I guess in your words you could say it doesn't "manage" your GPU on its own. Userspace drivers exist because it isn't feasible to solve everything from the kernel.

It is disingenious to argue with driver developers about what a driver is.

[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.

[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.