Darktable speed

Software darktable
1

Hi all,

So I’ve run into an interesting problem. I had a laptop that was roughly 4 years old with an i7 quad-core (don’t remember which one exactly) which ran darktable really well - even things like denoising were pretty smooth. Recently, it died so I bought a new laptop, also with an i7 quad-core (i7-7700HQ). Everything else seems to be really fast, but darktable seems to be really slow, even just reacting to things like mouse-over events (like when I hover over a picture in the lighttable module, for example). I thought maybe it had something to do with powersaving mode, so I switched the cpu governor and the perf-bias and everything (even switched to a realtime kernel since I prefer to use that anyway), but nothing’s helped. I’m not quite sure how to debug, but I can provide logs or run and/or compile things to test. Oh, and the version I’m currently using is the one compiled for the Debian sid branch (so some version of 2.4.0).

[Edit] Tried compiling my own version and still running into the same issue. Currently running darktable-generate-cache to see if that will help. It could just be that darktable is trying to generate the cache while also attempting to be responsive to me?

2

You can try toggling your GPU setting, though DT handles this pretty well. Since you’re on sid, I’d check to see if any libraries that DT depends on were recently updated.

3

I actually do have a Nvidia GPU, but I’d rather not use the Nvidia propietary drivers and it seems that Nouveau hasn’t fully implemented everything needed by darktable - I get this when I try running darktable-cltest:

[opencl_init] opencl related configuration options:
[opencl_init] 
[opencl_init] opencl: 1
[opencl_init] opencl_library: ''
[opencl_init] opencl_memory_requirement: 768
[opencl_init] opencl_memory_headroom: 300
[opencl_init] opencl_device_priority: '*/!0,*/*/*'
[opencl_init] opencl_mandatory_timeout: 200
[opencl_init] opencl_size_roundup: 16
[opencl_init] opencl_async_pixelpipe: 0
[opencl_init] opencl_synch_cache: 0
[opencl_init] opencl_number_event_handles: 25
[opencl_init] opencl_micro_nap: 1000
[opencl_init] opencl_use_pinned_memory: 0
[opencl_init] opencl_use_cpu_devices: 0
[opencl_init] opencl_avoid_atomics: 0
[opencl_init] 
[opencl_init] could not find opencl runtime library 'libOpenCL'
[opencl_init] could not find opencl runtime library 'libOpenCL.so'
[opencl_init] found opencl runtime library 'libOpenCL.so.1'
[opencl_init] opencl library 'libOpenCL.so.1' found on your system and loaded
[opencl_init] found 1 platform
[opencl_init] found 1 device
[opencl_init] device 0 `NV136' has sm_20 support.
[opencl_init] discarding device 0 `NV136' due to missing image support.
[opencl_init] no suitable devices found.
[opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
[opencl_init] initial status of opencl enabled flag is OFF

Also, I didn’t have OpenCL support on my old laptop because I only had an onboard GPU which wasn’t supported.

I’ll check to see if some library was recently updated.

4

Right, there is no OpenCL on Nouveau for that you need NVIDIA proprietary driver.

5
  1. darktable -d perf This will tell you where darktable spends the time. And which modules got slower.
  2. how did you build/install darktable on the old machine? did something change there when you build it for the new machine? if you used the same git checkout for building on the new machine a make clean might be good + re-running cmake.
  3. you could try the darktable packages from the OBS.
6

By any chance - does your new laptop have a 4K display?

1 Like
7

Yup. Is this what’s causing the problem?

8

bigger display means larger area which darktable has to render for your preview. more pixels affected. more computation required.

9
  1. The main module that got (noticeably) slower is denoise. But -d perf doesn’t seem to talk at all about the sluggishness of the interface.
  2. I installed it from Debian sid there as well.
  3. Hmmm, I’ll try that. Although, I think @mimoklepes might have hit upon something since my new laptop has a 4K display.
10

Hmm, right. Is there any way to speed it up? Ideally I don’t have to deal with the proprietary Nvidia driver, but if that’s the only way that I can speed it up…

11

openCL is one way to speed it up yes.

12

Alright, I’m going to take the plunge to see if the closed-source Nvidia driver will help.

13

I think there are two separate problems:

  1. in my experience using OpenCL for image rendering is a must (with any decent GPU), the performance difference is huge

  2. I believe that the sluggish response in lighttable is related to this issue: https://redmine.darktable.org/issues/10764 - darktable is redrawing all visible images on even the smallest mouse movements. It’s just much more noticeable on HiDPI displays, since it has to redraw more pixels. Unfortunately it seems this didn’t get much love yet, probably the impact on the user base is not that big.

14
  1. Yeah, I’m working on getting that working. That should hopefully at least speed up processing, and that’s where I do most of my work anyway.
  2. Yeah, I saw that bug report after you asked about my 4K display. I’m happy to help fix this issue (I didn’t realize it was an issue until I got my 4K display hahahaha).
15

Cool, got OpenCL support working, so at least processing now is at a decent speed. Obviously the lighttable bug is still a problem, but since I don’t really use it much except to add tags and export, it’s not a big deal.

16

FWIW I bought a 4k monitor last April, and there was no noticeable slowdown for me. I do run the Nvidia proprietary drivers though.

17

Huh, interesting. I switched to using the proprietary drivers, but still had the slowdown in lighttable (obviously using OpenCL will speed things up in actual processing). I confirmed it was the 4K resolution because switching down to 1920x1080 fixes things and everything’s back to the speed I was used to.

18

Weird. Maybe a difference in desktop environment? I run Slackware (KDE desktop). Maybe that has something to do with it?

Around a year ago I recall reading a post somewhere about high CPU usage in lighttable view, but I can’t find it now. Perhaps it’s the same issue you’re experiencing? Simply moving the mouse around the lighttable does use a lot of CPU on my machine (~40% of one core) but it’s not enough to cause a noticeable slowdown.

Edit: and on reading the rest of the comments here it looks like someone else has mentioned the post I couldn’t fnd! :slight_smile:

19

For those who are interested and have a similar problem, here is my current workaround. Since the problem is the 4K resolution, I created a script which sets the right resolution (just half in each dimension — e.g. my regular display is 3840x2160, so my “half” resolution is 1920x1080), starts darktable (along with resetting GDK_SCALE so that the interface isn’t gigantic), and cleans up by restoring the original resolution (--preferred argument to xrandr) after I exit darktable. This way, I get the awesome 4K display most of the time as well as responsive photo editing when I want it!

Of course, this workaround is most easily implemented in linux (is there even a command-line tool to set the screen resolution in Windows or macOS?). Here is the script I’m using:

#!/bin/bash

OUTPUT="eDP-1-1"
HALF_RES="1920x1080"
HALF_RES_DPI="96"
HIGH_RES_DPI="192"
DARKTABLE='firejail darktable --noiseprofiles ~/.config/darktable/noise/presets.json'

# Change resolution

xrandr --output $OUTPUT --mode $HALF_RES --dpi $HALF_RES_DPI;

# Start darktable

GDK_SCALE="" $DARKTABLE "$@";

# Change resolution back

xrandr --output $OUTPUT --preferred --dpi $HIGH_RES_DPI;

(I use firejail to sandbox programs, but that’s irrelevant — you can just as easily remove that and just start darktable "$@".)

2 Likes
20

Have you tested, how much firejail low down darktable?