If you only get that message after the error, I’d assume it’s genuine. However…
If you are processing multiple pipelines (for example, the darkroom uses one for the top-left small preview, and one for the editor area), darktable will try to work on them in parallel.
The GPU will start working on a module, in one of the pipelines. If GPU processing is mandatory (e.g., when using the very fast GPU scheduling profile, or using the default scheduling profile with an appropriately configured priority string), the 2nd pipeline will:
- first wait for the GPU to become available (see opencl_mandatory_timeout in
darktablerc- the default value is 400, the unit is 5 ms). - if the timeout (400 * 5 ms = 2 s) expires, and the GPU is still busy, it’ll fall back to the CPU path. This is when you see
reached opencl_mandatory_timeout trying to lock mandatory device, fallback to CPUin the log, if you have OpenCL debug logging enabled.
In some cases (e.g., when you are processing large files with heavy modules, like diffuse or sharpen or highlight reconstruction with guided laplacians), a timeout will occur even if everything is OK.
Now, if your GPU is faster than your CPU (which is usually the case), this may be detrimental:
- 2nd pipeline waits for 2 seconds
- starts processing on the CPU, let’s say 20 seconds
- total time is 22 seconds
- if it waited, and got the GPU after, say, 5 seconds, and then took 5 seconds to process the module on the GPU, the total time would have been 10 seconds.
So, you may want to increase that timeout significantly. It will either cause a hang (in that case, simply back out the change), or, possibly, a speed-up (like it did for me - OpenCL is mandatory, yet CPU is used (solved) - #4 by kofa).