AMDVLK 2024.Q3.3 Brings New Performance Optimizations & Pipeline Binaries

[phoronix]

Phoronix: AMDVLK 2024.Q3.3 Brings New Performance Optimizations & Pipeline Binaries

AMD today released AMDVLK 2024.Q3.3 as their latest open-source Vulkan API driver for Linux systems prior to ending the quarter...

https://www.phoronix.com/news/AMDVLK-2024.Q3.3

[Chewi]

I haven't previously cared about AMDVLK, but now I do because I have found that using it seems to prevent my whole system from spontaneously rebooting while playing certain games. I was on the verge of sending my 6800 XT back as I was so sure it must be a hardware issue, having ruled out a few other things, and also because the system doesn't even see the GPU when it initially comes back up. It seems to hold up with AMDVLK though. I haven't seen a crash with AMDGPU-Pro either, but its gaming performance is pretty bad. I would have preferred a hardware issue as driver issues are a nightmare, especially one like this! Maybe I can bisect Mesa, but given that it can take over an hour to crash, that could send me down a lot of blind alleys. That's assuming this isn't simply because RADV can push the card harder than the other drivers can.

[mbriar]

I haven't previously cared about AMDVLK, but now I do because I have found that using it seems to prevent my whole system from spontaneously rebooting while playing certain games. I was on the verge of sending my 6800 XT back as I was so sure it must be a hardware issue, having ruled out a few other things, and also because the system doesn't even see the GPU when it initially comes back up. It seems to hold up with AMDVLK though. I haven't seen a crash with AMDGPU-Pro either, but its gaming performance is pretty bad. I would have preferred a hardware issue as driver issues are a nightmare, especially one like this! Maybe I can bisect Mesa, but given that it can take over an hour to crash, that could send me down a lot of blind alleys. That's assuming this isn't simply because RADV can push the card harder than the other drivers can.

Gpu hang due to driver bug, you should open a bug report on the mesa gitlab using the 'radeon vulkan' template.

[Chewi]

Gpu hang due to driver bug, you should open a bug report on the mesa gitlab using the 'radeon vulkan' template.

Is there any point when there's almost nothing to go on? I'm running Gentoo, so there are a lot of variables. I should try to reproduce with Fedora or something first.

I was also thinking I could try wined3d as another data point. Most recently, I've reproduced this with Batman: Arkham City, which is far from new, although I did add a texture pack.

[mbriar]

Is there any point when there's almost nothing to go on? I'm running Gentoo, so there are a lot of variables. I should try to reproduce with Fedora or something first.

I was also thinking I could try wined3d as another data point. Most recently, I've reproduced this with Batman: Arkham City, which is far from new, although I did add a texture pack.

You can check https://gitlab.freedesktop.org/mesa/...ref_type=heads to get some data to go on, but yes, random hangs after an hour of play will be hard to debug. Running Gentoo or whaterver distro doesn't really matter, the driver code is the same (unless you compile Mesa with LTO, which is known to introduce "random" issues). Testing with wined3d is pointless in this case, since this will use OpenGL and thus a completely different driver. Even testing wined3d vulkan wouldn't really tell you much because the different usage patter could just not trigger the bug.

[Chewi]

unless you compile Mesa with LTO, which is known to introduce "random" issues.

You don't say. Mesa is the only thing I build with LTO. I generally believe it's not worth the extra build time, but I thought Mesa was a worthy exception. Well, I'll definitely try without then, thank you.

I wanted to test with wined3d so that I could rule RADV out.

[pWe00Iri3e7Z9lHOX2Qx]

I haven't previously cared about AMDVLK, but now I do because I have found that using it seems to prevent my whole system from spontaneously rebooting while playing certain games. I was on the verge of sending my 6800 XT back as I was so sure it must be a hardware issue, having ruled out a few other things, and also because the system doesn't even see the GPU when it initially comes back up. It seems to hold up with AMDVLK though. I haven't seen a crash with AMDGPU-Pro either, but its gaming performance is pretty bad. I would have preferred a hardware issue as driver issues are a nightmare, especially one like this! Maybe I can bisect Mesa, but given that it can take over an hour to crash, that could send me down a lot of blind alleys. That's assuming this isn't simply because RADV can push the card harder than the other drivers can.

I've recently been seeing some serious instability on my AM5 / Zen 4 all AMD desktop. I've been using the hybrid graphics option enabled with the Zen 4 IOD, so all 3 displays hooked up to the motherboard iGPU, with a RX 6700 XT waiting for gaming and other tasks on demand. I'm seeing hard crash / reboots, even sometimes just from refreshing a Firefox tab. Is it janky UEFI code from my motherboard manufacturer? Is it amdgpu bugs? Is it Mesa bugs? Graphics problems can be really hard to root cause. For now I've completely disabled the iGPU and hooked up all the displays to the RX 6700 XT. We'll see if the issues disappear fully.

[FireBurn]

Is there any point when there's almost nothing to go on? I'm running Gentoo, so there are a lot of variables. I should try to reproduce with Fedora or something first.

I was also thinking I could try wined3d as another data point. Most recently, I've reproduced this with Batman: Arkham City, which is far from new, although I did add a texture pack.

Unless you're doing something really crazy, it shouldn't be crashing, I'm always using mesa-9999 -O3 -march=native with LTO using Clang

I have /lib/firmware as a git clone of https://git.kernel.org/pub/scm/linux...x-firmware.git which I update each time I rebuild my kernels (the firmware is baked in)

https://github.com/FireBurn/KernelSt...ter/git-update is the update script I use

[mbriar]

Unless you're doing something really crazy, it shouldn't be crashing, I'm always using mesa-9999 -O3 -march=native with LTO using Clang

I have /lib/firmware as a git clone of https://git.kernel.org/pub/scm/linux...x-firmware.git which I update each time I rebuild my kernels (the firmware is baked in)

https://github.com/FireBurn/KernelSt...ter/git-update is the update script I use

Just because you don't hit any gpu hangs in the workloads/games you're running doesn't mean gpu hang causing bugs don't exist.

[Chewi]

I rebuilt without LTO, and whaddya know, it held up during my first session. I was so happy and was planning to upgrade my Ryzen 5 3600 to celebrate. Then on the second session...

Not that then. I normally build with GCC (currently 14) and -march=znver2 -O2. Hardly controversial. To shake things up a bit, I've rebuilt Mesa with Clang (currently 18) and -march=x86-64-v2 -O2. I doubt it will help but let's see.