Bug: Freezing and Crashing when opening or rendering in Fusion

[shumisan]

This issue is NOT about missing codecs

• I understand

Describe the bug

Trying to render with videos using multiple codecs (VP9, H.264, and FFV) inside specifically the Fusion workspace will lead to Davinci Resolve Studio freezing, and then crashing after a bit. These videos play fine in the Edit workspace, but will crash DR once you touch it in Fusion.

Steps to reproduce

Open project
Add media, specifically a clip
Open it in Fusion
If not automatically, manually render it
Freezes and crashes shortly after

Installation method used

setup.sh, Manual with Distrobox

OS Version

CachyOS

Desktop Environment

KDE Plasma 6.5.5

GPU Vendor

AMD

GPU Model

RX 5700

CPU

Intel(R) Xeon(R) E5-2680 v2

CPU w/ integrated GPU?

No iGPU

DaVinci Resolve Free or DaVinci Resolve Studio

Studio

DaVinci Resolve version

20.3.1.0006

Davincibox build (NOT the GitHub release number)

ghcr.io/zelikos/davincibox-opencl latest e20e4d94d97b 43 hours ago 2.68 GB

Extra context

Running through the command line shows this error when quitting:
Job 1, '/opt/resolve/bin/resolve' terminated by signal SIGSEGV (Address boundary error)

Switching off h.264 GPU acceleration or turning on easyDCP didn't seem to change anything.

I tried to use setup.sh initally to install, but ran into problems where passing in the installer went blank, so i manually installed after using the pre-existing davincibox made by setup.sh.

[shumisan]

After some time, I tried to investigate what else could be the problem, and found something with switcherooctl. When running switcherooctl version, It doesn't work, and spits out this error:

Traceback (most recent call last):
  File "/usr/bin/switcherooctl", line 187, in <module>
    launch(args, gpu)
    ~~~~~~^^^^^^^^^^^
  File "/usr/bin/switcherooctl", line 66, in launch
    os.execvp(args[0], args)
    ~~~~~~~~~^^^^^^^^^^^^^^^
  File "<frozen os>", line 612, in execvp
  File "<frozen os>", line 654, in _execvpe
  File "<frozen os>", line 645, in _execvpe
FileNotFoundError: [Errno 2] No such file or directory

I went ahead and reinstalled manually to make sure, but switcherooctl spat out the same error. switcherooctl list also gives no output.

I also tried to switch to KDE Wayland from X11, which didn't seem to change anything.

I'm inclined to believe this is a problem with ROCm, since the RX 5700 hasn't been supported on the latest 7.2 release, but switching to rusticl through instructions provided and using run-davinci -c makes the editor crash when opening a project with any media in it.

I checked in ResolveDebug.txt after changing to rusticl and found a crash dump. It's below.

==========[CRASH DUMP]==========
#TIME Sun Feb  1 12:05:58 2026 - Uptime 00:00:29 (hh:mm:ss)
#PROGRAM_NAME DaVinci Resolve Studio v20.3.1.0006 (Linux/Clang x86_64)
#BMD_ARCHITECTURE x86_64
#BMD_BUILD_UUID 5f90fb54-d661-4f14-9db1-3148deb6eb0f
#BMD_GIT_COMMIT d031039b09e055f0d8d437a51ff3d87f364f4765
#BMD_UTIL_VERSION 20.3.1.0006
#OS Linux

/opt/resolve/bin/resolve() [0x6087e49]
/opt/resolve/bin/resolve() [0x6087012]
/lib64/libc.so.6(+0x1a040) [0x7fb645429040]
/opt/resolve/bin/../libs/libProResRAW.so(_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv+0x38) [0x7fb6424da708]
/lib64/libRusticlOpenCL.so.1(+0x9705be) [0x7fb5f8f9c5be]
/lib64/libRusticlOpenCL.so.1(+0x977b57) [0x7fb5f8fa3b57]
/lib64/libRusticlOpenCL.so.1(+0x969aa5) [0x7fb5f8f95aa5]
/lib64/libRusticlOpenCL.so.1(+0x8bd3c) [0x7fb5f86b7d3c]
/lib64/libRusticlOpenCL.so.1(+0x713e9) [0x7fb5f869d3e9]
/lib64/libRusticlOpenCL.so.1(+0x88831) [0x7fb5f86b4831]
/lib64/libOpenCL.so.1(clBuildProgram+0x9f) [0x7fb6509303ef]
/opt/resolve/bin/resolve() [0x9c0d003]
/opt/resolve/bin/resolve() [0x9c0c1ec]
/opt/resolve/bin/resolve() [0x9c0d29b]
/lib64/libc.so.6(+0x71f14) [0x7fb645480f14]
/lib64/libc.so.6(+0xf532c) [0x7fb64550432c]
Signal Number = 11

