dostrajanie pamięci i wydajności

🔗wymagania dotyczące pamięci

Przetwarzanie obrazu RAW w darktable wymaga dużej ilości pamięci systemowej. Proste obliczenie jasno to pokazuje: w przypadku obrazu o rozdzielczości 20 megapikseli darktable wymaga 4x32-bitowej komórki zmiennoprzecinkowej do przechowywania każdego piksela, co oznacza, że każdy pełny obraz tego rozmiaru będzie wymagał około 300 MB pamięci na samo przechowywanie danych obrazu. Aby faktycznie przetworzyć ten obraz przez dany moduł, darktable potrzebuje co najmniej dwóch buforów (wejściowego i wyjściowego) tej wielkości, przy czym bardziej złożone moduły potencjalnie wymagają kilku dodatkowych buforów dla danych pośrednich. Bez dalszej optymalizacji do przechowywania i przetwarzania danych obrazu podczas wykonywania kolejki system może wymagać od 600 MB do 3 GB pamięci. Do tego dochodzi segment kodu darktable, kod i dane wszelkich dynamicznie połączonych bibliotek systemowych, a także dalsze bufory, których darktable używa do przechowywania stanów pośrednich (pamięci podręcznej) w celu szybkiego dostępu podczas pracy interaktywnej.

Na dobrą sprawę darktable wymaga praktycznie co najmniej 4GB fizycznej pamięci RAM i od 4 do 8GB dodatkowej pamięci wymiany, ale będzie działać tym lepiej, im więcej pamięci mu przydzielisz.

Oprócz wykonywania na procesorze, wiele modułów darktable ma także implementacje OpenCL, które mogą w pełni wykorzystać przetwarzanie równoległe, oferowane przez twoją kartę graficzną (GPU). Podobnie, im więcej masz pamięci GPU, tym lepiej będzie działać darktable.

🔗kafelkowanie

Jeśli darktable nie ma przydzielonej wystarczającej pamięci, aby przetworzyć od razu całe zdjęcie, moduły mogą korzystać ze “strategii kafelkowania”, w której zdjęcie dzielone jest na mniejsze części (kafelki), przetwarzane niezależnie, a następnie łączone ponownie w całość. Podejście takie pozwala na przetwarzanie mniejszą ilością pamięci, ale ma również kilka wad:

kafelkowanie jest zawsze wolniejsze – czasem do 10x, choć dla niektórych modułów bywa ono nieistotne,
kafelkowanie nie jest dostępne dla niektórych modułów z racji konstrukcji ich wewnętrznych algorytmów

W przypadku większości systemów kafelkowanie będzie prawdopodobnie używane tylko w przypadku eksportu pełnowymiarowych obrazów, dzięki czemu interaktywna praca w ciemni będzie przetwarzana wydajniej. Aby uzyskać najlepszą wydajność (i uniknąć trybów kafelkowania), powinieneś uruchomić darktable razem z jak najmniejszą liczbą innych aplikacji i skonfigurować darktable tak, aby wykorzystywał jak najwięcej pamięci systemowej i graficznej.

🔗dostrajanie wydajności

There are a number of configuration parameters that can help you to fine-tune your system’s performance. Some of these parameters are available in preferences > processing > CPU / memory and others need to be modified directly in darktable’s configuration file (found in $HOME/.config/darktable/darktablerc).

W tej sekcji znajdują się wskazówki dotyczące dostosowywania tych ustawień.

🔗jak testować

Aby określić, w jakim stopniu twoje modyfikacje poprawiają (lub nie) wydajność darktable, będziesz potrzebować jednego lub więcej przykładowych zdjęć do przetestowania oraz metody oceny szybkości kolejki przetwarzania.

W przypadku przykładowych zdjęć zaleca się użycie bardziej intensywnych modułów, takich jak dyfuzja lub wyostrzenie lub odszumianie (profilowane). Eksport będzie prawdopodobnie zapewniał bardziej spójne i porównywalne odstępy czasowe pomiędzy przebiegami potoków, niż prace interaktywne (i dodatkowo zwiększy obciążenie sprzętu).

Aby uzyskać informacje o profilowaniu, musisz uruchomić darktable na terminalu za pomocą polecenia darktable -d opencl -d perf. Jeśli chcesz uzyskać więcej informacji na temat kafelkowania, powinieneś użyć darktable -d opencl -d tiling -d perf.

