Open-Source Win: RADV Trades Blows With AMDGPU-PRO Vulkan In F1 2017

[aejsmith]

Hello Marek,

I _can't_ get it going on my openSUSE Tumbleweed _devel_ system.

The standard LLVM version is 4.0.1.
As you know, I'm running all Mesa git stuff with LLVM 6.0 git.
All dri (radeonsi_dri.so/radeonsi_drv_video.so/libvdpau_radeonsi.so.1.0.0) OpenGL stuff works like a charm with LLVM 6.0 git living in '/usr/local/lib64'. Even 'DiRT Rally' run with it.

But with 'F1 2017' I always get '/usr/local/lib64/libvulkan.so.1: undefined symbol: vkGetInstanceProcAddr'

Alex Smith of F. gave advice that I should remove _all_ system versions (LLVM 4.0.1) and self compiled (LLVM 6.0 git) and then the ones of Steam runtime should get used. But I can't find any 'Steam runtime' versions on my system.
Even AMDPRO ones don't work (LLVM clash - 4.0.1 / drmGetDevice2 undefined)...

How do you switch between 'devel' (LLVM 6.0) and 'release' (mostly LLVM 4.0.1) games requirements?
Or am I missing something?

Sorry if I was unclear - my suggestion was to just remove your system copy of libvulkan.so.1 (*not* the whole of LLVM, the two are unrelated), since it looks like you have your own copy under /usr/local which appears to be broken. Steam provides its own copy of libvulkan which works, so if you remove yours Steam's copy should be used instead.

[airlied]

The only title which i know right now which was created with vulkan in mind from the start is Doom2016. You can run it easily on linux using wine-staging and as the vulkan part is pushed through wine directly without any translation, the performance on my nvidia card was fully comparable to the windows performance. If you own that game, you could compare the Windows and Linux (with wine) performance on amd.

I think Wolfenstein II is in the category as well, though no success on wine as if yet,

Doom has a bunch of AMD specific optimisation that we haven't gotten in llvm/radv, but we are trying to get on top of them.

Dave

[M@yeulC]

best case for whom amd drops directx drivers?

For everyone involved, of course. That's a hypothetical win/win/win situation.
Highly hypothetical, of course. But we also have a working DX9 state tracker over gallium, and I think there were prototype ones for DX10/11. As for 12, that's an other story, but I believe the hardest part is the compiler, anyway, and that's already working pretty well.
OK, to be more explicit: overall, I think it would benefit mesa development (more test cases, and help identify bottlenecks), windows gamers (more performance = win, better support for older GPUs, community-fixable drivers), and AMD (well, because having only one good driver to maintain is obviously beneficial).
That's never going to happen, of course (especially the last part).

[juno]

Hope the next amdgpu pro release brings a Vulkan performance uplift.

Why would you hope that? AMD can now officially keep their implementation for themselves. They managed to sit the release out until it's already irrelevant.

[shmerl]

I think Wolfenstein II is in the category as well, though no success on wine as if yet,

Doom has a bunch of AMD specific optimisation that we haven't gotten in llvm/radv, but we are trying to get on top of them.

Dave

Thanks for clarifying. What about progress in Unreal and Unity? Don't they already provide an option to use Vulkan? So I suspect the potential number of Vulkan games should be higher.

[pal666]

For everyone involved, of course. That's a hypothetical win/win/win situation.
Highly hypothetical, of course. But we also have a working DX9 state tracker over gallium, and I think there were prototype ones for DX10/11. As for 12, that's an other story, but I believe the hardest part is the compiler, anyway, and that's already working pretty well.
OK, to be more explicit: overall, I think it would benefit mesa development (more test cases, and help identify bottlenecks), windows gamers (more performance = win, better support for older GPUs, community-fixable drivers), and AMD (well, because having only one good driver to maintain is obviously beneficial).
That's never going to happen, of course (especially the last part).

in some imaginary world with unlimited resources maybe. in real world i don't see any win in spending resources on writing dx drivers from scratch, so it is surely not win for everyone

[bridgman]

See the below quote from bridgman addressing the issue
https://www.phoronix.com/forums/foru...oxymoron/page4

I believe 17.40 includes large page support but not sure if it is enabled by default. I believe there were some instructions for mining (where 2MB pages really make a difference) calling for a fragment size boot parameter (setting to 9 instead of default 4 IIRC).

[boxie]

Why would you hope that? AMD can now officially keep their implementation for themselves. They managed to sit the release out until it's already irrelevant.

or, you know, there can be 2 drivers for AMD that are both maintained and performance stuff from both can be cross pollinated. In this case if there is a game that does not work on one it might work on the other

[humbug]

or, you know, there can be 2 drivers for AMD that are both maintained and performance stuff from both can be cross pollinated. In this case if there is a game that does not work on one it might work on the other

Hopefully the competition will help spur both drivers forward once AMD open sources there's and it achieves broader compatibility.

the downside though is that we have talented developers at AMD working on their driver, and then you have talented devs like David and Bas and the guys at Valve working on RadV. In an ideal world we would want all these guys collaborating on making one driver... But I guess this is a common problem in the world of Linux.

[boxie]

bridgman why not just ship RADV inside of the AMDGPU-pro driver like the pro driver ship ROCm ?

why not just drop the closed source Vulkan driver? why not just bring RADV to windows to?

because they have a very large team of programmers for the windows driver