darktable flatpak running slower than deb install

You can run the flatpak version of clinfo or run flatpak run org.darktable.Darktable --command darktable-cltest and post the output here.

This is what I got for the second one

darktable 4.6.1
Copyright (C) 2012-2024 Johannes Hanika and other contributors.

https://www.darktable.org
darktable is an open source photography workflow application and
non-destructive raw developer for photographers.
GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Usage:
darktable [OPTIONS] [IMAGE_FILE | IMAGE_FOLDER]

Options:

–cachedir DIR
darktable keeps a cache of image thumbnails for fast image preview
and precompiled OpenCL binaries for fast startup. By default the
cache is located in $HOME/.cache/darktable/. Multiple thumbnail
caches may exist in parallel, one for each library file.

–conf KEY=VALUE
Temporarily overwrite individual settings on the command line with
this option - these settings will not be stored in darktablerc
on exit.

–configdir DIR
Where darktable stores user-specific configuration.
The default location is $HOME/.config/darktable/

–datadir DIR
Define the directory where darktable finds its runtime data.
The default location depends on your installation.
Typical locations are /opt/darktable/share/darktable/
and /usr/share/darktable/

–library FILE
Specifies an alternate location for darktable’s image information database,
which is stored in an SQLite file by default (library.db) in the directory
specified by --configdir or $HOME/.config/darktable/. You can use this
option for experimentation without affecting your original library.db.
If the specified database file doesn’t exist, darktable will create it.

When darktable starts, it locks the library to the current user by writing
the process identifier (PID) to a lock file named FILE.lock next to the
specified library. If a lock file already exists, darktable will exit.

:memory: -> Use this option as FILE to keep the database in system memory,
discarding changes on darktable termination.

–localedir DIR
Define where darktable can find its language-specific text
strings. The default location depends on your installation.
Typical locations are /opt/darktable/share/locale/
and /usr/share/locale/

–luacmd COMMAND
A string containing lua commands to execute after lua
initialization. These commands will be run after your “luarc”
file. If lua is not compiled-in, this option will be accepted
but won’t do anything.

–moduledir DIR
darktable has a modular structure and organizes its modules as
shared libraries for loading at runtime.
This option tells darktable where to look for its shared libraries.
The default location depends on your installation.
Typical locations are /opt/darktable/lib64/darktable/
and /usr/lib64/darktable/

–noiseprofiles FILE
Provide a json file that contains camera-specific noise profiles.
The default location depends on your installation.
Typical locations are /opt/darktable/share/darktable/noiseprofile.json
and /usr/share/darktable/noiseprofile.json

-t, --threads NUM
Limit number of openmp threads to use in openmp parallel sections

–tmpdir DIR
Define where darktable should store its temporary files.
If this option is not supplied darktable uses the system default.

-v, --version
Print darktable version number

-h, --help
Show this help text

Debugging:

–bench-module MODULE_A,MODULE_B

–disable-opencl
Prevent darktable from initializing the OpenCL subsystem.

–disable-pipecache
Disable the pixelpipe cache. This option allows only
two cachelines per pipe, and should be used for debugging
purposes only.

–dump-pfm MODULE_A,MODULE_B

–dump-pipe MODULE_A,MODULE_B

–dumpdir DIR

-d SIGNAL
Enable debug output to the terminal. Valid signals are:

act_on, cache, camctl, camsupport, control, dev, expose,
imageio, input, ioporder, lighttable, lua, masks, memory,
nan, opencl, params, perf, pipe, print, pwstorage, signal,
sql, tiling, undo

all     -> to debug all signals
common  -> to debug dev, imageio, masks, opencl, params, pipe
verbose -> when combined with debug options like '-d opencl'
           provides more detailed output. To activate verbosity,
           use the additional option '-d verbose'
           even when using '-d all'.

There are several subsystems of darktable and each of them can be
debugged separately. You can use this option multiple times if you
want to debug more than one subsystem.

