OpenSuSE and AMDGPU

This web site requires that javascript be enabled. Click here for instructions..

First impressions of GPU support

Relevant hardware information:

AMD R9 3900X
AMD B550
AMD RX 6700XT

Support Summary:

Out of box (No work arounds):

3/10 - Broken by both OpenSuSE and AMD simple as.
OpenSuSE's current stable release Leap 15.2 does not enable complete functionality and latest rolling release Tumbleweed also does not boot live nor installer with the hardware combination.

Using work arounds:

8/10 - With the exception being a few titles which are flaky to run on Linux regardless.
Although not certain if recent Wine-Proton updates or game updates in some cases have caused instability/broken launchers (Looking at you, Rockstar Games).

OpenGL: Seems fine for Steam and titles which are native/Wine Proton and can be made to use OpenGL.
Vulkan: Works with ICD overrides for 64 & 32bit titles and rare combinations that require both -- e.g. MGS:V - TPP.
OpenCL: Still not yet working in custom Mesa build.

OpenCL can be partially forgiven to some extent as this has been a long standing issue with discussions/steps being made -- See ROCm GitHub Issue Tracker.
Notably this prevents applications such as video editing in BlackMagic Design - DaVinci Resolve from being remotely functional currently even with known workarounds.

However, the growing reliance upon DXVK as a translation layer building block for Windows games under Linux in Steam -- being the primary platform aside from advanced users' spinning their own builds of Wine -- still make this a first pass deal-breaker for ease of use to a Linux user who's not experienced with the library dependencies.
There is however a partial workaround to get Vulkan to work by building from source, again with some workarounds, plus use of VK_ICD_FILENAME environment variable as a band-aid solution.

I guess you could say, "Well, sure glad OpenGL/EGL works eh?"
And after all, we're Linux users so we're happy when anything works.
When it doesn't, at least we mostly know how to file a bug report and probably give some basic analysis back to a QA team.

Software information:

OpenSuSE Leap 15.2
5.3.18-lp152.66-default (73933a3) x86_64
Mesa-19.3.4-lp152.27.1
amdgpu-20.50-1234663-sles-15.2

See later on how I fixed the amdgpu-dkms issues seen here...

Trials so far...

I believe the Vulkan breakage to be a combination of the need for updates in the Kernel driver space for NAVY_FLOUNDER/Navi22 + Firmware (XZip) bundled correctly to preload at init/boot, plus Mesa support for device identification along with the LLVM version used.
Typically somewhere in either Mesa or the amdgpu driver code, when running an strace of any payload will yield:

amdgpu: unknown (family_id, chip_external_rev): (143, 50)

The above are the values for RDNA 2 Navi22 / NAVY_FLOUNDER, basically stating it has (apparently) no idea what it is, which would be correct for any Mesa releases before release in March 2021 so that is understandable...

Tried two other combinations to try and verify if this was resolvable with whatever I could find available from OBS official or community packages generated

One of the issues is finding a full suite of sources/headers, binaries and firmware, all with the consistent build naming for the same revision as a backport for Leap 15.2.

#1: Mesa 21.1.0 (From OBS repository - Community user generated)

#2: Mesa 20.3.4 (From OBS X11 repository)

Further tweaks based on these combinations by installing and fully upgrading Mesa packages missing from installing the main metapackage, at best I managed to get Vulkan to function at the expense of Steam GLX compatibility.
This also curiously meant booting up in run level 3 and starting Xorg by hand jumping to run level 5, segfaults in pthreads, amdgpu libraries and gnome-shell...
I then later got DOOM (2016) to run via Steam with Proton, only for it to fully lock up Xorg with the sound still going forcing a hard-reset.
Winding back to 20.3.4 of Mesa had no improvement on the situation.

In both cases:

Backported kernel 5.11.11 for Leap 15.2 (From OBS - Official + Community user generated as some packages are missing)
Must keep 19.3.4 libGL-32bit for Steam to function / open.
Installation of d3d tracker/other libraries not automatically included in the requisites for the main Mesa package breaks Wine Proton DXVK.
Still no better, graphical artefacts seen as hinted to by Phoronix though

