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

[FreePenguin]

Isn't there some bullshit with driver signing so you can't just compile and install your own driver without paying for signing keys to Microsoft?

[Quackdoc]

I don't give a shit. The only important thing will be possibly better support for radv that will benefit Linux users.

For app devs who live in the real world, we have to worry about windows users. OGL on windows via amd is horrendous. and the D3D12 state tracker is abysmal. So this has the potential of being highly important.

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.

Honestly why don't they port the Linux hardware driver itself to Windows (and finally bury the churn axe in that driver). Should be possible to port it all the way back to at least XP... maybe even 2k with a limited feature set.

since when have userland drivers not been drivers? In fact, it's in the name, "Userland driver"

It should be a no brainer for AMD who claimed that the need for amdvlk on Linux was for them to avoid supporting two separate drivers. radv is just better so let AMD support radv everywhere. That's it.

I doubt they will, well perhaps it's possible they could run their own for of radv, but I could foresee an over reliance on radv being detrimental to AMD

[kiffmet]

(…)OGL on windows via amd is horrendous. and the D3D12 state tracker is abysmal.(…)

You got me interested. Can you provide some more context/information regarding AMD's D3D12 UMD? They modeled a state tracker similar to i.e. gallium's frontends for this? What makes it so bad?

[shmerl]

I doubt they will, well perhaps it's possible they could run their own for of radv, but I could foresee an over reliance on radv being detrimental to AMD

Why? Relying on anv is not detrimental for Intel, so I don't see how it's worse for AMD.

[Quackdoc]

You got me interested. Can you provide some more context/information regarding AMD's D3D12 UMD? They modeled a state tracker similar to i.e. gallium's frontends for this? What makes it so bad?

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.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/8254

the video is dead so here is a reup

https://files.catbox.moe/25kvig.mp4

Why? Relying on anv is not detrimental for Intel, so I don't see how it's worse for AMD.

I do not believe that intel uses ANV on windows. Happy to be proven wrong though if so.

[shmerl]

I do not believe that intel uses ANV on windows. Happy to be proven wrong though if so.

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.

[cb88]

For app devs who live in the real world, we have to worry about windows users. OGL on windows via amd is horrendous. and the D3D12 state tracker is abysmal. So this has the potential of being highly important.



since when have userland drivers not been drivers? In fact, it's in the name, "Userland driver"



I doubt they will, well perhaps it's possible they could run their own for of radv, but I could foresee an over reliance on radv being detrimental to AMD

Are we going to start calling GCC and LLVM ... CPU drivers because if we are not then no, the vulkan state trackers and userspace are not really drivers. They are just libraries and compliers that implement APIs for accelerators, the drivers are mostly in the kernel that control the state of the cards hardware (the user space is about what is executing on the card not controlling the card so much itself).

[Quackdoc]

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.

I agree that it would be technically ideal, but there are for sure times when AMD gpu features lag behind windows for a variety of reasons. raytracing is a good example of this, now RT is also a good example of it potentially being far better technically, but if there are any legal reasons, or just dealing with maybe mesa doesn't want it a certain way, then that would be very detrimental.

Are we going to start calling GCC and LLVM ... CPU drivers because if we are not then no, the vulkan state trackers and userspace are not really drivers. They are just libraries and compliers that implement APIs for accelerators, the drivers are mostly in the kernel that control the state of the cards hardware (the user space is about what is executing on the card not controlling the card so much itself).

Userland drivers have always been called userland drivers. In both linux and windows. well windows calls them user mode drivers, a small difference but meaning the same thing

[rmfx]

To me the most important imho would be everyone focusing on Zink (windows version as well as linux) so that opengl has only one ultimate shared implementation that works amazingly well for everyone, the same way for multiple vendors/multiple os, ditching the need for closed source drivers and letting us move on and start using Vulkan as a target.

[Quackdoc]

To me the most important imho would be everyone focusing on Zink (windows version as well as linux) so that opengl has only one ultimate shared implementation that works amazingly well for everyone, the same way for multiple vendors/multiple os, ditching the need for closed source drivers and letting us move on and start using Vulkan as a target.

yes, Im hopping zink + radv on windows is actually usable