E.g. darktable -d opencl -d camctl -d perf

–d-signal SIGNAL
if -d signal or -d all is specified, specify the signal to debug
using this option. Specify ALL to debug all signals or specify
signal using it’s full name. Can be used multiple times.

–d-signal-act SIGNAL_ACT

Valid SIGNAL_ACT are:
all, raise, connect, disconnect, print-trace

If -d signal or -d all is specified, specify the signal action
to debug using this option.

See resources | darktable for more detailed documentation.
See Sign in to GitHub · GitHub to report bugs.

Sorry I got the syntax wrong, can you try flatpak run --command=darktable-cltest org.darktable.Darktable

darktable 4.6.1
Copyright (C) 2012-2024 Johannes Hanika and other contributors.

Compile options:
Bit depth → 64 bit
Debug → DISABLED
SSE2 optimizations → ENABLED
OpenMP → ENABLED
OpenCL → ENABLED
Lua → ENABLED - API version 9.2.0
Colord → ENABLED
gPhoto2 → ENABLED
GMIC → ENABLED - Compressed LUTs are supported
GraphicsMagick → ENABLED
ImageMagick → DISABLED
libavif → ENABLED
libheif → ENABLED
libjxl → ENABLED
OpenJPEG → ENABLED
OpenEXR → ENABLED
WebP → ENABLED

See resources | darktable for detailed documentation.
See Sign in to GitHub · GitHub to report bugs.

 0.0196 [dt_get_sysresource_level] switched to 1 as `default'
 0.0196   total mem:       15663MB
 0.0196   mipmap cache:    1957MB
 0.0196   available mem:   7831MB
 0.0196   singlebuff:      122MB
 0.0200 [dt_dlopencl_init] could not find default opencl runtime library 'libOpenCL'
 0.0201 [dt_dlopencl_init] could not find default opencl runtime library 'libOpenCL.so'
 0.0202 [opencl_init] opencl library 'libOpenCL.so.1' found on your system and loaded, preference 'default path'
 0.0702 [opencl_init] found 3 platforms
 0.0702 [check platform] platform 'rusticl' with key 'clplatform_rusticl' is NOT active
 0.0702 [check platform] platform 'Clover' with key 'clplatform_clover' is NOT active

[opencl_init] found 1 device

[dt_opencl_device_init]
DEVICE: 0: ‘NVIDIA GeForce RTX 3050 Laptop GPU’
PLATFORM, VENDOR & ID: NVIDIA CUDA, NVIDIA Corporation, ID=4318
CANONICAL NAME: nvidiacudanvidiageforcertx3050laptopgpu
DRIVER VERSION: 525.147.05
DEVICE VERSION: OpenCL 3.0 CUDA, SM_20 SUPPORT
DEVICE_TYPE: GPU, dedicated mem
GLOBAL MEM SIZE: 3904 MB
MAX MEM ALLOC: 976 MB
MAX IMAGE SIZE: 32768 x 32768
MAX WORK GROUP SIZE: 1024
MAX WORK ITEM DIMENSIONS: 3
MAX WORK ITEM SIZES: [ 1024 1024 64 ]
ASYNC PIXELPIPE: NO
PINNED MEMORY TRANSFER: NO
AVOID ATOMICS: NO
MICRO NAP: 250
ROUNDUP WIDTH & HEIGHT 16x16
CHECK EVENT HANDLES: 128
TILING ADVANTAGE: 0.000
DEFAULT DEVICE: NO
KERNEL BUILD DIRECTORY: /app/share/darktable/kernels
KERNEL DIRECTORY: /home/christian/.var/app/org.darktable.Darktable/cache/darktable/cached_v3_kernels_for_NVIDIACUDANVIDIAGeForceRTX3050LaptopGPU_52514705
CL COMPILER OPTION: -cl-fast-relaxed-math
CL COMPILER COMMAND: -w -cl-fast-relaxed-math -DNVIDIA_SM_20=1 -DNVIDIA=1 -I"/app/share/darktable/kernels"
KERNEL LOADING TIME: 0.0166 sec
[opencl_init] OpenCL successfully initialized. internal numbers and names of available devices:
[opencl_init] 0 ‘NVIDIA CUDA NVIDIA GeForce RTX 3050 Laptop GPU’
0.1348 [opencl_init] FINALLY: opencl is AVAILABLE and ENABLED.
[opencl_init] opencl_scheduling_profile: ‘default’
[opencl_init] opencl_device_priority: ‘/!0,///!0,*’
[opencl_init] opencl_mandatory_timeout: 400
[dt_opencl_update_priorities] these are your device priorities:
[dt_opencl_update_priorities] image preview export thumbs preview2
[dt_opencl_update_priorities] 0 -1 0 0 -1
[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] 0 0 0 0 0
[opencl_synchronization_timeout] synchronization timeout set to 200
[dt_opencl_update_priorities] these are your device priorities:
[dt_opencl_update_priorities] image preview export thumbs preview2
[dt_opencl_update_priorities] 0 -1 0 0 -1
[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] 0 0 0 0 0
[opencl_synchronization_timeout] synchronization timeout set to 200

The driver version in the flatpak is sort of old. What is your system driver version?

My system driver is also 525.147.05, when I got this computer about 2 years ago I went through trying a couple of driver versions and this was the one that worked.

Are you talking about application startup time or actual.processing time?

Its the processing time thats slower, start up is pretty similar between the 2.

Can you post the log (txt file) from -d perf for both versions using the same image and xmp?

I’ve never used perf before so I just want to make sure I’m doing what you wanted, should I be running something like “perf record -a sleep 10” in terminal while loading the same image/xmp files in each version of darktable?

use flatpak run --command=darktable -d perf org.darktable.Darktable and darktable -d perf

For darktable -d perf this is what I’m getting
darktable -d perf.txt (9.1 KB)
But on `flatpak run --command=darktable -d perf org.darktable.Darktable I’m getting this “error: Invalid id darktable: Names must contain at least 2 periods”

