You are not logged in.
Upgrade from linux 6.11.9.arch1-1 to linux 6.12.1.arch1-1 breaks davinci-resolve. Figured this out experimentally by downgrading the packages back to the state of 2024-11-23, before the 6.12.1 update.
Symptoms:
Loading of a Davinci Resolve project is stuck at 100% without any response, errors, or logs.
When starting an empty project playback doesn't work at all.
The issue seems to affect all versions of Davinci Resolve 19, up to 19.1 (which is not yet in AUR).
The hardware:
Intel i5-7400
AMD Radeon RX 580
The drivers (frozen to the latest version that works with RX 580, see [1] and [2]):
vulkan-amdgpu-pro 23.10_1620044-1
amdgpu-pro-oglp 23.10_1620044-1
amf-amdgpu-pro 23.10_1620044-1
opencl-amd 1:5.7.1-1
This might be related to the problem, but I cannot test it on different hardware.
Downgrading the kernel back to 6.11.9.arch1-1 or using the current linux-lts 6.6.63-1 (probably the most optimal solution for the moment) fixes the issue.
Offline
Mod note: moving to AUR Issues
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
So this means that you have all packages up to date and only downgrading the kernel packages (and nothing else) fixes the issue?
Edit: Also did you already check if there are any interesting error logs? Like for example when you start davinci resolve from the cli or if you have a look at systemlogs like dmesg/journalctl etc.
Last edited by gromit (2024-11-27 11:27:05)
Offline
Please post the output of pacman -Qs rocm
start DR with the latest kernel and close it.
Post the contents of ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt .
opencl-amd should work fine with the opensource drivers, does removing the amdgpu-pro stuff make a difference ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
So this means that you have all packages up to date and only downgrading the kernel packages (and nothing else) fixes the issue?
I did it another way around to detect the problem. First, I downgraded the whole system to the state of 2024-11-23 (resolve works fine), then updated the kernel package to 6.12.1 (resolve breaks). Finally, I updated the whole system up to date again, switching to linux-lts kernel (resolve works).
Edit: Also did you already check if there are any interesting error logs? Like for example when you start davinci resolve from the cli or if you have a look at systemlogs like dmesg/journalctl etc.
Nothing of note. It just silently freezes at 100% project loading.
ActCCMessage Already in Table: Code= c005, Mode= 13, Level= 1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c006, Mode= 13, Level= 1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= c007, Mode= 13, Level= 1, CmdKey= -1, Option= 0
ActCCMessage Already in Table: Code= 2282, Mode= 0, Level= 0, CmdKey= 8, Option= 0
19.0.3.0005 Linux/Clang x86_64
Main thread starts: 8C8AF000
0x7c078c8af000 | Undefined | INFO | 2024-11-27 15:01:28,423 | --------------------------------------------------------------------------------
0x7c078c8af000 | Undefined | INFO | 2024-11-27 15:01:28,423 | Loaded log config from /home/vladar/.local/share/DaVinciResolve/configs/log-conf.xml
0x7c078c8af000 | Undefined | INFO | 2024-11-27 15:01:28,423 | --------------------------------------------------------------------------------
Resolve communication is open and waiting..
Accepted new client
---
Please post the output of pacman -Qs rocm
local/opencl-amd 1:5.7.1-1
ROCr OpenCL stack, supports Vega 10 and later products - Legacy OpenCL stack (Proprietary), supports legacy products older than Vega 10 - This package is intended to work along with the free amdgpu stack.
start DR with the latest kernel and close it.
Post the contents of ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt .
With linux-6.12.1: https://pastebin.com/MBwxTLjd
With linux-lts: https://pastebin.com/cEm1Rcnv
opencl-amd should work fine with the opensource drivers, does removing the amdgpu-pro stuff make a difference ?
I use open source drivers as default ones, running resolve with
vk_pro progl /opt/resolve/bin/resolve
Running it without "vk_pro progl" prefixes yields the same result. Last time I checked (couple of months ago), opencl-amd beyond 1:5.7.1-1 version segfaults on RX 5xx series: https://aur.archlinux.org/packages/open … ent-949758
Offline
Mem data transmitter thread starts: E2D99000
0x7988956af000 | Main | INFO | 2024-11-27 15:29:07,040 | Show splash screen message: Loading Project Libraries
0x7987e359a000 | GPU.MultiBoardMgr | INFO | 2024-11-27 15:29:07,042 | Let There Be OpenCL Light!
0x7987e359a000 | GPU.MultiBoardMgr | INFO | 2024-11-27 15:29:07,042 | Initializing OpenCL board manager for Main Display GPU gpu:57eb8121.f91e8f0c.
0x7987e1d97000 | UI.GLContext | INFO | 2024-11-27 15:29:07,042 | Creating shared OpenGL context for this thread (2 total).
0x7987e1d97000 | DVIP | INFO | 2024-11-27 15:29:07,087 | Created OpenCL context for devices gpu:57eb8121.f91e8f0c
0x7987e1d97000 | DVIP | ERROR | 2024-11-27 15:29:07,112 | Failed to create OpenCL context:
DVIP Exception: OpenCL error
- API: OpenCL
- API Error Code: CL_OUT_OF_HOST_MEMORY (-6)
- Call stack:
1 resolve 0x8266932
2 resolve 0x82efa11
3 resolve 0x82e7e9b
4 resolve 0x82ebd0c
5 resolve 0x66d7f9e
6 resolve 0x66da73b
7 resolve 0x66dac9a
8 resolve 0x66e0e6f
9 libc.so.6 0x798890aa339d
10 libc.so.6 0x798890b2849c
0x7987e1d97000 | GPU.SingleBoardMgr | ERROR | 2024-11-27 15:29:07,112 | Failed to initialize OpenCL board manager for "AMD Radeon RX 580 Series" (gpu:57eb8121.f91e8f0c): Failed to initialize OpenCL context
Please post the outputs of
$ pacman -Qs opencl
$ lscpi -k
$ glxinfo -B
$ clinfo
$ vk_pro progl glxinfo -B
$ vk_pro progl clinfo
Some of the outputs (especially clinfo) can be long, consider using a pastebin service
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Please post the outputs of
$ pacman -Qs opencl $ lscpi -k $ glxinfo -B $ clinfo $ vk_pro progl glxinfo -B $ vk_pro progl clinfo
pacman -Qs opencl: https://pastebin.com/B2wQimQi
lspci -k: https://pastebin.com/qd0vcLZd
glxinfo -B: https://pastebin.com/0PLkbh8b
clinfo: https://pastebin.com/pFw0VJ0J
vk_pro progl clinfo: https://pastebin.com/w1rtdcav
vk_pro progl glxinfo -B hangs after a single line of output:
name of display: :0
Offline
Please don't use pastebin.com , see the first colored box in the wiki link I posted in #6 for details.
remove intel-oneapi-compiler-shared-runtime , try again .
If that is not enough, also remove opencl-rusticl-mesa & lib32-opencl-rusticl-mesa .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Please don't use pastebin.com , see the first colored box in the wiki link I posted in #6 for details.
remove intel-oneapi-compiler-shared-runtime , try again .
If that is not enough, also remove opencl-rusticl-mesa & lib32-opencl-rusticl-mesa .
Resolve bugs persevere after removal of all three packages. Here are the new outputs of commands:
pacman -Qs opencl: https://0x0.st/XR_Z.txt
lspci -k: https://0x0.st/XR_P.txt
glxinfo -B: https://0x0.st/XR_K.txt
clinfo: https://0x0.st/XR_H.txt
vk_pro progl clinfo: https://0x0.st/XR_N.txt
vk_pro progl glxinfo -B is still broken.
Offline
No need to repost those outputs unless being asked (clinfo was useful) .
clinfo now shows 2 devices, a gfx803 supporting OpenCL 1.2 and ellesmere supporting OpenCL 2.0 .
Both should be usable by DR .
I'm not familiar with ocl-icd-choose, DR should be able to detect your opencl drivers correctly without needing it .
Remove it , then start & close DR again .
Post fresh ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
No need to repost those outputs unless being asked (clinfo was useful) .
clinfo now shows 2 devices, a gfx803 supporting OpenCL 1.2 and ellesmere supporting OpenCL 2.0 .
Both should be usable by DR .I'm not familiar with ocl-icd-choose, DR should be able to detect your opencl drivers correctly without needing it .
Remove it , then start & close DR again .
Post fresh ~/.local/share/DaVinciResolve/logs/ResolveDebug.txt
Fresh logs:
when launched with vk_pro progl: http://0x0.st/XRyT.txt
And without: https://0x0.st/XRya.txt
The issue still persists on 6.12.1.
Offline
Ok, we simplified things until just DR & opencl-amd should be involved.
remove opencl-amd, install opencl-rusticl-mesa .
run clinfo --list , it should only list one device .
start & close DR, post the log .
Edited for clarity
Last edited by Lone_Wolf (2024-11-30 10:19:28)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Ok, we simplified things until just DR & opencl-amd should be involved.
remove opencl-amd, install opencl-rusticl-mesa .
run clinfo --list , it should only list one device .
start & close DR, post the log .Edited for clarity
clinfo --list:
Platform #0: rusticl
Full clinfo output: http://0x0.st/XR6Y.txt
ResolveDebug: http://0x0.st/XR6E.txt
No GPU detected, screenshots:
Same with the LTS kernel.
Offline
oops, forgot rusticl requires explicit enabling for many cards..
prepend RUSTICL_ENABLE=radeonsi to the commands .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
oops, forgot rusticl requires explicit enabling for many cards..
prepend RUSTICL_ENABLE=radeonsi to the commands .
This worked, allowing me to launch the project whilst opencl-amd was removed from the system: http://0x0.st/XR5C.txt
When opencl-amd is installed, the project won't load even with the RUSTICL_ENABLE key, which is quite strange: http://0x0.st/XRRz.txt
Upd1: In the second case, I can open an empty project and choose one of the two GPU (see the screenshot: https://imgur.com/PBc18Lf ), but neither works.
The performance of rusticl is still sub-par to opencl-amd which was the main reason I went with the latter initially.
Last edited by Vladar (2024-12-01 10:10:54)
Offline
The performance of rusticl is still sub-par to opencl-amd which was the main reason I went with the latter initially.
That's what I expected, but we now know that DR functions with rusticl and the problem is with the opencl-amd package itself.
Where does your opencl-amd package come from : pacman cache, archlinux archive, built from source using a PKGBUILD etc ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
The performance of rusticl is still sub-par to opencl-amd which was the main reason I went with the latter initially.
That's what I expected, but we now know that DR functions with rusticl and the problem is with the opencl-amd package itself.
Where does your opencl-amd package come from : pacman cache, archlinux archive, built from source using a PKGBUILD etc ?
I downloaded a tar.gz from this AUR page https://aur.archlinux.org/cgit/aur.git/ … e05b043041 (latest version working with RX 5xx according to https://aur.archlinux.org/packages/open … ent-949758 ) and built it with makepkg.
Offline
Have you tried rebuilding that version of opencl-amd ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Have you tried rebuilding that version of opencl-amd ?
Did it just now, same results as before:
Running with vk_pro progl: http://0x0.st/X7cb.txt
Running with RUSTICL_ENABLE=radeonsi: http://0x0.st/X7cc.txt
On the LTS kernel, the newly compiled opencl-amd works fine.
Offline
For clarity : downgrading only the kernel to lts 6.6.x is enough ?
That atleast gives a workaround.
Note that the next lts kernel will very likely be 6.12 , so in 2 or 3 months 6.6 will be dropped from repos.
Usually someone picks up the package and maintains an aur package for it, but it will mean you have to build that yourself.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
For clarity : downgrading only the kernel to lts 6.6.x is enough ?
Correct. I have both kernels installed on an up-to-date system, working on LTS 6.6.63, and reloading to 6.12.1 for testing.
Last edited by Vladar (2024-12-03 10:33:32)
Offline
Could you also check if the latest release candidate maybe fixes your issue?
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.13rc1-1-x86_64.pkg.tar.zst
Note that you'll need to setup your bootloader to recognize this new kernel (by writing a new system-boot loader entry or by running "grub-mkconfig -o ..") and also maybe verify that you booted the right one by running "uname -r" from the booted session (output should be "6.13.0-rc1-1-mainline").
Offline
Could you also check if the latest release candidate maybe fixes your issue?
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.13rc1-1-x86_64.pkg.tar.zst
Note that you'll need to setup your bootloader to recognize this new kernel (by writing a new system-boot loader entry or by running "grub-mkconfig -o ..") and also maybe verify that you booted the right one by running "uname -r" from the booted session (output should be "6.13.0-rc1-1-mainline").
The same result as for the 6.12.1, still broken.
Offline
same problem.
also have intel+rx580 and all amd drivers version same.
Offline
Would you be willing to test kernel packages so we can bisect which commit causes the issue?
Offline