Radeon "sisched" Scheduler Is Made Obsolete By RADV's ACO Back-End

[geearf]

What issues are you talking about? Not saying ACO is free of bugs but we fixed a bunch of issues recently. I would be glad to fix more.

For instance, unless it is part of those recent fixes and has not yet hit mainline, there is no support for VK_KHR_16bit storage and VK_KHR_8bit_storage, for those llvm is still needed.

[hakzsam]

For instance, unless it is part of those recent fixes and has not yet hit mainline, there is no support for VK_KHR_16bit storage and VK_KHR_8bit_storage, for those llvm is still needed.

You are right, 8-bit/16-bit support for ACO is still WIP, but should be upstream in the next few weeks.

[geearf]

You are right, 8-bit/16-bit support for ACO is still WIP, but should be upstream in the next few weeks.

Awesome news!
Since we're talking about it, how come ACO does not fall back to LLVM in that case? Wasn't it supposed to do so for missing shader support?

Thanks!

[Venemo]

Awesome news!
Since we're talking about it, how come ACO does not fall back to LLVM in that case? Wasn't it supposed to do so for missing shader support?

When ACO is enabled, different capabilities are advertised by the driver.

[Venemo]

Is there a reason why they don't merge all the open source drivers available for AMD?

Because they serve a different purpose and/or are built on different underlying technologies.
Actually, radeonsi and radv have a lot in common: they both use NIR, and rely on the same common stuff (src/amd/common and src/amd/llvm in the mesa source tree). They expose different APIs though, which have different requirements and different abstractions, so they can't be completely "merged".

The other drivers are maintained in a separate repo, so it's hard to share code with them directly.

[Buntolo]

Because they serve a different purpose and/or are built on different underlying technologies.
Actually, radeonsi and radv have a lot in common: they both use NIR, and rely on the same common stuff (src/amd/common and src/amd/llvm in the mesa source tree). They expose different APIs though, which have different requirements and different abstractions, so they can't be completely "merged".

The other drivers are maintained in a separate repo, so it's hard to share code with them directly.

Tomorrow I'll receive my RX 5700 and still I haven't figured out which driver I should use. It's a mess between openGl and Vulkan and so many drivers (AMDGPU/mesa/RADV/RadeonSI/AMDVLK/etc).

[agd5f]

Tomorrow I'll receive my RX 5700 and still I haven't figured out which driver I should use. It's a mess between openGl and Vulkan and so many drivers (AMDGPU/mesa/RADV/RadeonSI/AMDVLK/etc).

It's not that complicated. There are only 3 open source drivers for OpenGL and Vulkan:
OpenGL - radeonsi
Vulkan - RADV, AMDVLK

[skeevy420]

It's not that complicated. There are only 3 open source drivers for OpenGL and Vulkan:
OpenGL - radeonsi
Vulkan - RADV, AMDVLK

I get where Buntolo is coming from. There are so many different terms thrown around that it can be confusing if you haven't got 'em all figured out.

There's Mesa providing OpenGL with RadeonSI and Vulkan with RADV. We have another Vulkan from AMD with AMDVLK. And on the right distribution we have yet another set from AMD with AMDGPU-Pro. Plus there's radeon and amdgpu and references to those...which makes me wonder if renaming radeon to amdgpu-legacy wouldn't be a bad idea...

Then there's stuff like going to the wrong page on AMD's site and finding links to Catalyst with some R7 cards.