Za każdym razem, gdy kolejka jest przetwarzana (kiedy zmieniasz parametry modułu, powiększanie, przesuwanie, eksportowanie itp.), zobaczysz (w sesji terminala) całkowity czas spędzony w kolejce i czas spędzony w każdym z jąder OpenCL. Najbardziej wiarygodną wartością jest całkowity czas spędzony w kolejce i jego powinieneś użyć do oceny zmian.

Uwaga: Czasy podane dla każdego pojedynczego modułu są niedokładne w przypadku asynchronicznego uruchamiania kolejki OpenCL (por. tryb asynchroniczny poniżej).

Aby umożliwić wydajne przetwarzanie w OpenCL, ważne jest, aby procesor graficzny był zajęty. Wszelkie przerwania lub zablokowany przepływ danych wydłużają całkowity czas przetwarzania. Jest to szczególnie ważne w przypadku małych buforów obrazu, wykorzystywanych podczas pracy interaktywnej, które mogą być szybko przetwarzane przez szybki procesor graficzny. Jednak nawet krótkotrwałe przestoje kolejki mogą łatwo stać się wąskim gardłem.

Z drugiej strony wydajność darktable podczas eksportu plików zależy mniej więcej od szybkości algorytmów i mocy twojego procesora graficznego. Krótkoterminowe przestoje nie będą miały zauważalnego wpływu na całkowity czas eksportu.

🔗zasoby darktable

The “darktable resources” preference (in preferences > processing > CPU / memory) allows you to choose between four different approaches to allocating your system’s resources to darktable. Each of these options controls multiple individual parameters, which are defined independently in $HOME/.config/darktable/darktablerc. You can amend any of these directly within your darktablerc file to tweak values for your selected resource level, though you cannot add your own custom resource level to the preferences drop-down.

Uwaga: Tryb unrestricted naprawdę nie bierze jeńców. Może się to wydawać najlepszym ustawieniem, ale szczególnie podczas eksportowania dużych zdjęć o wysokiej jakości, nieograniczone użycie pamięci może spowodować swapping, co może prowadzić do pogorszenia wydajności lub cichego ubicia darktable przez system operacyjny.

Każda z czterech opcji „zasobów darktable” jest zdefiniowana w następujący sposób:

resource_default=512 8 128 700
resource_large=700 16 128 900
resource_small=128 4 64 400
resource_unrestricted=16384 1024 128 900

Mówiąc bardziej ogólnie, można je przedstawić jako poziom_zasobów=a b c d, gdzie a - d są zdefiniowane w następujący sposób:

a. pamięć systemowa do przetwarzania modułu: Maksymalna ilość pamięci systemowej udostępniona do przetwarzania modułu. Niższe wartości zmuszają pamięciożerne moduły do przetwarzania obrazów z coraz większą liczbą kafelków. Liczba ta stanowi ułamek całkowitej ilości pamięci systemowej, podzielony przez 1024. Na przykład w systemie z 16 GB całkowitej pamięci systemowej ilość przypisana przez resource_default (w GB) wynosi 16 * 512 / 1024, lub 8 GB pamięci systemowej.
b. minimalny rozmiar bufora kafli: Minimalny rozmiar pojedynczego bufora kafli, podobnie wyrażony jako ułamek całkowitej pamięci systemowej. Na przykład w systemie z 16 GB całkowitej pamięci systemowej ilość przypisana przez resource_default (w GB) wynosi 16 * 8 / 1024, czyli 0,125 GB systemowej pamięci RAM. Należy pamiętać, że to ustawienie ma w dużej mierze charakter historyczny i nie jest już zbyt przydatne w praktyce — zaleca się pozostawienie jego wartości domyślnej.
c. pamięć podręczna miniatur: Ilość pamięci, używanej dla pamięci podręcznej miniatur. Ponownie jest to wyrażone jako ułamek całkowitej pamięci systemowej, a w systemie 16 GB ilość przypisana przez resource_default wynosi 16 * 128 / 1024, czyli 2 GB systemowej pamięci RAM.
D. Pamięć OpenCL (GPU).: Maksymalna ilość pamięci GPU, udostępniona do przetwarzania modułu. Podobnie jak w przypadku pamięci systemowej, niższe wartości zmuszą pamięciożerne moduły do przetwarzania zdjęć w coraz większej liczbie kafelków. Pamięć karty graficznej będzie prawdopodobnie używana także przez inne aplikacje w systemie. Jednak w przeciwieństwie do pamięci systemowej, twój procesor graficzny nie jest w stanie korzystać z plików wymiany i darktable nie jest w stanie określić, ile pamięci jest w danym momencie dostępne. Jeśli ten parametr będzie ustawiony zbyt wysoko, darktable może zostać zmuszony do powrotu do przetwarzania przez procesor (które będzie znacznie wolniejsze, ale stabilne i z prawidłowo przetworzonymi danymi) lub darktable może ulec awarii, a nawet sprawić, że system będzie niezdatny do użytku. Z tego powodu część parametrów pamięci GPU obejmuje również dodatkowe 600MB zapasu, aby uniknąć nadmiernej alokacji pamięci. Na przykład, na procesorze graficznym z 6 GB pamięci, darktable użyje około (6 - 0,6) * 700 / 1024 lub 3,5 GB pamięci RAM GPU przy użyciu poziomu resource_default.

