As per title. I am using standard modules in scene-referred workflow and while editing, the ‘working…’ text takes an age to clear. It is much slower than previous version I was using, 3.2.1 It happens when making adjustsments in any module, clicking on history items, and toggling clipping indicators. Speed of export does not seem to be affected.
If there is any more information I can provide to help find a solution, please let me know.
darktable -d all
to get some numbers to see which module is slow.
Entered into terminal. Returned:
-bash: darktable: command not found
The darktable binary is inside the app bundle and is not on your system path.
I am new to this, and its a bit like reading French. I navigate to /Applications/darktable.app/Contents/MacOS
I see exec files which have the same icon as terminal. Out of curiosity I double click one called ‘darktable’, wondering if this is where I type the command given by darix. Without running command, it automatically opens darktable, and runs this, which is interesting because I see WARNING and CRITICAL:
(process:3070): GLib-GObject-CRITICAL **: 14:43:41.374: g_object_set: assertion ‘G_IS_OBJECT (object)’ failed
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
[dt_pthread_create] info: bumping pthread’s stacksize from 524288 to 2097152
(darktable:3070): GLib-GObject-WARNING **: 14:43:42.248: invalid cast from ‘GtkMenuBar’ to ‘GtkWindow’
(darktable:3070): Gtk-CRITICAL **: 14:43:42.248: gtk_window_add_accel_group: assertion ‘GTK_IS_WINDOW (window)’ failed
Typing darix command after that does nothing. I am lost.
EDIT: I run /Applications/darktable.app/Contents/MacOS/darktable -d all in terminal and lots is happening now. Computer is writing wonderful novel.
Ok I let that run whilst doing other things. Came back and I’m still not sure it had finished. From about 37.8 on it seemed to just be repeating the same process endlessly. So I have now ended it, and provide what it had done to that point.
soupy darktable d all.txt (397.4 KB)
EDIT: Re-uploaded after running a second time, and quitting darktable.
It won’t end until you quit darktable.
run darktable-cltest - it seems opencl kernels aren’t built properly. It can take several attempts, so you can do it with a script: OSX: compiling kernels for opencl for packaged darktable.app needs several attempts · Issue #2810 · darktable-org/darktable · GitHub
Thanks for the link. I copied and pasted into terminal, hit enter, and it returned OpenCL enabled. Opened darktable, but problem remains. I initially had ‘activate opencl support’ unchecked in preferences, and only turned it on when I noticed the problem. Of course it wouldn’t help any if opencl was disabled on mac, so your script has likely solved an issue I never knew I had, but not the current issue. Problem appears to be cpu rather than gpu.
What is your hardware?
run /Applications/darktable.app/Contents/MacOS/darktable -d perf gives the processing times for each module.
there’re some modules that will profit from opencl, since there’re a couple of parallelization issues using openmp with apple clang compiler … (but there also can be issues with opencl on some system configurations)
A lot of optimizing stuff was made for dt 3.4 that uses parallelization so this might have counteracted performance on osx …
Attached. All I did was enter the command, then quit darktable. Result looks very similar to my earliest post. I don’t see any module processing times here. Was I meant to go into darkroom and turn each module on and off?
soupy darktable d perf.txt (1.6 KB)
cpu: 2.3 GHz Intel Core i7
gpu: Intel HD Graphics 4000 1536 MB
memory: 4 GB 1600 MHz DDR3
hdd: 500GB sata, 89GB available
It’s all old stuff. However, it is the same hardware I was using with 3.2.1
just open one edited image in darkroom so the pipe is processed once - no need to turn on/off the modules.
Ok, attached.
soupy darktable d perf 2.txt (7.7 KB)
just the usual stuff: denoise (profiled) and contrast equalizer are known to cost performance (the values indicates, that the gpu was already used to process the full pixel pipe - it you zoom in it will even slow down)
demosaic is quite laggy - do you use specific settings?
there’s a known issue with waveform histogram - to speed up you’d better use the standard histogram (will be fixed with 3.4.1)
just to interpret the times:
you may do the same for darktable 3.2.1 and compare the results.
Since dt 3.4. updated the database you need to rename ~/.config/darktable to ~/.config/darktable.old to start with a clean config.
You can run darktable 3.2.1 from the dmg package ( /Volumes/darktable/darktable.app/Contents/MacOS/darktable -d perf), import the image (the edit should be taken over from the xmp file)
I can’t seem to find a mac that fits those specs. On OpenCL compatibility, refer to Mac computers that use OpenCL and OpenGL graphics - Apple Support (CA).
That was just using PPG defaults. edge threshold 0, smoothing off, match greens disabled.
You’ve found it! Upon startup pipe loads quickly but waveform takes an age to display. Toggling between histogram and waveform also takes an age. But using histogram only is much quicker, and speeds are comparable to how it was before. Many many thanks for your help!
Do I still need to do this now we’ve found the problem? What does clean config entail? Loss of presets/defaults, anything like that?
It’s a macbook pro, 15 inch (mid 2012). Can’t see it on that list, but I have read the gpu can support opencl 1.1
Yes, settings from darktablerc and data.db will be lost. library.db contains your image edits (can be restored importing XMP sidecars).
no, you don’t need to restart with a clean config.
Thats just an usual way to exclude individual settings when searching for the root of an issue. Since you was able to get your old performance back when using the standard histogram - then it’s a known bug originated in the code (or better Apples modifications to the build tools) and doesn’t depend on settings …
A quick web search shows that it has a NVIDA GeForce GT 650M, which may do what the integrated graphics chip cannot.