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

[profoundWHALE]

Holeee crap those are some good numbers. Check out the difference between 1080p and 4K on Vega 64!

[nuetzel]

That's incredible considering that RADV was originally started as a joke as Dave said if I remember correctly.

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?

[shmerl]

It's not really a true Vulkan title, so these benchmarks are only marginally interesting, since here hardware isn't really used to full potential. Are there true Vulkan titles for Linux?

[Masush5]

It's not really a true Vulkan title, so these benchmarks are only marginally interesting, since here hardware isn't really used to full potential. Are there true Vulkan titles for Linux?

If by "true vulkan title" you mean "developed with vulkan in mind from the get go", then no. But even then, a "true vulkan title" doesn't guarantee that the hardware is being used to its full potential. There can still be inefficiencies lurking everywhere, from the game's code to the driver's shader compiler.

[marek]

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?

Multiple LLVM versions can co-exist. If Mesa uses libLLVM-6.0svn.so, it obviously can't use libLLVM-4.0.so. Steam runtime shouldn't have its own LLVM, but if it does, I bet it's not called libLLVM-6.0svn.so, so it doesn't matter.

[humbug]

It's definitely nowhere near on par with its Windows counterpart.

Yes, for some reason, AMD Vulkan driver on Linux is slower than on Windows.

Yea, but how much of that is the driver and how much of that are the games

It's the driver we are talking about in this case. Both AMD's official linux vulkan driver as well as RadV are definitely slower than the windows driver, leaving aside the quality of the ports. You can tell by comparing the vulkan performance vs the competing Nvidia product. On windows AMD always wins at Vulkan.
i.e.
R9 290 beats GTX 970
Rx 580 beats GTX 1060
Vega56 beats GTX 1070
etc...

See the below quote from bridgman addressing the issue

https://www.phoronix.com/forums/forum/hardware/graphics-cards/969671-radeon-rx-vega-on-linux-high-performance-gpus-open-source-no-longer-an-oxymoron/page4

Most of the performance tuning for Vulkan was done on Windows since we did not yet have large page support in Linux. It took us a while to get that working and we didn't have time to get 2M page support into the AMDGPU-PRO stack before launch.

Once we have it integrated I expect we should see a noticeable performance improvement just from that... and having it will allow the Vulkan team to do more Linux-specific tuning as well.

[pal666]

in ~1 year

closer to 2

[pal666]

I would like to see a community effort on running the open source driver on windows.
Best case, AMD drops support for the other drivers :P

best case for whom amd drops directx drivers?

[shmerl]

If by "true vulkan title" you mean "developed with vulkan in mind from the get go", then no. But even then, a "true vulkan title" doesn't guarantee that the hardware is being used to its full potential. There can still be inefficiencies lurking everywhere, from the game's code to the driver's shader compiler.

Yes, I mean one developed using Vulkan directly, rather than using Vulkan as a wrapper around DirectX. Sure, there can be design flaws, but wrapper itself means it's limited by DirectX design.

[christian_frank]

Yes, I mean one developed using Vulkan directly, rather than using Vulkan as a wrapper around DirectX. Sure, there can be design flaws, but wrapper itself means it's limited by DirectX design.

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.

Serious Sam Fusion also has an Vulkan renderer (sadly wiht issues since th latest patch). It was implemented later on, but you still could compare win/lin with that game too.

Afaik, ashes of the singularity has an vulkan renderer now and will come to linux, then you have a nice windows/linux comparision example, cause that game was designed with DX12 from the beginning, so it also should fully benefit from vulkan.