Oprócz poziomów zasobów prezentowanych w interfejsie użytkownika, za pomocą wiersza poleceń można ustawić następujące opcje (np. darktable --conf resourcelevel="notebook"). Tryby te są przeznaczone do debugowania problemów z kafelkowaniem i testowania wydajności typowych systemów na większych maszynach programistycznych. Dostępne są następujące opcje:

“mini” (1GB ram, 2MB pojedynczego bufora, 128MB pamięci cache miniatur, 200MB pamięci na OpenCL)
“notebook” (4GB ram, 32MB pojedynczego bufora, 512MB pamięci cache miniatur, 1GB pamięci dla OpenCL)
“reference” (8GB ram, 32MB pojedynczego bufora, 512MB pamięci cache miniatur, 2GB pamięci dla OpenCL)

🔗dostrojenie użycia pamięci GPU

Jeśli chcesz maksymalnie skorzystać ze swojej pamięci GPU dla potrzeb OpenCL, masz trzy możliwości:

Wybierz „duży” poziom zasobów. W przypadku karty 6 GB zużyje to około 5 GB pamięci GPU, pozostawiając 1 GB na resztę systemu. (zalecane)
Dostosuj darktablerc, aby zwiększyć ostatnią liczbę (ułamek pamięci OpenCL) dla wybranego poziomu zasobów. Na przykład zwiększenie ułamka pamięci OpenCL do 950 spowodowałoby zwiększenie dostępnej pamięci na procesorze graficznym 6 GB do około 5,3 GB. (absolutnie nie polecamy)
Set preferences > processing > OpenCL > use all device memory to “on”, which will use all of your device’s memory, less a 600MB headroom. Please see the section below for “per device setting” of headroom.

🔗zrównoważone OpenCL vs. kafelkowanie CPU

W większości przypadków uruchomienie modułu na procesorze graficznym o dużej mocy (ścieżka kodowa OpenCL) jest znacznie szybsze, niż uruchomienie tego samego modułu przy użyciu ścieżki kodowej procesora. Jednak wielu użytkowników ma szybkie wielordzeniowe procesory z dużą ilością systemowej pamięci RAM, ale procesor graficzny o znacznie mniejszych możliwościach (zazwyczaj zintegrowana grafika z małą ilością dedykowanej pamięci). Użycie kodu OpenCL w takich przypadkach może prowadzić do nadmiernego kafelkowania i często lepiej jest uruchomić moduł bez kafelkowania, korzystając ze ścieżki kodowej procesora, niż próbować używać OpenCL z dużym kafelkowaniem.

Podczas przetwarzania kolejki darktable próbuje określić, który tryb będzie najlepszy dla danego modułu, szacując oczekiwane obciążenie dla ścieżek kodowych OpenCL oraz procesora. W większości przypadków preferowana będzie ścieżka kodowa OpenCL, nawet jeśli oznaczałoby to kafelkowanie obrazu, ponieważ OpenCL jest zazwyczaj znacznie szybszy, niż uruchamianie kodu procesora (często aż 10 razy szybciej, jeśli jest to karta dedykowana).

Jeśli stosunek szacowanego obciążenia (CPU do GPU) jest większy niż wspólczynnik korzyści (patrz poniżej), darktable użyje procesora do przetwarzania tego modułu, w przeciwnym razie użyje procesora graficznego.

🔗konfiguracja OpenCL dla urządzenia

Domyślne ustawienia darktable zapewniają rozsądną wydajność procesora graficznego na większości systemów. Jeśli jednak chcesz spróbować dalej zoptymalizować wszystko, w tej sekcji opisano odpowiednie parametry konfiguracyjne (wszystkie są ustawione w pliku darktablerc).