None of the above can truly be considered clean due to the amount of workarounds stacked/compounded.

Repositories of interest if you have more luck than me:

OpenSuSE - Kernel:/stable/standard/ - Source Packages + Missing Binaries
OpenSuSE - Kernel:/stable:/Backport/standard - Backport for kernel-default, kernel-default-devel, kernel-syms etc
X11 - Mesa 20.3.4 - OpenSuSE Leap 15.2
OBS - Mesa 21.1.0 - home:/khnazile:/video/openSUSE_Leap_15.2
OBS Project - Kernel:stable:Backport

Fixing the amdgpu-dkms build

Steps required to fix the amdgpu-dkms compatibility require patching to the existing source package.
I have done this manually but could be automated with a spec + package.

There are two files that need to be fixed up, the first simply enabled a feature already provided by AMDs amdgpu-dkms sources...

Changes you will need to make are as below either by hand or in a specfile if you want to build a custom RPM:

--- usr/src/amdgpu-5.9.10.69-1234663/Makefile	2021-03-27 23:41:05.475260712 +0000
+++ /usr/src/amdgpu-5.9.10.69-1234663/Makefile	2021-03-27 23:23:28.946581261 +0000
@@ -183,6 +183,22 @@
 endif
 endif
 
+# Patching function redefinition issue
+TMP_KVER:=$(shell echo $(KERNELRELEASE) | awk -F '-' '{print $$1"-"$$2}')
+MMU_CONTEXT_H:=/usr/src/linux-$(TMP_KVER)/include/linux/mmu_context.h
+$(info MMU file header: $(MMU_CONTEXT_H))
+ifneq (,$(wildcard $(MMU_CONTEXT_H)))
+
+HAS_KTUMM=$(shell grep -c "use_mm" $(MMU_CONTEXT_H))
+$(info MMU file header matches: $(HAS_KTUMM))
+ifneq ($(HAS_KTUMM),0)
+subdir-ccflags-y += -DHAVE_KTHREAD_USE_MM
+endif
+
+endif
+# ------------------------------------
+
+
 export OS_NAME OS_VERSION
 
 LINUXINCLUDE := \
--- usr/src/amdgpu-5.9.10.69-1234663/amd/amdgpu/amdgpu_amdkfd.h	2021-03-27 23:41:05.339260713 +0000
+++ /usr/src/amdgpu-5.9.10.69-1234663/amd/amdgpu/amdgpu_amdkfd.h	2021-03-27 23:30:47.034570969 +0000
@@ -28,6 +28,9 @@
 #include <linux/types.h>
 #include <linux/mm.h>
 #include <linux/kthread.h>
+#ifdef HAVE_KTHREAD_USE_MM
+#include <linux/mmu_context.h>
+#endif
 #include <linux/workqueue.h>
 #include <kgd_kfd_interface.h>
 #include <drm/ttm/ttm_execbuf_util.h>

Which is why this baffled me to begin with, why there wasn't some detection of this as the fix is absolutely trivial -- I have zero knowledge of the source base and figured this out in 5 minutes.
The second extends this fix for the use of the functions which are present if they exist in the base kernel memory management, which, they do so why not use them as intended?

Well, to be fair it's highly likely they were working against 5.9.10 as indicated in the directory name above -- and so, who the heck cares about what happened 6 minor versions ago, eh? That's in the past...

Rebuilding the DKMS module without reinstalling the source/full AMDGPU stack

It's easier than you think, issue the rebuild command :

# sudo dkms autoinstall

Close + save anything you need, and then reboot:

# sudo init 6

Note:

If you made the modifications by hand be sure not to forcibly reinstall/remove the amdgpu-dkms package as this undoes our hard work for any future kernel rebuilds triggered by zypper/YaST package installations/kernel upgrades etc.
These fixes will not break builds for later versions of the kernel as you can see in later experiments I conducted, although the detection is basic/dumb it does the job.
TODO: Guide - Debugging Xorg Initialisation

