RADV Ray-Tracing Now Rendering Quake II RTX Correctly But Very Slowly

[humbug]

AMD maintains AMDVLK because it's a shared codebase with their windows Vulkan driver.
Basically it's work they have to do regardless because of the massive customer base on windows; and as a side effect of that we get AMDVLK on Linux.

Unfortunately what happened was that when the Vulkan spec was released five years ago it took AMD more than 1.5 years to provide open source support on Linux. So in that time RadV was born out of necessity starting from Red Hat and then Valve and other contributors. Which means that AMDVLK on Linux was too late on Linux to get adoption.

[user1]

I think some cooperation between RADV developers and AMD would definitely help. Currently it looks like AMD consciously ignores RADV, completely ruling out any contributions to the driver. It's great that AMD developers assist developers in the sense that they answer questions asked by RADV developers, but that's just the bare minimum.

I'm not asking that AMD hires developers dedicated to improve RADV and making it an official AMD vetted driver. There's has to be a middle ground somewhere, though...

Completely agree. I think AMD should at least provide better documentation to RADV developers. For example, I think it's kinda unacceptable that RADV/ACO devs don't have early access to new hardware documentation unlike RadeonSi devs, so they need to rely on the early work being done in RadeonSi/LLVM for new hardware. I remember in the past RADV was somewhat slower than RadeonSi in gaining optimizations on new hardware, so that's probably the reason why.

[bridgman]

That's just it, even AMD/Bridgman recommends that the average person and gamers use RADV and Mesa provided solutions, to try AMDVLK if that doesn't work, and to leave AMDGPU-Pro for mostly enterprise solutions and LTS w/o HWE (gotta get a driver from somewhere if your hardware is too new for LTS).

Strictly speaking I made that recommendation in the context of an OpenGL discussion. I don't think I have made a corresponding statement about Vulkan.

[Linuxxx]

Strictly speaking I made that recommendation in the context of an OpenGL discussion. I don't think I have made a corresponding statement about Vulkan.

Could You please state why AMD is so scared by the existence of RADV that you don't want to even mention it? It's not like the driver was written by Lord Voldemort, you know!

I mean, does AMD really think that once Steam Deck is unleashed people are not going to find it out anyway?
Tackling this upfront seems to be the wiser approach to me...

[bridgman]

Could You please state why AMD is so scared by the existence of RADV that you don't want to even mention it? It's not like the driver was written by Lord Voldemort, you know!

I mean, does AMD really think that once Steam Deck is unleashed people are not going to find it out anyway?
Tackling this upfront seems to be the wiser approach to me...

We're not "scared by the existence of RADV" - not sure where you're getting that impression. I just didn't think that listing all the drivers made sense when I could just say "Vulcan", but I can do that if you prefer:

Strictly speaking I made that recommendation in the context of an OpenGL discussion. I don't think I have made a corresponding statement about Vulkan RADV, AMDVLK and the AMDGPU-PRO driver.

Is that better ?

Not sure what you mean by "people will find out" - distros have been packaging RADV for pretty much as long as it has existed, and I think everyone already knows that the primary developers are not from AMD.

By the same token I think it is also understand that RADV development leverages vendor-supplied code from AMD (radeonsi, AMDVLK) and Intel (anv), and that AMD developers are helping out where they can, both by answering questions and occasionally contributing.

This was the case with the 300g and 600g Gallium3D drivers as well - both of those were started by non-AMD developers. This is no secret, and IMO is one of the great things about supporting open source development.

If you look in the RADV commit history you will find a number of commits from Marek, although some of those were focused on making sure that changes to radeonsi code leveraged by RADV did not break RADV.

Our Vulkan team needs to support other OSes, so dropping the Linux-packaged versions does not save enough effort for them to take on supporting RADV as well. Our Vulkan driver makes heavy use of the PAL framework which is shared across APIs as well as across OSes, so even if we were to do something like replacing the Windows Vulkan driver with RADV the bulk of the PAL work would still have to be done, so again the "just move your developers from AMD Vulkan to RADV" argument doesn't really hold up.

If you want to complain that we should be hiring even more engineers and having them work on RADV that would be fair, although we already have a big queue of positions we are trying to fill for even more urgent projects.

[skeevy420]

Strictly speaking I made that recommendation in the context of an OpenGL discussion. I don't think I have made a corresponding statement about Vulkan.

Yeah, I think that was the case and that I'm extrapolating more from that recommendation than was intended.

If you want to complain that we should be hiring even more engineers and having them work on RADV that would be fair, although we already have a big queue of positions we are trying to fill for even more urgent projects.

Is a person to update the documentation to append asterisks to features that Linux doesn't support one of those positions? I think my 580 supports something like 1/2 of the features listed on the product spec page. I didn't forget about that

[loganj]

Linuxxx i think that will be the least of their problems ("shock"). the biggest shock will probably "this weird windows version"

[AHOY]

The open AMD drivers have a control panel for changing settings like ray tracing outside a game? I'm not a gamerphile but I hope it isn't anything like the Windows version I read about, looks so heavy and cumbersome to navigate.

[pal666]

the end user gets one driver maintained and developed by NVidia that just works.

novideo gets nvidiots spreading fairy tales

[pal666]

I'm not asking that AMD hires developers dedicated to improve RADV and making it an official AMD vetted driver. There's has to be a middle ground somewhere, though...

radv and radeonsi share code in mesa, seems like middle ground to me