Mesa 21.0-devel RADV vs. AMDVLK 2021.Q1.1 Vulkan Driver Performance

[ms178]

The only things that come to mind short of a recent Mesa Git regression would be in terms of recent changes to that system would be something quirky happening with Resizable BAR issue (it was enabled from BIOS throughout) or Linux 5.11.

Could you re-test with the newest Beta BIOS - ROG CROSSHAIR VIII HERO BIOS 3102?!

From the changelog:
Update AMD AM4 AGESA V2 PI 1.1.9.0.
Improve ReSize Bar function

In the past, I've seen severe performance issues with Above 4G Decoding on AM4, but other users reported that the most recent BIOS release fixed it. See also for reference: https://gitlab.freedesktop.org/drm/amd/-/issues/1039

[MadCatX]

Michael
It looks like you used kernel 5.11 with a Zen 3 chip to run the benchmark. IIRC the schedutil governor is rather broken on this config and causes performance regressions. Any chance you can re-run at least some of these tests with the performance governor and see if these large differences between RADV and AMDVLK go away?

[Michael]

Michael
It looks like you used kernel 5.11 with a Zen 3 chip to run the benchmark. IIRC the schedutil governor is rather broken on this config and causes performance regressions. Any chance you can re-run at least some of these tests with the performance governor and see if these large differences between RADV and AMDVLK go away?

As noted on the system table from the first page, the 'performance' governor was used (as is normally the case when running gaming tests).

[MadCatX]

As noted on the system table from the first page, the 'performance' governor was used (as is normally the case when running gaming tests).

Ouch, I guess I should always read the entire table I found it weird that AMDVLK's frame latencies seem to be all over the place even when it averages higher FPS that RADV and thought that frequency scaling could be behind this.

[theriddick]

amdvlk good for F1 and that kingdoms game.
I tried amdvlk on WarThunder which now uses vulkan and it almost causes the kernel to crash and breaks Xorg (no way to log back in until reboot).

[DTolm]

Hello, I am the creator of VkResample and VkFFT. The discrepancy in VkResample results can be explained by the fact that RADV and AMDVLK report different values of maxComputeSharedMemorySize. For RADV, it is possible to use 32KB of shared memory per thread block and for AMDVLK it is possible to allocate 64KB. VkFFT can greatly benefit from the additional shared memory. The test performs 4k upscaling and the sequences used there take exactly 64KB of memory. So, on AMDVLK VkFFT can do the FFT in one upload, while RADV will require two. The one upload version can also benefit from R2C/C2R optimizations, which improve the speed and memory usage by a factor of 2. Adding all this together, we get a big performance difference. Feel free to ask any questions about VkFFT and VkResample!

[aceman]

I tried amdvlk on WarThunder which now uses vulkan and it almost causes the kernel to crash and breaks Xorg (no way to log back in until reboot).

Meanwhile it works great with Mesa integrated RADV (ACO).

[xxmitsu]

Something is odd in this benchmark. Must be a severe regression or something. I see that the mesa git revision used for this benchmark is 6 days old.

There were some complains in the mesa bug tracker with regards to performance degradation which seemed fixed with this MR: https://gitlab.freedesktop.org/mesa/..._requests/8393

Perhaps is related..


I expect to see a different situation when Michael will retest it when mesa 21 is released.

Michael , if you need a newer mesa, and don't want to build it yourself, there's a fedora copr which builds it from git, multiple times a day.

[MrCooper]

There were some complains in the mesa bug tracker with regards to performance degradation which seemed fixed with this MR: https://gitlab.freedesktop.org/mesa/..._requests/8393

Perhaps is related..

Yep, the tested upstream Git commit didn't have my fixes, so (unless the tests were run in a Wayland session) the Mesa numbers are completely worthless.

Michael if you can't wait for an actual release candidate, can you at least get in touch with developers before going public with such unexpected numbers?

[ernstp]

There seems to be a number of issues with the latest AMDVLK also: https://github.com/GPUOpen-Drivers/AMDVLK/issues/195

I had both installed before and used RADV primary, but after the latest AMDVLK update I started having issues which I simply solved by uninstalling AMDVLK because I didn't have time to dig fruther...