maybe its flatpak run --command=-d perf org.darktable.Darktable. I don’t have the flatpak installed on this machine.

I’m not having any luck with it tonight so I’ll give it another try tomorrow to see if I can have any better luck figuring out the command in the morning with some coffee.

In the file you posted, it is taking 2.3s to process this image:

24.4414 [dev_process_image] pixel pipeline took 2.317 secs (5.598 CPU) processing `_DSC9187.NEF'

Almost a 1sec of it is in the second exposure module.

This was more brush strokes than I would typically use, for this I was just me tossing some edits on a file to make it take some time to process to see if there was a noticeable difference in processing time between the deb and flatpak. And for the -d perf on the flatpak I’ve been playing around with trying to change the commands on and off today and haven’t had any luck finding anything that works rather than just getting the error about needing at least 2 periods in the name.

Try this:

flatpak run org.darktable.Darktable -d perf

That worked, heres what I got. flatpak darktable -d perf.txt (7.0 KB)

Interesting. There seems to be a slight performance hit. I assume it could be from the flatpak sandbox.

7.5018 [dev_process_image] pixel pipeline took 3.285 secs (7.412 CPU) processing `_DSC9187.NEF''

But this is not really the problem you are seeing. In your .deb setup (4.4.2), I think you have the resources set to very fast GPU. The preview pipe is being processed in GPU and it takes 0.9s. The flatpak is setup to default. In default, it uses the CPU for the preview pipe and it is taking 4.5s.

Therefore, change the flatpak processing preferences to very fast GPU.

3 Likes

That seems to be speeding up the flatpak, I hadn’t noticed that the default settings for that was different from one to the other, but a couple of test edits and the flatpak is running a lot faster now. Thanks for the help.

1 Like