Większość opcji OpenCL zarządzana jest strategią “na urządzenie”. Parametr konfiguracyjny dla każdego urządzenia ma postać:

cldevice_v5_nvidiacudaquadrortx4000=0 250 0 16 16 128 0 0 0.000 0.000 0.500

lub bardziej ogólnie

cldevice_version_canonicalname=a b c d e f g h i j k

Przy pierwszym uruchomieniu darktable zostanie automatycznie utworzony wpis w darktablerc dla każdego nowo wykrytego urządzenia, zawierający poprawną kanoniczną nazwę urządzenia i numer wersji. Parametry a - k definiowane są w następujący sposób i można je edytować ręcznie:

a. unikaj operacji atomowych: 1 = unikaj operacji atomowych; 0 = używaj operacji atomowych (domyślnie); Operacje atomowe w OpenCL są specjalną metodą synchronizacji danych i są używane tylko w kilku modułach. Niestety, niektóre stare urządzenia AMD/ATI wyjątkowo wolno przetwarzają elementy atomowe i w przypadku tych kart lepiej jest przetwarzać moduły, których dotyczy problem, w procesorze, niż akceptować ultrawolną ścieżkę kodową GPU. Ustaw ten parametr na 1, jeśli doświadczasz powolnego przetwarzania w modułach takich jak cienie i światła, monochromatyczność, kontrast miejscowy lub globalna mapa tonów (przestarzałe) lub jeśli system zawiesza się sporadycznie. Należy pamiętać, że nie powinno to dotyczyć żadnej karty, wyprodukowanej po 2015 roku.
b. mikrodrzemka: domyślnie 250; W idealnym przypadku podczas przetwarzania kolejki procesor graficzny będzie zajęty na 100%. Jeśli jednak do aktualizacji ekranu wymagana jest także karta graficzna, a darktable wykorzystuje ją w 100%, może nie wystarczyć czasu na to zadanie. Zwykle objawia się to nierównymi aktualizacjami GUI podczas przesuwania, powiększania lub przesuwania suwaków. Aby rozwiązać ten problem, darktable może dodawać małe przerwy w przetwarzaniu kolejek, aby procesor graficzny mógł złapać oddech i wykonać czynności związane z GUI. Parametr „mikrodrzemka” kontroluje czas trwania tych przerw w mikrosekundach.; We wszystkich obecnych systemach wartość domyślna jest bezpieczna. Jeśli używasz wielu urządzeń lub nie używasz oddzielnego procesora graficznego do rysowania na ekranie, wartość tę można ustawić na 0 dla wszystkich urządzeń innych niż stacjonarne, co poprawi wydajność.
c. przypięta pamięć: 0 = wyłącz przypięty transfer (domyślnie); 1 = wymuszaj przypięty transfer; Podczas kafelkowania ogromne ilości pamięci muszą zostać przeniesione pomiędzy hostem a urządzeniem. Na niektórych urządzeniach bezpośrednie przesyłanie pamięci do i z dowolnego obszaru pamięci hosta może spowodować duży spadek wydajności. Jest to szczególnie zauważalne podczas eksportowania dużych obrazów na mniejsze karty graficzne lub podczas korzystania z nowszych modułów, takich jak dyfuzja lub wyostrzenie lub tryb laplasjana z prowadzeniem w module ratowania prześwietleń.; Nie ma bezpiecznej metody ani ogólnej zasady pozwalającej przewidzieć, czy ten parametr zapewni poprawę wydajności, więc będziesz musiał sam poeksperymentować. Jednak szansa, że przypięty transfer doprowadzi do poprawy, jest dość niska, jeśli twoja karta została wyprodukowana po 2015 roku.
d. clroundup wh / e. clroundup ht: Te parametry należy zostawić z wartościami domyślnymi – testy nie pokazały żadnych korzyści z innymi wartościami.
f. liczba uchwytów zdarzeń: domyślnie 128; Uchwyty zdarzeń są używane przez darktable do monitorowania powodzenia/niepowodzeń jąder i dostarczania informacji o profilowaniu, nawet jeśli kolejka jest wykonywana asynchronicznie. Liczba uchwytów zdarzeń jest ograniczonym zasobem sterownika OpenCL — chociaż można je ponownie wykorzystać, istnieje ograniczona liczba, z których można korzystać w tym samym czasie. Niestety nie ma sposobu, aby dowiedzieć się, jakie są limity zasobów dla danego urządzenia (jest to spowodowane tym, że darktable korzysta z API OpenCL V.1.2 do obsługi wszystkich platform), więc darktable domyślnie przyjmuje bezpieczne założenie 128. Na większości aktualnych urządzeń i sterowników można spodziewać się, że bezpiecznych na pewno będzie aż 1024 (na pewno, jeśli sterownik/karta zgłasza OpenCL V.2.0 lub nowszy), co prowadzi do nieco lepszej wydajności OpenCL. Jeśli w sterowniku zabraknie wolnych uchwytów, wystąpią awarie jądra OpenCL z komunikatem o błędzie CL_OUT_OF_RESOURCES, a nawet awaria lub zawieszenie systemu. (Jeśli napotkasz ten problem, otwórz prosimy zgłoszenie na gihubie); Wartość 0 zakazuje darktable używania jakichkolwiek uchwytów zdarzeń. Uniemożliwi to darktable prawidłowe monitorowanie powodzenia jąder OpenCL, ale pozwoli zaoszczędzić trochę na narzucie obliczeniowym sterowników, co prowadzi do nieco lepszej wydajności (mniej niż 5%). Konsekwencją tego jest to, że wszystkie awarie będą prowadzić do zniekształconych wyników, których darktable nie zauważy. Jest to zalecane tylko wtedy, gdy masz pewność, że twój system działa solidnie.
g. tryb asynchroniczny: 1 = użyj trybu asynchronicznego; 0 = nie używaj (domyślnie); Ta flaga kontroluje, jak często darktable blokuje kolejkę OpenCL, aby uzyskać informację o powodzeniu/porażce uruchomionych jąder. Aby uzyskać optymalne opóźnienie, ustaw tę wartość na 1, aby darktable uruchamiał kolejkę asynchronicznie i próbował użyć jak najmniejszej liczby przerwań/zdarzeń. Jeśli zauważysz błędy OpenCL, np. uszkodzonych jąder, zresetuj parametr do 0. Spowoduje to przerwanie pracy darktable po każdym module, co ułatwi ci wyizolowanie ewentualnych problemów. Zgłaszano problemy z niektórymi starszymi kartami AMD/ATI (takimi jak HD57xx), które mogą generować zniekształcone dane wyjściowe, jeśli ten parametr jest ustawiony na 1. W razie wątpliwości pozostaw domyślną wartość 0.
h. wyłącz urządzenie: 0 = włącza urządzenie; 1 = wyłącza urządzenie; Jeśli darktable wykryje nieprawidłowe działanie urządzenia, automatycznie je oznaczy, ustawiając ten parametr na 1. Jeśli masz urządzenie, które zgłasza wiele błędów, możesz je ręcznie wyłączyć, ustawiając to pole na 1. Jeśli darktable wyłączył to urządzenie, ale jesteś pewien, że należy go użyć, możesz go ponownie włączyć, ustawiając to pole na 0.

