Opencl working for a specific module

PD1 · October 21, 2025, 8:23am

I may have missed it. How do I check if OpenCL is working for a specific processing module?

the command -d opencl shows the opencl is loaded, but doesn’t seem to show if it is working for a specific module

kofa · October 21, 2025, 8:48am

You may want to also add -d perf. You’ll see lines like:

    23.9197 [dev_pixelpipe] took 0.006 secs (0.007 CPU) [full] processed `filmicrgb' on GPU, blended on GPU
    23.9602 [dt_ioppr_transform_image_colorspace] IOP_CS_RGB-->IOP_CS_LAB took 0.005 secs (0.053 CPU) [colorout]
    24.0420 [dev_pixelpipe] took 0.122 secs (0.852 CPU) [full] processed `colorout' on CPU, blended on CPU

Check:

processed `name of module' on GPU

vs

processed `name of module' on CPU

PD1 · October 21, 2025, 10:57am

Thanks

Popanz · October 21, 2025, 12:02pm

By the way, is there a way to disable OpenCL just for one specific module?

The Liquify module is producing artefacts with my RustiCL environment.
I had this with my old graphic card as well with the new one. Using the AMD OpenCL version together with the free drivers worked with the old card. But I can’t get my new one to work with it.
I didn’t try too hard to be honest, because I prefer RustiCL in the end.

PD1 · October 21, 2025, 12:07pm

This is a very important question, needing an answer. I have the artifact problem with haze removal module while using OpenCL, to the extent I have stopped using it and depend upon other modules for the work

My OpenCL implementation is on Windows/Intel XEGraphics GPU

kofa · October 21, 2025, 1:33pm