Building Mesa from source

You will need the following installed at bare minimum including compiler tools:

sudo zypper in \
meson meson-test \
libvdpau-devel libvdpau-devel-32bit \
clang-devel \
clang11 llvm11 libLLVM11 libLLVM11-32bit\
xshmfence libxshmfence-devel \
glproto glproto-devel \
dri2proto dri2proto-devel \
valgrind valgrind-client-headers \

You will additionally require LLVM / Clang 11 from OpenSuSE repositories online as we do not have these by default in Leap 15.2 stable.
Thankfully there is a One-click Installer available with what we need.

Due to the flaky way that LLVM detects which version to use out of all versions available in the system, means that often it will simply stick to LLVM 9.0.1 as provided in Leap 15.2.
However this is not sufficient for Mesa OpenGL + OpenCL to meet its minimum requirements, and will statically break support for NAVY_FLOUNDER / "GFX1030".
This condition can be found encoded here:

#src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
        /* LLVM 11 is required for GFX10.3. */
        if (ws->info.chip_class == GFX10_3 && ws->use_llvm && LLVM_VERSION_MAJOR < 11) {
                fprintf(stderr, "radv: GFX 10.3 requires LLVM 11 or higher\n");
                return false;
        }

... Although explicit reasoning is missing here, so I have taken it at its word that it is needed and cannot be simply hacked without bad things happening.

You can determine what is still missing for building by continuing to re-run the meson build step and installing the missing packages as needed.

You will need to clone a copy of the source code and ensure you are using this specific revision: f89c8ba4101

mkdir -p ~/Software/Mesa/
cd ~/Software/Mesa/
git clone https://github.com/mesa3d/mesa.git mesa-git
git checkout f89c8ba4101

The following 'fixes' (ahem) needed to be applied:

commit 4868775d30c209f93e879175e7c35773ad386345 (HEAD -> master)
Author: Jim Shorter <jim@jimshorter.me.uk>
Date:   Wed Apr 7 23:49:58 2021 +0100

    Couldn't give a shit about broken nouveau code path

diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c b/src/gallium/drivers/nouveau/nouveau_screen.c
index 80ef7a12c44..db0b361748b 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -260,7 +260,7 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev)
             start += screen->svm_cutout_size;
             continue;
          }
-
+       /* BORKED: Constructors, I don't care about NShitia
          struct drm_nouveau_svm_init svm_args = {
             .unmanaged_addr = (uintptr_t)screen->svm_cutout,
             .unmanaged_size = screen->svm_cutout_size,
@@ -270,7 +270,7 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev)
                                &svm_args, sizeof(svm_args));
          screen->has_svm = !ret;
          if (!screen->has_svm)
-            os_munmap(screen->svm_cutout, screen->svm_cutout_size);
+            os_munmap(screen->svm_cutout, screen->svm_cutout_size);*/
          break;
       } while ((start + screen->svm_cutout_size) < BITFIELD64_MASK(limit_bit));
    }
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 8bae491e526..f00a4c5661f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -42,7 +42,7 @@ nvc0_svm_migrate(struct pipe_context *pipe, unsigned num_ptrs,
    struct nouveau_screen *screen = &nvc0->screen->base;
    int fd = screen->drm->fd;
    unsigned i;
-
+/* BORKED - args' type size is unknown
    for (i = 0; i < num_ptrs; i++) {
       struct drm_nouveau_svm_bind args;
       uint64_t cmd, prio, target;
@@ -68,10 +68,10 @@ nvc0_svm_migrate(struct pipe_context *pipe, unsigned num_ptrs,
       args.header |= prio << NOUVEAU_SVM_BIND_PRIORITY_SHIFT;
       args.header |= target << NOUVEAU_SVM_BIND_TARGET_SHIFT;
 
-      /* This is best effort, so no garanty whatsoever */
       drmCommandWrite(fd, DRM_NOUVEAU_SVM_BIND,
                       &args, sizeof(args));
    }
