David Airlie Tackling RADV Vulkan Conformance

[duby229]

Please do not confuse "my stance" with the answers I give when you ask what our plans are.

Why would you expect a new kernel driver to help OpenGL performance ? We certainly didn't... we've been working on improving Mesa GL performance for that.

When you talk about distro integration are you talking about enterprise distros / WS users, or are you still thinking about -pro as "consumer driver for life" ?

If the latter, remember that once we have Vulkan open sourced (or use similar functionality in Mesa GL etc..) we can upstream the required kernel functionality and run the drivers over an upstream kernel. We're just stuck out-of-tree while we have kernel functionality that is only used by closed source userspace bits. Workstation OpenGL is the only part that might end up requiring out-of-tree kernel support but you don't care about that, do you ?

Look, I'm sorry, I just can't keep this up. We've all seen what happens when AMD tries to open source proprietary code. DC anyone? The fact is radv is here now and people are using it now. Not your open source Vulkan driver because you don't have one yet. When you do however much time from now, I won't be one tiny bit surprised if radv immediately supersedes it. (If that happens it means -your- driver was the redundant one and you wasted all that effort, which should have been spent on radv.) You guys -need- to be preparing yourselves and your customers for that. Not misleading them into thinking a shared driver is going to be commonly available. It's gonna hurt linux if you do.

[smitty3268]

Nope, not helping. A developer not interested in Linux is likely to go with DX12 since they already know that, so I don't understand how you can think Linux driver availability is not going to influence developers.

From what I can tell, developers have just been targeting the NVidia vulkan driver on linux, the same way they used to do with OpenGL. I'm not sure having the proprietary AMD vulkan drivers really made any kind of difference there, one way or another.

I do think having it for Windows was important, and so you can then get it almost for free in the linux pro drivers, so from that standpoint I think it makes a certain amount of sense. It's still basically useless in practical terms, but there's no reason not to provide it, and several reasons to do so.

Again, read what I said. Game developers asking about having the *same* driver on Linux & Windows.

That's just stupid. If their apps can't work across drivers, then Vulkan is useless and we might as well abandon it now and keep using GL.

Who do you think is going to "reject" the open source Vulkan driver ? Assume you are talking about the distros ?

Yes, it will definitely be the distros deciding which driver they pick as the default. I suspect Fedora will pick radv up by default in the fall, and then all the other distros will follow next spring. Since I'm suspecting the AMD driver won't be out until after then, it's going to have an uphill battle to try and replace radv unless it can prove to be better somehow.

[nanonyme]

Even if/when AMD opensources their Vulkan driver or parts of it, radv may still remain the primary driver. I read bridgman's earlier comments about timeline that getting legal review and opensourcing of specific parts of Vulkan driver to happen faster might yield a boost to radv which sounds a fair plan to me

[boffo]

Hm...I thought this is exactly what they did with the last amdgpu-pro when they made it possible to install only the compute part...in arch (which I am running, it has found it's way to AUR: https://aur.archlinux.org/packages/opencl-amd/)

Thank you. I didn't know.

[bridgman]

Even if/when AMD opensources their Vulkan driver or parts of it, radv may still remain the primary driver. I read bridgman's earlier comments about timeline that getting legal review and opensourcing of specific parts of Vulkan driver to happen faster might yield a boost to radv which sounds a fair plan to me

For clarity, that was something I mentioned as a possibility several months ago when radv first appeared (I was hoping there might be some framework code etc.. that was easy to open up quickly and would avoid Dave & Bas having to start from scratch completely), but after looking into it internally we ended up staying on the original plan.

[nanonyme]

For clarity, that was something I mentioned as a possibility several months ago when radv first appeared (I was hoping there might be some framework code etc.. that was easy to open up quickly and would avoid Dave & Bas having to start from scratch completely), but after looking into it internally we ended up staying on the original plan.

Also imo the opensourcing of Vulkan driver that wouldn't integrate with Mesa may end up a silly plan depending on what comes out of possible GL+Vulkan interop

[shmerl]

For clarity, that was something I mentioned as a possibility several months ago when radv first appeared (I was hoping there might be some framework code etc.. that was easy to open up quickly and would avoid Dave & Bas having to start from scratch completely), but after looking into it internally we ended up staying on the original plan.

Is the original plan (full opening if I understood correctly) progressing well at least? Or you had some unexpected delays? For outside observers it all takes quite a long time, so it's hard to judge how reasonable such time is.

[smitty3268]

Is the original plan (full opening if I understood correctly) progressing well at least? Or you had some unexpected delays? For outside observers it all takes quite a long time, so it's hard to judge how reasonable such time is.

I don't think it's clear it's progressing at all.

The last I heard, they were going to put the Vulkan effort on hold for an indefinite amount of time and focus 100% of resources on opening up the OpenCL driver instead. Of course, who knows how accurate that was, or if it hasn't changed several times already. They won't give you any insight into what's happening internally.

[bridgman]

Is the original plan (full opening if I understood correctly) progressing well at least? Or you had some unexpected delays? For outside observers it all takes quite a long time, so it's hard to judge how reasonable such time is.

On track in terms of what the development teams were able to commit, but obviously faster would be nicer.

The last I heard, they were going to put the Vulkan effort on hold for an indefinite amount of time and focus 100% of resources on opening up the OpenCL driver instead. Of course, who knows how accurate that was, or if it hasn't changed several times already.

I never heard this and don't remember hearing anyone say it. Can you point me to a reference ? Thanks...

The only difference AFAIK is that on the OpenCL side we were able to provide an initial developer preview (albeit in binary form) showing OpenCL running with the new compiler and new ROCm back end, late last year.

[shmerl]

On track in terms of what the development teams were able to commit, but obviously faster would be nicer.

Thanks. So, there are still parts that require replacement to release it, or now it's just legal review of the codebase?