================================

I'll see if this still happens on the Free version tomorrow... I hope this isn't just a sign of my GPU failing...

[zelikos]

I'll see if this still happens on the Free version tomorrow... I hope this isn't just a sign of my GPU failing...

Fusion had been very hit-or-miss for me with ROCm on an RX 6600XT, even when that series of GPUs was still supported in ROCm. Sinces your GPU is from an even older series, I'm much more inclined to believe it's an ROCm issue than GPU failure.

I've seen mention in other issue reports that enabling rusticl in davincibox isn't working either, but, that's another thing I'll need to investigate when I find the time to

[shumisan]

I did more research, and i probably should've realized way earlier, but the RX 5700 and other gfx101X cards were never supported officially by ROCm. (is that better or worse than my GPU failing?) I'm gonna assume this is the main issue.

ROCm 6.2 is the one currently in davincibox, and the compatibility matrix has no mention of gfx1010, or the RDNA1 architecture.

So, instead I've tried to change the HSA_OVERRIDE_GFX_VERSION to those supported on 6.2. Here's the results I've gotten from just starting resolve. It's probably not working since the architectures are completely incompatible, but it was worth a shot:

HSA Override Value	GPU	Architecture	Result
11.0.0	gfx1100 - 7900(XT)/7800	RDNA 3	didn't test
10.3.0	gfx1030 - 6800(XT)	RDNA 2	Complete freeze, PC had to be force shut down
9.4.2	gfx942 - MI300X (?)	CDNA 3	App hangs on loading Fairlight Engine, session crashes shortly after
9.0.a	gfx90a - MI250	CDNA 2	didn't test
9.0.8	gfx908 - MI100	CDNA	App hangs on loading Fairlight Engine, session crashes shortly after

I didn't bother with the ones inbetween, since it was clear it'd just crash since it's probably executing instructions the GPU doesn't understand.

After more research, ROCm also only works with CPUs that support PCIe Atomics, which on Intel is Haswell and newer. Apparently specifically the E5-26XX v2 series of CPUs are an exception to this though. So, I'm gonna try downgrade to 5.6 and/or 5.2 and change the override value to gfx906, which is the Radeon VII, and pray that it Just Works, but otherwise, it's back to rusticl.

I've made a pull request to change the readme to state the RX 6000+ series are those supported with ROCm since those are the ones supported on the current davincibox. (It's my first, so please tell me if anything's wrong with it!)

If I manage to get ROCm to work with the semi-ghetto downgrade method, should I make a pull request to add those as options to the setup?

Also... I ran out of space on my SSD to download the Free version, so i got lazy and didn't bother check if anything changes when running it on the Free version. Oops. I doubt it'd lead to anything though.

[zelikos]

#241 to state the RX 6000+ series are those supported with ROCm since those are the ones supported on the current davincibox. (It's my first, so please tell me if anything's wrong with it!)

Will review it after I post this reply

If I manage to get ROCm to work with the semi-ghetto downgrade method, should I make a pull request to add those as options to the setup?

I don't really want to encourage people to do anything like that. For cards that aren't supported by ROCm, I'd rather figure out getting rusticl working again

Also... I ran out of space on my SSD to download the Free version, so i got lazy and didn't bother check if anything changes when running it on the Free version. Oops. I doubt it'd lead to anything though.

Yeah, things like GPU driver issues should be identical between Free and Studio

[shumisan]

After wasting about an hour trying to downgrade, it's becoming obvious to me that it's best to change to rusticl.

Theoretically, changing all the ROCm libraries to whatever Debian is using rather than actually downgrading would allow for the card to work in a much easier manner, since the maintainers over there have opted to enable the gfx101X series of cards, but I'm not really sure if that's worth the effort to try put on the Fedora-based box.

However, AMD seems to have atleast implied that RDNA1 along with other GPUs will eventually get supported, with some sorta shake up to the ROCm infrastructure. So in the future, this wouldn't be a problem, atleast theoretically.

Until then, I guess it's trying to figure out the problem with Rusticl.