+*/
 }
commit 11d799780368e04ccf464685306cc0fc7dbf12a2
Author: Jim Shorter <jim@jimshorter.me.uk>
Date:   Wed Apr 7 23:05:09 2021 +0100

    Hack the libdrm_intel version because, fuck intel why do I care?

diff --git a/meson.build b/meson.build
index c69659afc2c..ba3da0602b0 100644
--- a/meson.build
+++ b/meson.build
@@ -1453,7 +1453,7 @@ dep_libdrm_intel = null_dep
 
 _drm_amdgpu_ver = '2.4.100'
 _drm_radeon_ver = '2.4.71'
-_drm_nouveau_ver = '2.4.102'
+_drm_nouveau_ver = '2.4.100'
 _drm_intel_ver = '2.4.75'
 _drm_ver = '2.4.81'

These hacks will only affect functionality if you care particularly about:

Having functional NVidia opensource driver (nouveu) functional, or
An Intel IGPU (maybe dGPU later this year) that you need to rely upon since the minimum library requirement is not satisfied by OpenSuSE 15.2

Copy the above to a patch file and save this in the root directory of the mesa-git directory we made earlier.
Then you can apply from the terminal, like so:

cd ~/Software/Mesa/mesa-git
patch -p1 < fixes.patch

For the build process, it is very important to not run this via sudo nor as your root user:

cd ~/Software/Mesa/mesa-git
mkdir -p build/install && cd build
meson \
  --prefix=/home/$USER/Software/Mesa/mesa-git/build/install \
  --libdir=lib64 \
  -Dgallium-opencl=disabled \
  -Dgallium-drivers=radeonsi,swrast \
  -Dgallium-nine=true \
  ..
# Build and then subsequently install in our non-root install area
ninja 
ninja install

Note we currently need to disable OpenCL, there are apparently two modes to build

# , disabled
... -Dgallium-opencl=icd ... # or standalone

Wait a little while, once it passes the build process you can then write a manual override trick to get things going for any Vulkan payloads.

You're done, the hard part is basically over :) All that is left to do, is force the applications we want to use the correct library.
We can do this a more elaborate way, but this is still a first pass and non-system destructive way to proceed rather than forcibly installing libraries over the top of your system areas.

Basic test application

You can test whether vulkan is broken first by using vkmark as a crude test:

sudo zypper in vkmark
vkmark

You can also check if OpenCL no longer complains about the GPU being an unknown family & chip, with:

LD_PRELOAD="/home/$USER/Software/Mesa/mesa-git/build/src/gallium/targets/opencl/libOpenCL.so.1.0.0" clinfo

... that is, if you can get Meson build system to actually accept all the LLVM requirements checks that fail for no good reason.

Then, with our workaround thanks to this post on Reddit r/linux_gaming - AMD GPU Vulkan driver: How to easily switch between RADV and AMDVLK:

VK_ICD_FILENAMES="/home/$USER/Software/Mesa/mesa-git/build/src/amd/vulkan/radeon_icd.x86_64.json"  vkmark

Did you see a window open with a white mesh of a horse spinning?
If so, great! This is equally the most underwhelming benchmark alongside glxgears :) But heck it does the job!

Turns out you can also do something similar for OpenCL (And maybe even OpenGL) ICD loader profiles except it is not JSON using the environment variable: CL_ICD_FILENAMES (Maybe GL_ICD_FILENAMES?).

Building 32bit Mesa

Cross compile file needed, this may not be correct yet:

[binaries]
c='gcc'
cpp='g++'
ar='ar'
strip='strip'
pkgconfig='i586-suse-linux-gnu-pkg-config'
llvm-config='/usr/bin/llvm-config-32'

[properties]
c_args=['-m32', '-march=native']
c_link_args=['-m32']
cpp_args=['-m32', '-march=native']
cpp_link_args=['-m32']

