Note - everything was working just fine before I went away on 7th November
Nothing change on that module but many performances had been added by @hannoschwalm and maybe there’s some cases where performance falls. I can’t reproduce on my side your issue and use daily master. Not sure but your issue could be related to that one: Bug module Surface Blur on Darktable 4.1.0~git1190.39d46ffa-1 · Issue #13109 · darktable-org/darktable · GitHub (of course, it’s not same module but such issue is probably not related to module but the fact that those modules are those who need more resources than many others).
I’m still trying to track down the event that causes the problem with OpenCL.
I can take an image and use all the modules click by click, including the Diffuse or Sharpen presets, and masking, and there is no problem.
However some of my saved styles and presets do cause the problem, unclear what the difference can be.
Can you post a raw and XMP that trigger the problem?
-d tiling an -d perf might be useful. And what version of Nvidia drivers and what OS.
Raw image is mine and free of all ridiculous usage licences - anyone can use it for any purpose
ER6_3846.CR3 (12.7 MB)
ER6_3846.CR3.xmp (10.8 KB)
OS is latest linux mint, latest Nvidia drivers, but i think the problem is something to do with saving presets or shortcuts
I don’t understand this, but I’ll try to reproduce the issue once I’m home.
Using Windows and 4.1+1185 from the other day… no issues… also tried my own presets and even ones invoking a mask and they seem snappy enable and disable results in an almost instant screen update…
If you just switched to this build, delete darktables opencl kernel cache and have dt rebuild the opencl kernels
I use the following to delete kernels:
rm -rf ~/.cache/darktable/cached_kernels*
Does that clear the opencl kernels?
Well I did a lot of exploring, and could easily reproduce the issue with a number of images.
I tried starting right from the beginning with an image, setting up the usual modules and then adding 3 instances of Diffuse and Sharpen for Local Contrast; AA Filter; Deblur (Hard) all masked onto a small part of the photo. None of these triggered any issues, even though I had 50 iterations on deblur.
I then Ctrl-C copied to another photo, Ctrl-Shift-V pasting to retain the mask, and get these kind of messages:
[opencl_lock_device] reached opencl_mandatory_timeout trying to lock mandatory device, fallback to CPU
I see there were some discussions on this kind of issue back in January (issues/10828)
If I fiddle around with the image a bit, I can get these kind of error messages:
unknown mask mode ‘0’ in module ‘diffuse’
[dt_ioppr_check_iop_order] gamma is not the last iop, last is diffuse Deblur Hard(34) image 0 (dt_dev_modules_update_multishow)
[dt_ioppr_check_iop_order] module diffuse AA Filter(33) should be after gamma (92) image 0 (dt_dev_modules_update_multishow)
[dt_ioppr_get_iop_order_after_iop] can’t find module previous to diffuse Deblur Hard(34) while moving diffuse AA Filter(33) after it
[dt_ioppr_check_iop_order] gamma is not the last iop, last is diffuse LocCont(37) image 0 (dt_dev_modules_update_multishow)
[dt_ioppr_check_iop_order] module diffuse AA Filter(33) should be after gamma (92) image 0 (dt_dev_modules_update_multishow)
673.102930 [dt_opencl_enqueue_kernel_2d_with_local] kernel 24 on device 0: CL_INVALID_KERNEL_ARGS
673.103829 [opencl_blendop] couldn’t enqueue kernel! CL_INVALID_KERNEL_ARGS
673.103834 [opencl_pixelpipe] [full] could not run module `diffuse’ on gpu. falling back to cpu path
Is it just that I am overloading with too many iterations and instances?
Are you perhaps appending to an old xmp so you create a hybrid of something old and new and then it can’t be processed or has issues?? I was not clear if you paste was to a new image or one processed in the future??
As far as I know the target image is untouched by me, but of course an XMP is created on import into DT.
Either way, I thought copying to an image overwrote the previous XMP rather than merging.
Yes it should
There are two modes append and overwrite…
Yes, when used in lighttable, but in darkroom mode Ctrl-V is always overwrite ( I think)
No I think not but I could be wrong…It is actually one of the things that I thought about requesting was to have the option to select the mode… But I think it follows what you set in lightroom…
EDIT confirmed at least on my version and all those I have used in the past…
If you are selecting original before you paste then you will essentially get a replace with append… but you can see the in append even in darkroom view. The pasted items will be appended after teh current position that you have in the history stack… so you can do both with append…
You are correct, I just tested it too.
I normally keep the lighttable setting on Overwrite, so I had never noticed it before
Well I added in my edit… above… append goes from where you are in the stack so if you select original before you paste you will get replace and if you move to some point in the stack your paste will follow that…so you can fully control it…
I’ve seen these messages with the recent windows build - see How cheap a GPU will still speed up darktable? - #53 by hannoschwalm but I’d basically concluded that it was a result of using the wrong OpenCL tuning for my system, as it only does it with certain settings. I’m using D&S too BTW.