AMD's Vulkan Driver Will Only Work With The AMDGPU Kernel Driver

[Sonadow]

The advantage of going open source is not to have little fairies do all the work.
In fact if you read some analysis of people working in the field, you'll find that companies are pretty well aware of that.

Most of the contributions has to come from the company. Then the little fairies will do some minor but interesting contributions, enhance compatibility, do fixes, find regressions, etc.
That's exactly what happens with Mesa to me. People do report regressions, do implement some extensions, do some fixes, and some other things (gallium nine, etc).

Yeah, well, community ≠ unpaid volunteers.

Right, this just proves once and for all that all that "release the source and the documentation and the community will do everything" demands made in the past is a flaming pile of bullshit

[bridgman]

Wait, AMD does think about supporting older GCN GPUs with amdgpu? The last time the question came up the reply was more like "why would you want that?"...

Pretty simple really. For new things like Vulkan, we started development on the code base we know we'll be using going forward (amdgpu kernel driver and libdrm-amdgpu). The standard was evolving, as was our code, so it didn't make sense to lock in the kernel driver design for older hardware too early until everything settled down (which it has recently).

If we were not in the middle of a kernel driver transition this would be a non-issue, but since both IOCTLs and internal structure of the kernel drivers changed between radeon and amdgpu the decision depends a lot on what functionality the userspace drivers ended up needing.

There are three obvious options for pre-VI Vulkan support:

1. run Vulkan over the radeon userspace library (libdrm-radeon/radeon winsys),

2. run Vulkan over the amdgpu userspace library but extend it to support radeon IOCTLs as well as amdgpu IOCTLs, or

3. extend amdgpu support back to earlier GCN parts and either find a way to replace radeon as the upstream default or eat the ongoing cost of working on two kernel drivers

There is also the option using option #2 for SI and option #3 for CI, of course.

With options #1 or #2 everything would run over the radeon kernel driver, so there really would have been little or no user benefit to running SI/CI hardware on amdgpu. With option #3 there would be a benefit to running SI/CI on amdgpu and so we would adjust our plans accordingly.

Everyone is probably thinking "hey SI and CI are pretty much the same are you guys stupid or what ?" but outside of the shader core SI actually has more in common with NI than with CI. Since shader core interaction is primarily handled by the userspace drivers, you can see what this means from a kernel driver perspective.

People sometimes forget that GCN is short for Graphics Core Next, not Graphics Chip Next

[bridgman]

.... aaaaand I've been moderated again. Bleah.

Maybe this is why people are tweeting instead of using forums.

EDIT - post above has now appeared.

[Veerappan]

Right, this just proves once and for all that all that "release the source and the documentation and the community will do everything" demands made in the past is a flaming pile of bullshit

"Everything" is a strong word, but the community does contribute. The fact that all of the gallium state trackers are shared among drivers for multiple cards/systems and that all mesa drivers share a GLSL compiler is a great thing, it reduces the amount of effort required to bring up new drivers, and eases *some* of the maintenance burden for everyone. It doesn't mean that you get a free driver, but you are allowing interested 3rd parties to get involved. The community doesn't just mean random volunteers; it means volunteers, hardware vendors, os vendors, other software vendors, and anyone else with a vested interest.

By going with an open-source driver, you're also allowing people who think they've run into a bug in your driver a way to find out why things aren't working. Have you seen the turnaround time on how quickly fixes to mesa can get committed to the upstream repository for some new games? Not always, mind you, but there's times that the fix is committed upstream within hours of the user bug report coming in... and that allows the user to quickly test and confirm that their issue is actually fixed. I'd gladly take a fix in a day or so, instead of having to wait a month or two for a new driver to come out.

[devius]

People sometimes forget that GCN is short for Graphics Core Next, not Graphics Chip Next

Meh, I always read it as GameCube Nintendo anyway...

Oops.... wrong forum

[MaxToTheMax]

<SNIP>
People sometimes forget that GCN is short for Graphics Core Next, not Graphics Chip Next

Very informative, thanks.

[artivision]

I think the community must think Vulkan also for Radeon HD 5000-6000 series. With an extra D3D12 to Vulkan compatibility layer with low overhead, we can take a very important portion of the gamers from MS (D3D12 on HD5-6 series). This is a golden and rare change to upgrade Linux usage on PC and gain more native support after.

[Kano]

DX12 uses HLSL not SPIR-V - HLSL is the same as before. But maybe it is faster to do HLSL -> SPIR-V than HLSL -> GLSL. At least writing an optimizier for SPIR-V would be more generic after that step.

[artivision]

DX12 uses HLSL not SPIR-V - HLSL is the same as before. But maybe it is faster to do HLSL -> SPIR-V than HLSL -> GLSL. At least writing an optimizier for SPIR-V would be more generic after that step.

D3D12 uses HLSL and Vuckan GLSL and every API will be ever created will use an SL for Devs to write graphics and never an Assembly. The only difference is that with low level APIs, graphics will be distributed pre-compiled in Assembly(SpirV or D3D12_asm) with many optimizations already done. So it will be asm_to_SpirV (assembly to equal level assembly with just typos conversion), or directly asm_to_hw, or to virtual machine assembly (LLVM-IR) and then HW.

[Kano]

No, there is a GLSL -> SPIR-V sample implementation but Vulkan can only use SPIR-V.