[host_machine]
system='linux'
cpu_family='x86'
cpu='x86'
endian='little'

Again need a few things installed before we can build this:

# Provide the missing i586-suse-linux-gnu-pkg-config since this is not available for Leap 15.2
# This was taken directly from a later OpenSuSE rolling release build (Tumbleweed)
# Write this inside your "build_32" directory
#----------------------------------

#!/bin/sh

# Simple wrapper to tell pkgconf to behave as a platform-specific version of pkg-config
# Platform: i586-suse-linux-gnu

if [ -z "${RPM_BUILD_ROOT}" ]; then
	export PKG_CONFIG_LIBDIR="${PKG_CONFIG_LIBDIR:-/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig}"
	export PKG_CONFIG_SYSTEM_LIBRARY_PATH="${PKG_CONFIG_SYSTEM_LIBRARY_PATH:-/usr/local/lib:/usr/lib}"
	export PKG_CONFIG_SYSTEM_INCLUDE_PATH="${PKG_CONFIG_SYSTEM_INCLUDE_PATH:-/usr/local/include:/usr/include}"
else
	export PKG_CONFIG_LIBDIR="${PKG_CONFIG_LIBDIR:-/usr/lib/pkgconfig:/usr/share/pkgconfig}"
	export PKG_CONFIG_SYSTEM_LIBRARY_PATH="${PKG_CONFIG_SYSTEM_LIBRARY_PATH:-/usr/lib}"
	export PKG_CONFIG_SYSTEM_INCLUDE_PATH="${PKG_CONFIG_SYSTEM_INCLUDE_PATH:-/usr/include}"
fi

exec pkgconf "$@"
#----------------------------------

# Write the above to a file and chmod 750
chmod 750 i586-suse-linux-gnu-pkg-config

# Tools and libraries not likely installed by default
# GCC7 32bit, libelf 32bit, X Video / Video Motion compensation library
sudo zypper in \
cross-i386-gcc7 \
libelf1-32bit libelf-devel-32bit \
libXv-devel libXv1-32bit libXvMC1-32bit libXvMC-devel-32bit libXvMC1-32bit

# Create links for the libraries to keep this consistent with lib64
sudo ln -s /usr/lib/libXv.so.1             /usr/lib/libXv.so
sudo ln -s /usr/lib/libxcb-xfixes.so.0     /usr/lib/libxcb-xfixes.so
sudo ln -s /usr/lib/libxcb-shm.so.0        /usr/lib/libxcb-shm.so
sudo ln -s /usr/lib/libxcb-dri2.so.0       /usr/lib/libxcb-dri2.so
sudo ln -s /usr/lib/libxcb-dri3.so.0       /usr/lib/libxcb-dri3.so
sudo ln -s /usr/lib/libxcb.so.1            /usr/lib/libxcb.so
sudo ln -s /usr/lib/libxcb-present.so.0    /usr/lib/libxcb-present.so
sudo ln -s /usr/lib/libxcb-sync.so.1       /usr/lib/libxcb-sync.so
sudo ln -s /usr/lib/libxcb-randr.so.0      /usr/lib/libxcb-randr.so
sudo ln -s /usr/lib/libxshmfence.so.1      /usr/lib/libxshmfence.so
sudo ln -s /usr/lib/libxcb-glx.so.0        /usr/lib/libxcb-glx.so

sudo ln -s /usr/lib/libwayland-client.so.0 /usr/lib/libwayland-client.so
sudo ln -s /usr/lib/libwayland-server.so.0 /usr/lib/libwayland-server.so

sudo ln -s /usr/lib/libexpat.so.1          /usr/lib/libexpat.so

sudo ln -s /usr/lib/libunwind.so.8         /usr/lib/libunwind.so

sudo ln -s /usr/lib/libzstd.so.1           /usr/lib/libzstd.so

# We do not have a separate 32bit static library package for libzstd in OpenSuSE
# Without this the 32bit linking process will fail
sudo ln -s /usr/lib64/libzstd.a            /usr/lib/libzstd.a