There is a hackish way, yes: delete the corresponding kernel.
On Windows:
C:\Users\my-user\AppData\Local\Programs\darktable\share\darktable\kernels (or wherever your installation directory is; on this machine, it’s at C:\Users\my-user\AppData\Local\Programs\darktable

Try to guess the name. For modern modules, it’s usually simple; for very old ones, it’s sometimes more difficult, e.g. atrous.cl for contrast equalizer.

Delete the cache directory of compiled kernels (I don’t have OpenCL on this Windows laptop).

Less guessing: open darktable/src/iop at master · darktable-org/darktable · GitHub, click on the search icon on the top right (ignore the one on the left):

For the search expression, enter the following, replacing contrast equalizer with whatever you are looking for:

return _("contrast equalizer")

Use the name of the module, but with a .cl extension to locate the OpenCL implementation in C:\Users\my-user\AppData\Local\Programs\darktable\share\darktable\kernels:

Happy deleting! And please, raise a bug report, so it can be fixed!

Popanz · October 21, 2025, 2:17pm

I’m on Linux. Guess it should be the same way.
Anyway I use Liquify quite seldom. So maybe it’s easier to just deactivate OpenCL in this cases or use GIMP instead.

Anyway, I have opened a bug report on Github now.

Edit:
On my machine it is in
/usr/share/darktable/kernels
I renamed
liquify.cl to liquify.cl.bak

Now I have no artefacts anymore. But who will remind me to rename it when the bug is ironed out. Don’t know if this is a good way.

Probably the cache solution is the better one. Thanx @kofa

kofa · October 21, 2025, 2:48pm

Under Linux:
rm -rf ~/.cache/darktable/*kernel*

That removes the card-specific, compiled versions; they will be recreated the next time you start darktable (except for the one where you removed the whatever.cl source file).

Darktable will complain a bit on the console, but will proceed.

Popanz · October 21, 2025, 3:09pm

Tried the removing of the kernel from cache. But this for some reason doesn’t have the effect, that the artefacts disappear. Anyway don’t think more about it. It’s not worth.

kofa · October 21, 2025, 3:14pm

Have you used -d opencl -d perf to make sure no OpenCL is used for that module? Or, after removing the cache, darktable-cltest? That also rebuilds the kernels.

Popanz · October 21, 2025, 3:17pm

No I just controlled that the files in cache are gone and they were.
But as I said, it’s not worth to think further about it. Let’s see, if the bug report will help on the longer sight.

kofa · October 21, 2025, 3:20pm

And after a restart, are the compiled modules back, including / without the one you deleted?

Popanz · October 21, 2025, 3:25pm

After a restart they are there again

kofa · October 21, 2025, 3:38pm

Including the one whose .cl file you removed? Because, in that case, it wasn’t removed from the right place.

kofa · October 21, 2025, 3:56pm

You’ll need -d opencl -d verbose to see what files are compiled. Note the lines:

KERNEL BUILD DIRECTORY: /home/kofa/darktable-master/share/darktable/kernels – this is where the .cl files are, that’s where you’ll have to delete whatever.cl
KERNEL DIRECTORY: /home/kofa/.cache/darktable/cached_v5_kernels_for_NVIDIACUDANVIDIAGeForceGTX10606GB_57017208 – this is where the compiled versions are placed.

An example:

kofa@eagle:~$ rm -rf .cache/darktable/*kernel*
kofa@eagle:~$ darktable -d opencl -d verbose
darktable 5.3.0+623~g2288d1921c
Copyright (C) 2012-2025 Johannes Hanika and other contributors.

Compile options:
  Bit depth              -> 64 bit
  ...

     0.0001 [dt starting]
 /home/kofa/darktable-master/bin/darktable -d opencl -d verbose
     1.0007 [dt_dlopencl_init] found default opencl runtime library 'libOpenCL'
     1.0007 [opencl_init] opencl library 'libOpenCL' found on your system and loaded, preference 'default path'
     1.0144 [opencl_init] found 1 platform
[opencl_init] found 1 device

[dt_opencl_device_init]
     1.0145 [dt_opencl_write_device_config] writing data '0 250 0 16 16 0 0 0 0.000 0.000 0.250' for 'cldevice_v5_nvidiacudanvidiageforcegtx10606gb'
     1.0145 [dt_opencl_write_device_config] writing data '600' for 'cldevice_v5_nvidiacudanvidiageforcegtx10606gb_id0'
   DEVICE:                   0: 'NVIDIA GeForce GTX 1060 6GB'
   ...
   DEFAULT DEVICE:           NO
   KERNEL BUILD DIRECTORY:   /home/kofa/darktable-master/share/darktable/kernels
   KERNEL DIRECTORY:         /home/kofa/.cache/darktable/cached_v5_kernels_for_NVIDIACUDANVIDIAGeForceGTX10606GB_57017208
   CL COMPILER OPTION:       -cl-fast-relaxed-math
   CL COMPILER COMMAND:      -w -cl-fast-relaxed-math -DNVIDIA_SM_20=1 -DNVIDIA=1 -I"/home/kofa/darktable-master/share/darktable/kernels"
   CL EXCEPTION:             DT_OPENCL_ONLY_CUDA
     1.0867 [dt_opencl_device_init] testing program `demosaic_ppg.cl' ..
     1.0868 [opencl_fopen_stat] could not open file `/home/kofa/.cache/darktable/cached_v5_kernels_for_NVIDIACUDANVIDIAGeForceGTX10606GB_57017208/demosaic_ppg.cl.bin'!
     1.0868 [opencl_load_program] could not load cached binary program, trying to compile source

     1.0868 [opencl_load_program] successfully loaded program from '/home/kofa/darktable-master/share/darktable/kernels/demosaic_ppg.cl' MD5: '009046903d9803f1d35da113eb1be20a'
     1.0914 [opencl_build_program] successfully built program
     1.0914 [opencl_build_program] BUILD STATUS: 0
     1.0914 BUILD LOG:
     1.0914 

     1.0914 [opencl_build_program] saving binary
     1.0916 [dt_opencl_device_init] testing program `atrous.cl' ..
     ...

     1.1795 [opencl_build_program] saving binary
     1.1795 [dt_opencl_device_init] testing program `agx.cl' ..
     1.1796 [opencl_fopen_stat] could not open file `/home/kofa/.cache/darktable/cached_v5_kernels_for_NVIDIACUDANVIDIAGeForceGTX10606GB_57017208/agx.cl.bin'!
     1.1796 [opencl_load_program] could not load cached binary program, trying to compile source

     1.1796 [opencl_load_program] successfully loaded program from '/home/kofa/darktable-master/share/darktable/kernels/agx.cl' MD5: 'ff837a5eff47ba8a8cb0a12208a7c1d8'
     1.1815 [opencl_build_program] successfully built program
     1.1815 [opencl_build_program] BUILD STATUS: 0
     1.1815 BUILD LOG:
     1.1815 

     1.1815 [opencl_build_program] saving binary
   KERNEL LOADING TIME:       0.0948 sec
     1.1815 [dt_opencl_write_device_config] writing data '0 250 0 16 16 0 0 0 0.000 0.000 0.250' for 'cldevice_v5_nvidiacudanvidiageforcegtx10606gb'
     1.1815 [dt_opencl_write_device_config] writing data '600' for 'cldevice_v5_nvidiacudanvidiageforcegtx10606gb_id0'
[opencl_init] OpenCL successfully initialized. internal numbers and names of available devices:
...

If I now quit darktable and temporarily move agx.cl:

kofa@eagle:~$ rm -rf .cache/darktable/*kernel*
kofa@eagle:~$ mv /home/kofa/darktable-master/share/darktable/kernels/agx.cl /tmp
kofa@eagle:~$ darktable -d opencl -d verbose
...
     1.1876 [opencl_load_program] successfully loaded program from '/home/kofa/darktable-master/share/darktable/kernels/capture.cl' MD5: '26d8f693ccf531f467914546457ca9ff'
     1.1889 [opencl_build_program] successfully built program
     1.1889 [opencl_build_program] BUILD STATUS: 0
     1.1889 BUILD LOG:
     1.1889 

     1.1889 [opencl_build_program] saving binary
     1.1890 [dt_opencl_device_init] testing program `agx.cl' ..
     1.1890 [opencl_fopen_stat] could not open file `/home/kofa/darktable-master/share/darktable/kernels/agx.cl'!
   KERNEL LOADING TIME:       0.0916 sec
     1.1890 [dt_opencl_write_device_config] writing data '0 250 0 16 16 0 0 0 0.000 0.000 0.250' for 'cldevice_v5_nvidiacudanvidiageforcegtx10606gb'
     1.1890 [dt_opencl_write_device_config] writing data '600' for 'cldevice_v5_nvidiacudanvidiageforcegtx10606gb_id0'
[opencl_init] OpenCL successfully initialized. internal numbers and names of available devices:
[opencl_init]           0       'NVIDIA CUDA NVIDIA GeForce GTX 1060 6GB'
     1.1890 [opencl_init] FINALLY: opencl PREFERENCE=ON is AVAILABLE and ENABLED.
[opencl_init] opencl_scheduling_profile: 'very fast GPU'

You’ll notice:

     1.1890 [opencl_fopen_stat] could not open file `/home/kofa/darktable-master/share/darktable/kernels/agx.cl'!

But still, overall, OpenCL is working:

[opencl_init] OpenCL successfully initialized.

Popanz · October 21, 2025, 4:03pm

Ok, before we talk of different things:

I started darktable
I started terminal and executed
rm -rf ~/.cache/darktable/*kernel*/*liquify.cl*
afterwards I searched in this directory for liquify.cl and found nothing
I closed darktable
I started darktable and searched in cache for liquify.cl and found liquify.cl.bin
in
cached_v5_kernels_for_rusticlAMDRadeonRX9070XT_25251/
and
cached_v5_kernels_for_rusticlAMDRadeonGraphics_25251/
which is a symlink pointing to some cryptical named files:
reading like 44933aa115d38cb57360d785a2ce465d in the same folder

Popanz · October 21, 2025, 4:08pm

I think I will make a small script which renames the original kernel file in /usr/share/darktable/kernels
to toggle between enabled and disabled and make a entry for it in the start menu.

Popanz · October 21, 2025, 4:09pm

Just looked at your description. And it seems like I got you wrong in the beginning. WIll try again.

kofa · October 21, 2025, 4:53pm

Yes, the cl files (the device-independent OpenCL kernel sources) are not in the cache; only the compiled, card-specific files are. You have to remove the .cl file to prevent it being recompiled and used.

Popanz · October 21, 2025, 4:56pm

Yes but I did it initially the right way I think. You have a local user install if I understand it right. I have a system wide install the cl files are in
/usr/share/darktable/kernels
But then I don’t need to move anything around. renaming
liquify.cl to liquify.cl.bak
is enough. Darktable still starts and the other modules still run with OpenCL support.