i. reserved

j. współczynnik korzyści: definiuje współczynnik korzyści, opisany w sekcji zrównoważone OpenCL vs. kafelkowanie CPU. Jeśli masz szybką kartę graficzną z dużą ilością pamięci, możesz bezpiecznie pozostawić tę domyślną wartość 0,000. Jeśli jednak chcesz dostosować tę wartość do własnego systemu, powinieneś skorzystać z poniższego procesu:

Uruchom darktable z opcją debugowania kafelków (darktable -d tiling) i rozpocznij edycję obrazu w ciemni. Otwórz moduł ratowania prześwietleń i skorzystaj z metody “laplasjana z prowadzeniem”, ustawiając „średnicę rekonstrukcji” na wysoką wartość, dbając jednocześnie o to, aby kafelkowanie nie występowało (sprawdź informacje debugowania w sesji terminala podczas regulacji suwaka).
Sprawdź czasy wykonania tego modułu przy włączonym i wyłączonym OpenCL (uruchamiając darktable -d perf, aby sprawdzić wydajność).
Ustaw opcję „współczynnik korzyści” na przybliżoną wartość (czas wykonania procesora / czas wykonania procesora GPU).

k. część pamięci współdzielonej: Niektóre urządzenia OpenCL nie mają dedykowanej pamięci, ale dzielą ją z procesorem — jednym z przykładów jest układ Apple ARM, ale także urządzenia zintegrowane Intela, AMD lub ARM SOC. Ponieważ chcemy, aby pamięć systemowa była dostępna do buforowania lub ścieżek kodowych procesora, ograniczamy ilość całej pamięci używanej do podanego ułamka. Zatem przy domyślnej wartości 0.5 i komputerze Apple z 16 GB systemowej pamięci RAM, OpenCL będzie w stanie wykorzystać 8 GB.