#NOTE: If your links are missing the original library, you can install them by following:
#  sudo zypper search <libname>
#  sudo zypper in <libname>-32bit

Now we can finally produce the ninja build file and fix up the last three things:

cd ~/Software/Mesa/mesa-git
mkdir -p build_32//install && cd build_32
cd build_32
meson \
  --prefix=/home/$USER/Software/Mesa/mesa-git/build_32/install \
  --libdir=lib \
  -Dgallium-opencl=disabled \
  -Dgallium-drivers=radeonsi,swrast \
  -Dgallium-nine=true \
  --cross-file /home/$USER/Software/Mesa/mesa-git/build_32/cross_file2 \
  ..

cat build.ninja | \
  sed -e 's#lib64/#lib/#g' \
      -e 's#/usr/lib/gcc/x86_64-suse-linux#/usr/lib64/gcc/x86_64-suse-linux#g' \
      -e 's#-lLLVM#/usr/lib/libLLVM.so.11#g' > build.ninja.1
mv build.ninja build.ninja.orig
mv build.ninja.1 build.ninja
ninja

The fact that it is still searching lib64 seems to suggest pkg-config override is still not working correctly.
Unfortunately we have to use the lib64 area for the compiler but all other libraries are in lib, hence the two replacements made.
The third fix is critical and also requires us to ensure that it links with the 32bit library not the 64bit library.

Again for Vulkan we need to override the ICD profile to use:

VK_ICD_FILENAMES="/home/$USER/Software/Mesa/mesa-git/build_32/src/amd/vulkan/radeon_icd.x86_64.json" <other_args=values> %command% <+game_options>

This brings us to another type of fix needed specifically for OpenGL applications, if the applications are 32 or 64bit and require OpenGL (Native Linux or Windows).
For example: Borderlands 2 (Native Linux 32bit build) and Payday: The Heist (32bit Windows-only, but requires it for Wine-Proton)

# 64bit
LD_PRELOAD="/usr/lib64/libLLVM.so.11:/home/$USER/Software/Mesa/mesa-git/build/install/lib64/libGL.so.1.2.0:/home/$USER/Software/Mesa/mesa-git/build/install/lib64/libEGL.so.1.0.0" LIBGL_DRIVERS_PATH="/home/$USER/Software/Mesa/mesa-git/build/install/lib64/dri/" <shell_args=value> %command% <game_args>

# 32bit
LD_PRELOAD="/usr/lib/libLLVM.so.11:/home/$USER/Software/Mesa/mesa-git/build_32/install/lib/libGL.so.1.2.0:/home/$USER/Software/Mesa/mesa-git/build_32/install/lib/libEGL.so.1.0.0" LIBGL_DRIVERS_PATH="/home/$USER/Software/Mesa/mesa-git/build_32/install/lib/dri/" <shell_args=value> %command% <game_args>

Steam applications

Now, to use the correct libraries we must apply the following override to every game that needs DXVK for Wine or Vulkan in a native Linux application.
In Steam applications, you can right click on the title you want to modify and select "Properties..."
In the new dialog, you need to be in the "General" tab and see the "Launch Options" entry.
Now add the variable like so

VK_ICD_FILENAMES="/home/$USER/Software/Mesa/mesa-git/build/src/amd/vulkan/radeon_icd_local.x86_64.json" <other_args=values> %command% <+game_options>

You will likely find that games will need to reconfigure their settings again since you have upgraded the GPU.
They will currently default to medium/low/potato since they have no idea what a 6700XT actually is, but this is not the end of the world so long as they launch or you can override their configuration files.

Steam games at the time of writing

Working/Functional - 64bit Mesa Vulkan:

Fallout 4
Kingdom Come: Deliverance - Performance is lacking, settings often do not apply without restarting. Use NexusMods - Optimised Graphics Settings as a workaround for 80+FPS playable on modified high.
The Witcher III: Wild Hunt
Rise Of The Tomb Raider
Shadow Of The Tomb Raider
DOOM (2016) - You must have the ICD override plus Vulkan selected in the game settings*1
Dying Light - Must use (at time of writing) Proton 5.0-10.

