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

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

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]

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.

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

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!

[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

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

[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