Complete System failure running darktable and OpenCL (Intel)

[marcsitkin]

Hi-
On two occasions now I have had fatal crashes that required me to reinstall my Aurora system.
In both cases, I was using the AppImage of Darktable in conjunction with the Intel Opencl drivers (layered). Darktable was launched using the Gear Lever application. The crashes started with a freeze while moving a slider in a processing
prevent darktable from creating superblocks out of alignment while using opencl - Google Search.pdf
module. After a few minutes waiting, I rebooted the system and got error messages relating to superblocks being out of alignment.

I posted on the pixls.us website, and was told it was related to darktables repeated writing to disk with every move of a slider.
Running without OpenCL enabled has not resulted in any further occurrences, but this is far from ideal.

I posed the question on Google Gemini, and received about 20 pages of suggestions, and starting on page 11 of the (attached) document, some recommendations specific to Arch are given.

A couple caught my attention, and I wanted to run them by someone with more knowledge than me:

You can adjust how Aurora mounts your root partition. Because Aurora uses an immutable deployment model, you should configure user mount arguments via ujust if available, or manually adjust your /etc/fstab to decrease the commit window and enable synchronous writing:
UUID=your-nvme-uuid / btrfs subvol=root,compress=zstd:1,commit=5,flushoncommit 0 0

3. Throttle Slider Processing InternallyWhen you drag a slider in darktable, it tries to re-render the image preview continuously at full resolution for every single pixel shift. Forcing this rapid re-allocation onto the Intel compute pipeline is what triggers the hard crash. You can force darktable to wait until you finish moving the slider before it renders:Open ~/.config/darktable/darktablerc.Add or modify the following line:inislider_interaction_processing_delay=250

Another possibility is to run in a container:

4. Isolate Intel OpenCL in a Toolbx / DistroboxIf you absolutely must use OpenCL down the line for performance reasons, do not use the default host driver configuration. Because Aurora heavily leans on containerized developer tools, run darktable inside an isolated distrobox container:Create a container environment: distrobox create -n darktable-sandbox --image fedora:44Enter the box: distrobox enter darktable-sandboxInstall a specific, older version of the Intel Compute Runtime inside the container that doesn't trigger the Kernel 7.0 driver crash. If the app crashes inside the sandbox, it will kill the container process instead of locking your native kernel and ruining your NVMe drive blocks.

Any thoughts on how to proceed?

[renner0e]

On two occasions now I have had fatal crashes that required me to reinstall my Aurora system.

That is very hard to believe that only reinstall would help you.

You can adjust how Aurora mounts your root partition. Because Aurora uses an immutable deployment model, you should configure user mount arguments via ujust if available

No, that is no true. You use the tools that are well documented and understood, fstab -> which generates systemd mount units.

adjust your /etc/fstab to decrease the commit window and enable synchronous writing: UUID=your-nvme-uuid / btrfs subvol=root,compress=zstd:1,commit=5,flushoncommit 0 0

That won't work, see this blog post, use rpm-ostree kargs --editor to adjust this.

I am not familiar with OpenCL or darktable, so beyond that I can't help you.

EDIT: looking at this again, why are you not using the flatpak of darktable? flathub/org.darktable.Darktable#158 (comment)

[marcsitkin]

Hi- Believe it, it's true that the system bricks. I tried the cli tools for dealing with mis-aligned superblocks, and couldn't get going again. I've had this happen 3 times on Aurora, and as a sanity check, installed Fedora 44 and had the same issue.

I've since reinstalled Aurora, but swapped out my Intel Arc B580 for an AMD Radeon RX 7600. I had a long test session Sunday, and another yesterday, and have not had the same issue. It seems like much there is much less use of the CPU and more of the GPU with this combination.

I've run Aurora with Darktable without OpenCL, and not had any issues under the old Intel GPU. Darktable was the only program that gave me issues. As a side note, I've run Aurora on my laptop pc for almost 2 years, on an old Dell PC for 18 months, and my wife runs Bluefin on her Sys76 Lemur Pro. No issues to speak of, so I KNOW how solid the system you guys publish is.

The reason for choosing the AppImage is that it's the only official version of Darktable available on Linux, and my understanding is that the Flatpak is compiled with support only for Nvidia OpenCL, the updates to the Fedora RPM's are slow to come, and the Open Suse Build versions of the RPM is missing key features. I did set up a container and run that RPM, but still bricked the machine. I've compiled my own in the past, but it's something I'd rather not do.

Thanks for taking a look, hopefully this hardware change will work for the best.

[renner0e]

Hi- Believe it, it's true that the system bricks. I tried the cli tools for dealing with mis-aligned superblocks, and couldn't get going again. I've had this happen 3 times on Aurora, and as a sanity check, installed Fedora 44 and had the same issue.

you should report this to darktable if you want things to get better for everyone. Especially when you could reliably reproduce it three times.

Flatpak is compiled with support only for Nvidia OpenCL

have you looked for open issues about this? Seems like this whole thing is a mess.

These issues you are experiencing are not something that are really actionable for us to fix, we purposefully are not in the "application packaging business" and leave that up to flathub 😄