*1: You can find your configuration file under:

"/home/$USER/.local/share/Steam/steamapps/compatdata/379720/pfx/drive_c/users/steamuser/Saved Games/id Software/DOOM/base/DOOMConfig.local"
r_renderAPI "1" // 1 = Vulkan, 0 = OpenGL

You may want to test with OoenGL if you experience performance issues however from my limited testing, the escape menu once you are in-game leads to some poor frame rates for the menu only.

With 32bit Mesa Vulkan:

Call of Duty - Modern Warfare 2
DiRT 3 - Compete Edition - Although no longer officially available on Steam as a new-purchase.
Fallout: New Vegas - No issues.
Hitman: Absolution - Some visual issues with faces having triangles in the wrong order.

Requires both 64-bit and 32-bit Mesa in the ICD string:

Metal Gear Solid V: Phantom Pain - Launches, due to update first launch seems to sit on loading screen before online can connect but works with subsequent launch.

Requires 32bit OpenGL:

Borderlands 2 - Native for Linux works perfectly.
Payday - The Heist - Wine-Proton works perfectly.

Broken / ** Neither 64 or 32bit Vulkan nor OpenGL is sufficient, requires other libraries?:

Sleeping Dogs - Hangs before startup / splash screen**.
GTA: V - Launcher fails to connect to your account after recent game update again.

What about switching to Tumbleweed?

Latest Tumbleweed rolling build as of writing: Snapshot 20210330

Fails to cleanly start Xorg on the installation version with the above hardware setup
The live image has the same behaviour, in failsafe mode it gets further then hangs on expanding the rootfs.img timing out dropping you to an ineffective root terminal

Have not yet tested system upgrade from Leap 15.2, as I have been putting off doing this until I exhaust acceptable backports or workarounds.
This would include booting with a known supported GPU to facilitate installation or upgrade and then switching back the GPU post-installation.

Further thoughts

This leaves some questions about alternative routes.

Q. What about transplanting the amdgpu kernel/drivers to 5.3.18?

I took a cursory look at whether it would be possible to simply take a patch of the amdgpu-only code in the kernel sources.
And partly to my surprise there's about a 5.4MB diff of the non-binary changes just in the amdgpu kernel area itself independent of the other interface changes around the outside/periphery that also break in trying to transplant this backwards.
And this is not to trivialise the amount of effort that goes in to any driver or well functioning piece of software that is neglected and relied upon by millions.

However, even as far as retaining the driver code is also not a quick fix scenario as too many dependent changes are seemingly -- well, likely -- required for this to work out with minimal effort.
It may well be possible with some effort in understanding and reworking to retain compatibility against the older kernel.

This leaves the best bet being any existing backports that can be improved to be more complete, to serve as a stable stop gap on the understanding future updates will be impacted as chosen by the user.
Ah, the joys and burdens of having a real choice! But at least you have some.

Q. What is the rought expected roadmap for Leap 15.3?

i.e. How long might we be waiting for functionality to improve?
If there are plans to at least include Kernel ~5.12.x and Mesa 21.x.x along with the required GPU firmware I think this problem eventually goes away - As greater stability would be offered.

Currently only the upgrades on Leap 12.3 that are planned at the time of writing are to Mesa which might be enough to meet the minimum requirements.
However, with current kernel stability pegged rightly against the SLES15 kernel release schedule I am not certain GPU firmware will be enough without at the bare minimum:

The specific device detection being backported...
Plus any known fixes that are needed for device compatibility.
... Well, we can dream :)

Q. Is it worth waiting or just jumping on the rolling bandwaggon?

Using rolling release which as far as I understand does not provide means of say "down-grading" to a long-term stable installation is not possible without full reinstallation.
Unless it happens to be kept old enough that the stable is then an "upgrade" which would be an option.