Uwaga: jeśli darktable wykryje wadliwy klucz konfiguracyjny urządzenia, zostanie on przywrócony do wartości domyślnych.

🔗konfiguracja OpenCL dla pojedynczych id

Dostępny jest również drugi klucz konfiguracyjny specyficzny dla urządzenia, który uwzględnia zarówno nazwę urządzenia oraz jego identyfikator (w przypadku posiadania dwóch identycznych urządzeń). W tym przypadku po zwykłej nazwie klucza cldevice_version_canonicalname następuje _idX, gdzie X jest identyfikatorem urządzenia. Na przykład, jeśli powyższe przykładowe urządzenie było określane jako urządzenie 0, drugie ustawienie konfiguracyjne będzie miało (domyślnie) wartość cldevice_v5_quadrortx4000_id0=600.

Ten klucz konfiguracyjny ma obecnie zdefiniowany tylko jeden parametr:

forced headroom (default 600): The amount of memory (in MB) that will not be used by darktable during OpenCL processing. This setting is only valid if you set preferences > processing > OpenCL > use all device memory to “on”.; Jeśli masz pewność, że żadna aplikacja (ani twój system operacyjny) nie korzysta z konkretnego urządzenia, możesz ustawić ten parametr na 0 dla nieużywanego urządzenia, aby darktable wykorzystał całą pamięć tego urządzenia.; Domyślna wartość 600 MB powinna wystarczyć w przypadku większości systemów. Jeśli zauważysz problemy z wydajnością spowodowane spadkiem wydajności darktable na procesorze, spróbuj zmienić go na 800 lub większy.

🔗pozostałe klawisze konfiguracyjne

W darktablerc dostępne są również poniższe klawisze konfiguracyjne:

cldevice_version_canonicalname_building: Ta opcja jest używana podczas kompilowania jąder OpenCL i może być udostępniona w celu dostrojenia wydajności lub obejścia błędów. Musisz usunąć wszystkie istniejące jądra, aby móc je ponownie skompilować z nowymi opcjami. Podaj pusty ciąg do rekompilacji bez żadnych opcji. Usuń to ustawienie całkowicie, aby przekompilować je z opcjami domyślnymi, domyślnie jest to -cl-fast-relaxed-math dla sterowników NVIDIA, żadne inne karty nie mają ustawionej tej opcji kompilatora.; Opcja -cl-fast-relaxed-math znacznie poprawia wydajność, ale zmienia obliczenia matematyczne w kodzie przetwarzającym moduł, co może prowadzić do innych wyników. W przypadku obecnych implementacji Intela ta flaga kompilatora prowadzi do wyraźnie błędnych wyników, na kartach AMD wyniki są niejednoznaczne. Niektóre kombinacje karta/sterownik są w porządku, inne nie. Ponieważ sterowniki AMD stale się zmieniają, nie zalecamy używania tej opcji na kartach AMD.
opencl_synch_cache: Jeśli ustawiony na „true”, ten parametr zmusi darktable do pobrania buforów obrazów z procesora graficznego po każdym module i zapisania ich w pamięci podręcznej kolejki. Jest to operacja pochłaniająca zasoby, ale może mieć sens w zależności od procesora graficznego (nawet gdy procesor graficzny jest raczej wolny). W tym przypadku darktable może faktycznie zaoszczędzić trochę czasu, gdy parametry modułu się zmienią, ponieważ może wrócić do stanu pośredniego buforowanego i ponownie przetworzyć tylko część kolejki. Od wersji darktable 4.4 wydajność pamięci podręcznej kolejki znacznie się poprawiła, więc ustawienie jej na „aktywny moduł” (domyślnie) jest w większości przypadków dobre.
opencl_mandatory_timeout: domyślnie 400; Jeśli darktable chce skorzystać z dowolnego urządzenia OpenCL, musi je zarezerwować do dalszego użytku. Jeśli to urządzenie jest aktualnie używane, darktable odczeka opencl_mandatory_timeout * 5ms, zanim powróci do procesora. Zwiększ tę wartość, jeśli wolisz używać OpenCL (ponieważ twoja karta jest naprawdę szybka, a procesor nie).