AMDVLK vs. RADV vs. AMDGPU-PRO 17.50 Vulkan Performance

[difron]

Thank you, bridgman! You answered all my questions.
I still have technical issue on radeon HD 7770 on ArchLinux. vulkaninfo shows VK_ERROR_OUT_OF_HOST_MEMORY. Similar problem used to be with closed source opencl, but was solved via setting GPU_FORCE_64BIT_PTR=1. Is there some analog for vulkan?

[wizard69]

what we need is a database that catalogs software that properly uses Vulkan on Linux. I have no idea at the moment if a package is a terrible port or has other issues killing performance. I assume due the shitting nature of gaming and 3D on linux that we are dealing with bad ports.

Good job AMD guys! I really appreciate your opensource work! I'm sure performance will increase in time as it does with radeonsi. And I would really like to see some better Linux ports, as the proper Vulkan implementation needs to be started on a engine design level, not on DX11 to Vulkan layer... So we need some more games with new engines to see the actual Vulkan power.

[duby229]

Yes, Yes, Yes.
RADV for one, AMDVLK to the other, and a AMDGPU-PRO for the third. Linux style!

Does anyone here actually think that's a good idea? I sure as hell don't. I really do need a zero configuration out of box experience. And I know for an absolute fact that's true for almost everybody that uses computers.

[duby229]

DirectX is more then just a graphics API, allot more. So you would still need wine regardless and I don't think AMD is one bit interested in doing such a thing to help wine devs map rendering calls directly via the driver. Also microsoft might get all upset and stuff if you started doing such a thing...

MS doesn't have a say so in the matter. They lost the DX lawsuite which allows third parties to reimplement DX in any way they want. MS has nocontrol over the matter at all anymore. DX became a defacto standard whether we like it or not and that is a benefit to us because it made it possible for MS to lose a lawsuit that allows reimplimentations of it.

[Djhg2000]

DirectX is more then just a graphics API, allot more. So you would still need wine regardless and I don't think AMD is one bit interested in doing such a thing to help wine devs map rendering calls directly via the driver. Also microsoft might get all upset and stuff if you started doing such a thing...

Well yes it is more than a graphics API, but the rest is relatively easy deal with because we already have the most important parts of those components (like sound and input) from WINE. Microsoft would go nuts and all such things, but the question is whether it's possible, not realistically feasible.

[Shnatsel]

Strictly speaking the LLVM compiler backend is shared with HCC rather than ROCm

What's HCC? Is radeonsi included in there?

I could follow all of the abbreviations in this thread right up to this point; this is the first time I hear about "HCC".

[puleglot]

What's HCC?

https://gpuopen.com/compute-product/hcc-heterogeneous-compute-compiler/

[geearf]

What's HCC? Is radeonsi included in there?

I could follow all of the abbreviations in this thread right up to this point; this is the first time I hear about "HCC".

a b c d e f g *H*

gcc -> hcc

[enrico.tagliavini]

Honestly I think AMD is making it more complex than it should be. I can see they want a "special" driver for Enterprise customers, but this is just making it more complex for normal everyday users. This driver situation will just confuse the heck out of them.

Speaking for myself I care only about RADV. Drivers must work out of the box and RADV is included in mesa, making it the easiest solution without issues supporting new Xorg / kernel version. Go RADV!!!

[geearf]

Honestly I think AMD is making it more complex than it should be. I can see they want a "special" driver for Enterprise customers, but this is just making it more complex for normal everyday users. This driver situation will just confuse the heck out of them.

Speaking for myself I care only about RADV. Drivers must work out of the box and RADV is included in mesa, making it the easiest solution without issues supporting new Xorg / kernel version. Go RADV!!!

Once the LLVM patches for this driver land upstream, it'll be very easy to include it in distributions as well, RADV won't have an advantage there. Being part of Mesa does not make it much easier...