David Airlie Tackling RADV Vulkan Conformance

[shmerl]

It is probably relevant to ask bridgman directly: Are there any updates on AMDs plans to open source the AMDGPU Pro Vulkan driver?

bridgman was reluctant to discuss details and give any ETAs. I'm not sure what problem there is with publicity. I just hope they didn't cancel their initial plans.

[schmidtbag]

I'm really wondering if it's good that RADV exists? As to be honest - the AMDGPU-PRO Vulkan driver is much more complete, performs better, but needs improvement/feedback from RedHat and Valve, but they are focusing on RADV as AMDGPU-PRO Vulkan part is not opensourced and... with RADV there is no pressure on AMD to opensource it. They might probably not opensource it at all and say - here you have RADV. Ok, but lets assume they opensource it and now what? All the work on RADV would go to trash?

Shhh..... you're about to get a lot of flak for saying that (I would know, because I've said similar things). Though I think RADV is a good project and so far very well-made, I've always felt it had bad priorities, when you consider the following:
Intel: Mostly (if not completely) Vulkan compliant
Nvidia closed-source: Vulkan compliant
Nouveau: Nothing
AMD GCN 1.2+: Vulkan compliant; temporarily closed source
AMD GCN 1.0-1.1: Nothing
Software renderers: Probably nothing (not entirely sure)

To me, it just doesn't make sense why RADV is targeting something that already had Vulkan support and was possibly going to be open-sourced anyway. At some point, somebody's work is going to be obsoleted, and that was known the day this was started. Sure, RADV could possibly end up being better than the amdgpu-pro drivers, but that's a bit of a gamble considering other GPUs in need. There are compatible and common GPUs in need of [official] support and currently have none. To me, it's kind of like donating money to someone who already has a job, instead of someone who is homeless.

[shmerl]

I think the reason is timing. AMD can work on opening up their Vulkan for years, and meanwhile AMD users who want to use open drivers will be left out in the cold.

[schmidtbag]

I think the reason is timing. AMD can work on opening up their Vulkan for years, and meanwhile AMD users who want to use open drivers will be left out in the cold.

There's being left out in the cold, and then there's being left naked out in the cold. GCN 1.0-1.1 users have nothing, unless you count unstable experimental stuff that requires custom-built kernels. I would much rather use closed drivers that actually work than have no support at all. 99.99% of all Linux users will not take advantage of open-source video drivers in a useful way. Back in the Catalyst days, a demand open-source made sense because Catalyst's update cycle was a huge burden to everything the kernel and Xorg depended on or was dependent-upon. It didn't take much to break everything. But amdgpu-pro doesn't leave people stranded like this.

[shmerl]

If you are so pressed to use Vulkan, at least you have a choice to buy newer hardware. But if you have no open driver to begin with, you have no choice.

[VikingGe]

AMD GCN 1.0-1.1: Nothing

If you're comfortable with running the (still experimental?) amdgpu kernel module on those, you can use RADV. On Arch it is supported by default, just requires you to add the amdgpu module to your mkinitcpio.conf, not much of a hassle. Not sure about other distros.

To me, it just doesn't make sense why RADV is targeting something that already had Vulkan support and was possibly going to be open-sourced anyway. At some point, somebody's work is going to be obsoleted, and that was known the day this was started.

True, but with RADV we have a working Vulkan driver that can be used together with Mesa's OpenGL implementation. I'm not aware of any way use run the Vulkan part of the Pro driver alongside Mesa's libGL (unlike the OpenCL part, which does work). For OpenGL gaming and desktop use, I really wouldn't want to run the Pro driver.

I'm glad it is there, it allows me to experiment with the API (currently writing a library that uses Vulkan compute shaders for GPU computing) without having to use a broken OpenGL driver or, gods forbid, Windows.

In all honesty, the best thing that could happen would be for AMD to throw some manpower at RADV in order to make it fast, add missing features and lift some unnecessary limitations. That probably should have happened as soon as RADV became a serious thing in Mesa 13.

[schmidtbag]

If you are so pressed to use Vulkan, at least you have a choice to buy newer hardware. But if you have no open driver to begin with, you have no choice.

I'm not pressed. Aside from SteamVR (which is barely usable) and eventually Star Citizen (which I haven't played), I don't own anything Vulkan-compatible. What I like about Linux is the community - I like to see things get done even for hardware I don't/won't have or will ever encounter. I like to see people contribute to things to make Linux a complete platform. I like it when Linux users can cross something off the "incompatible list". It's a good feeling. Redundant drivers does not help raise with completion.

Anyway, people shouldn't have to buy new hardware to utilize something their current hardware is supposed to be compatible with. Unlike most un-supported products where the manufacturer says "too bad, we don't owe you anything", RADV has devs who (to my knowledge) aren't restricted by a manufacturer's agenda.

[schmidtbag]

If you're comfortable with running the (still experimental?) amdgpu kernel module on those, you can use RADV.

I'd rather not use experimental. SI/CIK has been experimental for a while for a reason. I use Arch and though there is a pre-built kernel, I had a lot of issues using it.

True, but with RADV we have a working Vulkan driver that can be used together with Mesa's OpenGL implementation. I'm not aware of any way use run the Vulkan part of the Pro driver alongside Mesa's libGL (unlike the OpenCL part, which does work). For OpenGL gaming and desktop use, I really wouldn't want to run the Pro driver.

I thought people were still able to use OpenGL with the Pro driver? Personally, I don't care what OpenGL implementation I'm using as long as it works and I'm not losing performance.

I'm glad it is there...

In all honesty, the best thing that could happen would be for AMD to throw some manpower at RADV in order to make it fast, add missing features and lift some unnecessary limitations. That probably should have happened as soon as RADV became a serious thing in Mesa 13.

Don't get me wrong - I don't have a problem with RADV as a whole. My gripe is the priorities. Assuming RADV is solely dependent on amdgpu (non-pro), the most manpower AMD should've thrown was to get that driver compatible with GCN 1.0-1.1. Their drivers so far seem decent, so if their intention is to open-source them, I don't see why they'd care about supporting RADV.

EDIT:
In a parallel universe where RADV supported GCN 1.0-1.1 (whether that be in addition to or instead of 1.2+), AMD would realize how quickly it progresses and how many big companies have contributed toward it, and would have pushed them to open-source their own drivers. "Free" skilled and hard-working developers are every tech company's dream. But, in our universe, AMD may look at this Vulkan situation and probably thinks "meh, I'll just kill off our drivers once RADV catches up".

[shmerl]

I don't call that redundant. Closed driver is simply a bad option.

[Mystro256]

bridgman was reluctant to discuss details and give any ETAs. I'm not sure what problem there is with publicity. I just hope they didn't cancel their initial plans.

AFAIK, nothing has changed, i.e. the plan is to open source it, but there's no ETA. I'm no authority on the matter, but bridgman has been saying this over and over for quite a while, so my assumption is that there's likely nothing to update. The lack of update is unfortunate but there are a lot of new products coming out this year, so I'm sure his focus is on other items right now.