(Solved) darktable 3.6.1 lost OpenCl functionality while exporting images. How to recover?

Working with a new clean install of Mint 20.2 on a newly acquired PC, equipped with nVidia GTX 1050 (2GB model), I was running fine, for some days, importing (“add to library”) all the images from my predecessor Mint 20.2 PC (still running), and then exporting some jpegs. While exporting some new raw images I was presented - for about half a second - with an error message suggesting that a problem had been found with OpenCL, but what that problem was was not revealed. I realised that OpenCL was no longer working because the processor fan immediately began to run faster.

I have read chapters 10.2.3 and 10.2.4 multiple times but feel a bit like a seamstress being given the manual to solve a problem with a dead LHC: I know how to read but have no idea how to do problem source identification or problem resolution. The fact that the system ran without problem for some days suggests to me that all the requirements mentioned in chapter 10.2.4 are satisfied - I can certainly find libOpenCL.so, libnvidia-opencl.so.1 which is a SymLink to libnvidia-opencl.so.470.74; the contents of etc/OpenCL/vendors/nvidia.ICD seems to be correct;; lsmod output lists nvidia, nvidia_uvm, nvidia_drm and nvidia_modeset. I’m running kernel 5.4.0-89.

I’m quite satisfied that earlier reports, in this forum, of this version of dt (3.6.0) not providing OpenCL support for the nVidia GTX 1050 Ti do not apply here - because it was working just fine for some days. It might not be relevant, but my Windows install of 3.6.0.1 runs with the same GPU without problem and has done so since 3.6.0 was released.

I have tried running darktable from the command line but I immediately get an error telling me that command darktable is not found but can be installed with ‘sudo apt install darktable’. This fails with the error ‘Unable to locate package darktable’. I am running the Flatpak version of 3.6.1.

Any advice on how I should proceed from here (and yes, I have turned the PC off and on again !) ?

(23 Oct) Bottom line is that reverting to the OSB version 3.6.1-1.1, as advised by others, fixed the problem. Cause of failure when using the Flatpak version not known, but assumed to be ‘user error’ of some sort.

Were you running darktable, and at anytime put your system into suspend mode at anytime without exiting darktable? I find that can be enough for open CL to get disabled.

One other option rather than using the flatpack version of darktable, try installing the build for Ubuntu 20.04 available from the opensuse obs wesite:

https://software.opensuse.org/download.html?project=graphics:darktable&package=darktable

Select the ubuntu 20.04 version as that is what mint is based on

Yes, I did that frequently, particularly on the ‘old’ install, because Mint seems to be able to run for months without requiring a restart, other than for some kernel updates (in contrast I find I am restarting Windows every few days on average).

Having found a possible explanation, how do I recover? Perhaps it is, as you suggest in another post, an issue with the Flatpak version of dt. But if that is the case, what has the build of the Flatpak version changed in dt, such that OpenCL cannot be enabled - given that all the ‘external’ requirements are satisfied (in my uninformed opinion)?

OK, I’ll give that a try - but can I retain all the customisations I have done in darktable preferences, especially the presets?

you can manually copy the preferences and presets over.
Flatpak app config and presets for Darktable should exist in:
/home/USERNAME/.var/app/org.darktable.Darktable/config/darktable

While the deb installation config files would be in:
/home/USERNAME/.config/darktable/

Ah, thanks for this - yes I can see the Flatpak stuff - should I replace the (yet to be created) DEB install with all these files:
darktablerc
data.db
keyboardrc
library.db

Which of these contain my own presets - for example that for lens correction?

Screenshot from 2021-10-23 16-11-54
There should be a subfolder called “styles” and your presets should live in there.

specifically, data.db contains the module presets
Always make a backup of everything first. If there is a big change in the version, you might get an error on loading, and it will want to create a new library file. I get this when there is a new release, but not sure what happens when you are downgrading. A recent version config file might have incompatabilities with an older version.

For my system, Flatpak is on version 3.6 while the deb is on 3.4

Thank you for taking the time to inform me with the excellent screenshot and the further clarification. Yes, I have found that the ‘styles’ folder does not contain the lens correction preset.

My ‘downgrade’ plan is to install 3.6.0 DEB from the OSB without removing the Flatpak version, on the basis that they store their key files in different places. The files for the DEB version will not be important, but I will back them up before overwriting them with the Flatpak 3.6.1 version and hope that the cause of the loss of OpenCL functionality is not within the Flatpak config files, but is in the executable code.

In the worst case, I’ll just have to import all my images againand hope the .xml files are un-corrupted and also do not contain data that will cause an OpenCL issue.

Have I forgotten/mis-assumed anything major ?

btw I could see no good reason to stay on 3.4 once I had sampled the greater functionality, especially in import, in 3.6.

yeah you can run both at the same time. I simply just copy the folder over from one install to the other .

Thanks for the assurance and support. ‘Belt and braces’ worn, ‘downgrade’ to the OSB DEB version complete, dt running with OpenCL enabled on first attempt, with presets in place too.

Good initial result

2 Likes

The OSB version should be 3.6.1? For mint users select the package for Ubuntu 20.04 based distro.

It’s certainly 3.6.1 I am running on my mint 20 machine, which I downloaded from obs site.

Yes, that is exactly the version that I installed earlier today, in spite of my inability to correctly spell OBS (I played all the right notes, but not necessarily in the right order…). No problems with enabling OpenCL

1 Like

Excellent news @LateJunction :slight_smile: Maybe the flatpack version has issues with OpenCL since it is “containerised”?

Flatpak only works with nvidia cards for openCL. You need an additional flatpak package that contains the nvidia driver.

if you go to the terminal and run
flatpak run org.darktable.Darktable -d opencl
You will get some output about what Flatpak darktable is doing with opencl.

Could I ask for a little more guidance on which Flatpak package you are suggesting ?

You need org.freedesktop.Platform.GL.nvidia

I would like to follow up on this:
Having noted your comment on problems with OpenCL availability after suspending Mint 20.2 when using the Flatpak version of dt, I made sure of closing dt before suspending Mint, even though I am now using the OBS version (3.6.1-1.1) of dt. Finding this to somewhat defeat the purpose of ‘suspend’, I tried it without closing dt first; result: OpenCL availability stull gets broken over a ‘suspend/resume’ cycle on both my Mint 20.2 installs when using the OBS version of 3.6.1.

I cannot tell if this is a problem with the hardware, chosen BIOS settings, nVidia drivers, Mint (Cinnamon) , dt or me (it’s usually me…). Should I submit a bug report? Nobody seems to have done so, when I examine the Issues register on Github. I find this remarkable - I guess that the majority of dt users run the Linux version, and Mint is probably in the top 3 distros used by dt users - so it can’t just be me, surely?

1 Like