Did something change inside the nightly build of Diffuse or Sharpen module?

Software darktable
28

And now there’s Mask manager is broken in master · Issue #13119 · darktable-org/darktable · GitHub

29

Yes indeed - but no criticism of dev team is intended. Stuff happens, and I am eternally grateful that it gets fixed so promptly!

30 
couldn't enqueue kernel! CL_INVALID_KERNEL_ARGS

That’s a different error, I think.

31

While the debug options are turned on, here is another group of errors that are showing up on images where I have simply applied my standard style:

[dt_ioppr_check_duplicate_iop_order] modules denoiseprofile (9) and denoiseprofile (9) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules exposure (22) and exposure (22) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules channelmixerrgb (31) and channelmixerrgb (31) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules diffuse (32) and diffuse AA Filter(32) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules colorbalancergb (52) and colorbalancergb (52) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules filmicrgb (58) and filmicrgb (58) have the same iop_order
[dt_ioppr_check_iop_order] module denoiseprofile (0)(9) and denoiseprofile (0)(9) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module exposure (0)(22) and exposure (0)(22) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module channelmixerrgb (0)(31) and channelmixerrgb (0)(31) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module diffuse AA Filter(0)(32) and diffuse (0)(32) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module colorbalancergb (0)(52) and colorbalancergb (0)(52) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module filmicrgb (0)(58) and filmicrgb (0)(58) have the same order image 0 (dt_dev_pop_history_items_ext end)

32

I managed to narrow it down to a minimal XMP. Can be reproduced using other raw files, too.
DSC_9619_01.NEF.xmp (6.4 KB)

(It’s based on ER6_3846.CR3.xmp from Did something change inside the nightly build of Diffuse or Sharpen module? - #9 by Aliks, but I applied it to a different raw, just to double-check.)

Update: Masking: couldn't enqueue kernel! CL_INVALID_KERNEL_ARGS · Issue #13120 · darktable-org/darktable · GitHub

2 Likes
33

@Aliks, which NVidia driver do you use? And are you on Linux?

34

Linux Mint 20.3 ; NVIDIA GeForce RTX 3060/PCIe/SSE2 v: 4.6.0 NVIDIA 510.108.03

35

Thanks. I recently upgraded to driver 525. Will try reverting to 470, which I’d used before that.

36

520 is running stable here.

37

All: the issue has been fixed, and the fix is available on master (Fixing #13120 by jenshannoschwalm · Pull Request #13124 · darktable-org/darktable · GitHub). Thanks, @hannoschwalm, @dterrahe & @Pascal_Obry !

38

Thanks everyone! Umm… I had a look on github but it went over my head. Just curious might this be related to the issues I had when I was fiddling with OpenCL?

39

Did you settle on a config for OpenCL??

40

I believe it had nothing to do with configuration, rather with the way parameters were passed to the processing OpenCL code.

41

Yes, basically the defaults work well! But as long as I don’t use openCL tuning I don’t have any probs. I did have resources set to large previously, I might go back to that. I need to check if it makes a difference (now that I know how😀)

42

Try the new build to see if improved your issue. Im not sure it will.

43

Will do! Might be in a day or two though… A bit busy atm

44

I still get :

[opencl_lock_device] reached opencl_mandatory_timeout trying to lock mandatory device, fallback to CPU

even with the new build. Haven’t seen any performance hit though

45

If there are no other errors, and you see this while working in the darkroom, this can be the consequence of what is discussed here:

46

Ok I think I understand now.

With a very fast GPU that you want to use for intensive DorS iterations, probably best to set the timeout high (600 seems to work for me)

But one more question, where do you set the dt_opencl_update_priorities to find out if my fast GPU makes any difference for preview, thumbs or preview2?

in my config file , I have

opencl_device_priority=/!0,///!0,*

in the log file
dt_opencl_update_priorities] show if opencl use is mandatory for a given pixelpipe:
[dt_opencl_update_priorities] image preview export thumbs preview2
[dt_opencl_update_priorities] 1 1 1 1 1

47

I think that’s good. Now you can make measurements. :slight_smile:

1 Like