geheugen & prestatie-afstemming

🔗geheugenvereisten

Het verwerken van een Raw-afbeelding in darktable vereist veel systeemgeheugen. Een eenvoudige berekening maakt dit duidelijk: voor een afbeelding van 20 megapixels heeft darktable een 4x32-bit floating point cel nodig om elke pixel op te slaan, wat betekent dat elke volledige afbeelding van deze grootte ongeveer 300 MB geheugen nodig heeft om de afbeeldingsgegevens op te slaan. Om deze afbeelding daadwerkelijk via een bepaalde module te verwerken, heeft darktable ten minste twee buffers (invoer en uitvoer) van deze grootte nodig, waarbij complexere modules mogelijk meerdere extra buffers nodig hebben voor tussenliggende gegevens. Zonder verdere optimalisatie kan er tussen de 600 MB en 3 GB geheugen nodig zijn om beeldgegevens op te slaan en te verwerken terwijl de pixelpijp wordt uitgevoerd. Daarbovenop komt het codesegment van darktable, de code en gegevens van alle dynamisch gekoppelde systeembibliotheken, evenals verdere buffers die darktable gebruikt om tussenliggende toestanden (cache) op te slaan voor snelle toegang tijdens interactief werk.

Al met al vereist darktable minstens 4GB fysiek RAM plus 4 tot 8GB extra swap-ruimte om te draaien, maar het zal beter presteren naarmate je meer geheugen hebt.

Veel darktable-modules werken niet alleen op uw CPU, maar hebben ook OpenCL-implementaties die volledig kunnen profiteren van de parallelle verwerking die door uw grafische kaart (GPU) wordt geboden. Evenzo, hoe meer GPU-geheugen je hebt, hoe beter darktable zal presteren.

🔗tegelen

Als darktable niet voldoende geheugen heeft om de hele afbeelding in één keer te verwerken, kunnen modules ervoor kiezen om een “tiling-strategie” te gebruiken, waarbij de afbeelding wordt opgesplitst in kleinere delen (tegels) die onafhankelijk worden verwerkt en aan het einde weer aan elkaar worden genaaid. Hoewel hierdoor afbeeldingen kunnen worden verwerkt met een veel kleinere geheugenvoetafdruk, heeft het ook enkele nadelen:

tegelen is altijd langzamer – soms tot 10x langzamer, hoewel voor sommige modules het verschil verwaarloosbaar is,
tegelen is technisch niet mogelijk voor sommige modules vanwege de aard van de onderliggende algoritmen

Voor de meeste systemen zal tiling waarschijnlijk alleen worden gebruikt voor het exporteren van afbeeldingen op volledige grootte, waarbij interactief werk in ontwikkelen efficiënter wordt verwerkt. Voor de beste prestaties (en het vermijden van tiling-modi) moet u darktable naast zo min mogelijk andere toepassingen gebruiken en darktable configureren om zoveel mogelijk van uw systeem- en GPU-geheugen te gebruiken.

🔗prestatieafstemming

Er zijn een aantal configuratieparameters die u kunnen helpen om de prestaties van uw systeem te verfijnen. Sommige van deze parameters zijn beschikbaar in voorkeuren > verwerken > cpu/gpu/memory en andere moeten direct worden gewijzigd in het configuratiebestand van darktable ( gevonden in $HOME/.config/darktable/darktablerc).

In dit gedeelte vindt u richtlijnen voor het aanpassen van deze instellingen.

🔗hoe te testen

Om te bepalen in hoeverre uw aanpassingen de darktable-prestaties verbeteren (of niet), heeft u een of meer voorbeeldafbeeldingen nodig om mee te testen en een methode om de snelheid van de pixelpijp te beoordelen.

Voor voorbeeldafbeeldingen wordt u aangeraden enkele van de meer intensieve modules te gebruiken, zoals diffuus of verscherpen of [ruisreductie (profiel)](../ module-referentie/verwerkingsmodules/denoise-profiled.md). Exporteren heeft waarschijnlijk meer consistente en vergelijkbare timing tussen pijpruns dan interactief werk (en zal ook uw hardware meer pushen).

Om profileringsinformatie te verkrijgen, moet u darktable starten vanaf een terminal met darktable -d opencl -d perf. Als je meer informatie wilt over tegelen, gebruik dan darktable -d opencl -d tiling -d perf.

Elke keer dat de pixelpijp wordt verwerkt (wanneer u moduleparameters wijzigt, zoomt, pant, exporteert enz.), ziet u (in uw terminalsessie) de totale tijd doorgebracht in de pixelpijp en de tijd doorgebracht in elk van de OpenCL-kernels. De meest betrouwbare waarde is de totale tijd die in pixelpijp is doorgebracht en u moet deze gebruiken om uw wijzigingen te beoordelen.

Opmerking: De timing die voor elke afzonderlijke module worden gegeven, zijn onbetrouwbaar wanneer de OpenCL pixelpipe asynchroon wordt uitgevoerd (zie asynchrone modus hieronder).

Om een efficiënte verwerking met OpenCL mogelijk te maken, is het essentieel dat de GPU bezig wordt gehouden. Eventuele onderbrekingen of een vastgelopen gegevensstroom zullen bijdragen aan de totale verwerkingstijd. Dit is vooral belangrijk voor de kleine beeldbuffers die worden gebruikt tijdens interactief werken, die snel kunnen worden verwerkt door een snelle GPU. Echter, zelfs korte onderbrekingen van de pixelpipe kunnen gemakkelijk een bottleneck worden.

Aan de andere kant worden de prestaties van darktable tijdens het exporteren van bestanden min of meer alleen bepaald door de snelheid van de algoritmen en de paardenkracht van jouw GPU. Kortdurende haperingen zullen geen merkbaar effect hebben op de totale duur van een export.

🔗darktable bronnen

Met de voorkeur “darktable resources” (in voorkeuren > verwerken > cpu/gpu/memory) kunt u kiezen tussen vier verschillende benaderingen voor het toewijzen van de bronnen van uw systeem naar darktable. Elk van deze opties bestuurt meerdere individuele parameters, die onafhankelijk worden gedefinieerd in $HOME/.config/darktable/darktablerc. U kunt elk van deze rechtstreeks in uw darktablerc-bestand wijzigen om waarden voor uw geselecteerde resource-niveau aan te passen, hoewel u uw eigen aangepaste resource-niveau niet kunt toevoegen aan de vervolgkeuzelijst met voorkeuren.

Opmerking: de modus onbeperkt “neemt echt alles”. Dit lijkt misschien de beste instelling om te gebruiken, maar vooral bij het exporteren van grote afbeeldingen met hoge kwaliteit kan onbeperkt geheugengebruik leiden tot swapping, wat kan leiden tot verminderde prestaties of tot het stilletjes uitschakelen van darktable door uw besturingssysteem.

Elk van de vier “darktable resources”-opties wordt als volgt gedefinieerd:

resource_standaard=512 8 128 700
resource_groot=700 16 128 900
resource_klein=128 4 64 400
resource_onbeperkt=16384 1024 128 900

Meer in het algemeen kunnen deze worden weergegeven als resource_level=a bc d waarbij a - d als volgt worden gedefinieerd:

a. systeemgeheugen voor moduleverwerking: De maximale hoeveelheid systeemgeheugen die beschikbaar is gesteld voor moduleverwerking. Lagere waarden dwingen geheugen-hongerige modules om afbeeldingen te verwerken met een toenemend aantal tegels. Dit getal is een fractie van de totale hoeveelheid systeemgeheugen, gedeeld door 1024. Op een systeem met 16 GB totaal systeemgeheugen is de hoeveelheid die wordt toegewezen door ‘resource_default’ (in GB) bijvoorbeeld ‘16 * 512 / 1024’, of 8 GB systeem-RAM.
b. minimale tegelbuffergrootte: De minimale grootte van een enkele tiling-buffer, op dezelfde manier uitgedrukt als een fractie van het totale systeemgeheugen. Op een systeem met 16 GB totaal systeemgeheugen is de hoeveelheid die wordt toegewezen door ‘resource_default’ (in GB) bijvoorbeeld ‘16 * 8 / 1024’ of 0,125 GB systeem-RAM. Houd er rekening mee dat deze instelling grotendeels historisch is en niet langer van veel praktisch nut is - u wordt geadviseerd deze op de standaardwaarde te laten staan.
c. miniatuur cache geheugen: de hoeveelheid geheugen die moet worden gebruikt voor de miniatuurcache. Nogmaals, dit wordt uitgedrukt als een fractie van het totale systeemgeheugen en op een systeem van 16 GB is de hoeveelheid die wordt toegewezen door resource_default 16 * 128 / 1024, of 2 GB systeem-RAM.
D. OpenCL (GPU)-geheugen: de maximale hoeveelheid GPU-geheugen die beschikbaar wordt gesteld voor moduleverwerking. Net als bij systeemgeheugen zullen lagere waarden geheugenvretende modules dwingen om afbeeldingen met een toenemend aantal tegels te verwerken. Uw GPU-geheugen zal waarschijnlijk ook worden gebruikt door andere applicaties op uw systeem. In tegenstelling tot het systeemgeheugen kan uw GPU echter geen voordeel halen uit wisselbestanden en is het voor darktable onmogelijk om te weten hoeveel geheugen er op een bepaald moment beschikbaar is. Als deze parameter te hoog is ingesteld, kan darktable gedwongen worden terug te vallen op CPU-verwerking (wat aanzienlijk langzamer maar stabieler zal zijn en met correct verwerkte gegevens) of kan darktable crashen en zelfs uw systeem onbruikbaar maken. Om deze reden omvat de GPU-geheugenparameterfractie ook een extra 600 MB vrije ruimte in een poging om overmatige toewijzing van geheugen te voorkomen. Op een GPU met 6 GB geheugen zal darktable bijvoorbeeld ongeveer (6 - 0.6) * 700 / 1024 gebruiken, of 3,5 GB GPU RAM bij gebruik van het resource_default niveau.

Naast de resource-niveaus die in de gebruikersinterface worden weergegeven, kunnen de volgende opties worden ingesteld via de opdrachtregel (bijv. darktable --conf resourcelevel="notebook"). Deze modi zijn ontworpen voor het oplossen van problemen met tegels en het testen van de prestaties van veelvoorkomende systemen op grotere ontwikkelmachines. De volgende opties zijn voorzien:

“mini” (1 GB ram, 2 MB enkele buffer, 128 MB thumbnail-cache, 200 MB OpenCL-geheugen)
“notebook” (4GB ram, 32MB enkele buffer, 512MB thumbnail cache, 1GB OpenCL geheugen)
“referentie” (8 GB ram, 32 MB enkele buffer, 512 MB thumbnail-cache, 2 GB OpenCL-geheugen)

🔗GPU-geheugengebruik afstemmen

Als je de GPU-geheugen maximaal wilt benutten voor OpenCL, heb je drie opties:

Kies het resource-niveau “groot”. Voor een kaart van 6 GB gebruikt dit ongeveer 5 GB GPU-geheugen, waardoor er 1 GB overblijft voor de rest van uw systeem. (aanbevolen)
Wijzig darktablerc om het laatste getal (de OpenCL-geheugenfractie) voor het door u geselecteerde resource-niveau te verhogen. Als u bijvoorbeeld de OpenCL-geheugenfractie naar 950 verhoogt, zou het beschikbare geheugen op een 6 GB GPU toenemen tot ongeveer 5,3 GB. (absoluut niet aan te raden)
Stel [voorkeuren > verwerking > OpenCL > gebruik volledige geheugen] (../preferences-settings/processing.md#cpu–gpu–memory) in op “aan”, waardoor al het geheugen van uw apparaat wordt gebruikt, minus 600 MB speelruimte. Zie de sectie hieronder voor de ‘per apparaatinstelling’ van de speelruimte.

🔗Gebalanceerde OpenCL versus CPU tiling

In de meeste gevallen is het uitvoeren van een verwerkingsmodule op een krachtige GPU (het OpenCL codepad) aanzienlijk sneller dan het uitvoeren van dezelfde module via het CPU codepad. Veel gebruikers hebben echter snelle multi-core CPU’s met een grote hoeveelheid systeem-RAM, maar een GPU met aanzienlijk minder mogelijkheden (meestal geïntegreerde grafische kaarten met kleine hoeveelheden speciaal geheugen). Het gebruik van OpenCL code kan in deze gevallen leiden tot overmatige tiling en het is vaak beter om een module zonder tiling uit te voeren met het CPU codepad dan te proberen OpenCL te gebruiken met zware tiling.

Tijdens het verwerken van de pijplijn probeert darktable te bepalen welke modus het beste is voor een bepaalde module door de verwachte werkbelasting voor zowel OpenCL als CPU codepaden in te schatten. In de meeste gevallen wordt de voorkeur gegeven aan het OpenCL codepad, zelfs als dat zou betekenen dat de afbeelding getegeld moet worden, omdat OpenCL meestal veel sneller is dan het uitvoeren van de CPU code (vaak wel 10 keer sneller als het een speciale kaart is).

Als de verhouding van geschatte werklasten (CPU vs GPU) groter is dan de voordeelhint (zie hieronder), gebruikt darktable de CPU voor het verwerken van die module, anders gebruikt het de GPU.

🔗apparaat-specifieke OpenCL-configuratie

De standaard darktable-instellingen leveren op de meeste systemen redelijke GPU-prestaties. Als je echter wilt proberen om dingen verder te optimaliseren, beschrijft deze sectie de relevante configuratieparameters (die allemaal zijn ingesteld in je darktablerc-bestand).

De meeste OpenCL-gerelateerde opties worden met een “per apparaat”-strategie beheerd. De configuratieparameter voor elk apparaat ziet er als volgt uit:

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

of, meer in het algemeen

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

Er wordt automatisch een item gemaakt in darktablerc voor elk nieuw gedetecteerd apparaat wanneer je darktable voor de eerste keer start, met de juiste canonieke apparaat-naam en versienummer. De parameters a - k zijn als volgt gedefinieerd en kunnen handmatig worden bewerkt:

a. vermijd atomen: 1 = vermijd atomen; 0 = gebruik atomen (standaard); Atoombewerkingen in OpenCL zijn een speciale methode voor gegevenssynchronisatie en worden slechts in enkele modules gebruikt. Helaas zijn sommige oude AMD/ATI-apparaten extreem traag in het verwerken van atomaire gegevens en op deze kaarten is het beter om de betrokken modules op de CPU te verwerken in plaats van een enorm langzaam GPU-codepad te accepteren. Stel deze parameter in op 1 als u trage verwerking ervaart binnen modules zoals schaduwen en hooglichten_, [monochrome](../. ./module-reference/processing-modules/monochroom.md), lokaal contrast, of [globale toonmap (verouderd)](. ./../module-reference/processing-modules/global-tonemap) of als het systeem met tussenpozen vastloopt. Houd er rekening mee dat dit geen invloed mag hebben op kaarten die sinds 2015 zijn geproduceerd.
b. micro nap: standaard 250; In het ideale geval houd je de GPU op 100% bezig bij het verwerken van de pixelpijp. Als uw GPU echter ook uw scherm moet bijwerken en darktable deze voor 100% gebruikt, is er mogelijk niet voldoende tijd over voor deze taak. Dit manifesteert zich meestal als schokkerige GUI-updates bij pannen, zoomen of bij het verplaatsen van schuifregelaars. Om dit probleem op te lossen kan darktable kleine pauzes toevoegen aan de pixelpijp-verwerking, zodat de GPU op adem kan komen en GUI-gerelateerde activiteiten kan uitvoeren. De parameter “micro nap” regelt de duur van deze pauzes in microseconden.; Op alle huidige systemen bent u veilig met de standaardwaarde. Als u meerdere apparaten gebruikt of als u uw afzonderlijke GPU niet gebruikt om op uw scherm te tekenen, kan deze waarde worden ingesteld op 0 voor alle niet-desktopapparaten, wat tot betere prestaties leidt.
c. vastgezet geheugen: 0 = vastgezette overdracht uitschakelen (standaard); 1 = vastgezette overdracht afdwingen; Tijdens het tiling moeten enorme hoeveelheden geheugen worden overgedragen tussen host en apparaat. Op sommige apparaten kan directe geheugenoverdracht van en naar een willekeurig host-geheugengebied een grote prestatievermindering opleveren. Dit is vooral merkbaar bij het exporteren van grote afbeeldingen op kleinere grafische kaarten of bij het gebruik van nieuwere modules zoals diffuus of verscherpen of de gestuurde laplacians-modus in de [hooglicht herstellen] (../module-reference/processing-modules/highlight-reconstruction.md) module.; Er bestaat geen veilige methode of algemene regel om te voorspellen of deze parameter al dan niet een prestatievoordeel zal opleveren, dus u zult zelf moeten experimenteren. De kans dat een vastgezette overdracht tot een verbetering leidt, is echter vrij klein als uw kaart na 2015 is geproduceerd.
d. clroundup wh / e. clroundup ht: Deze parameters moeten op deze standaardwaarde blijven staan – testen heeft geen enkel voordeel opgeleverd voor het gebruik van andere waarden.
F. aantal gebeurtenishandvatten: standaard 128; Gebeurtenishandvatten worden door darktable gebruikt om het succes/falen van kernels te monitoren en profileringsinformatie te bieden, zelfs als de pixelpijp asynchroon wordt uitgevoerd. Het aantal gebeurtenishandvatten is een beperkte bron van uw OpenCL-stuurprogramma. Hoewel ze kunnen worden gerecycled, is er een beperkt aantal dat tegelijkertijd kan worden gebruikt. Helaas is er geen manier om erachter te komen wat de resourcelimieten zijn voor een bepaald apparaat (dit komt doordat darktable de OpenCL V.1.2 API gebruikt om alle platforms te ondersteunen), dus darktable gebruikt standaard een conservatieve schatting van 128. Op de meeste huidige apparaten en stuurprogramma’s kun je verwachten dat een aantal tot 1024 veilig is (zeker als je stuurprogramma/kaart OpenCL V.2.0 of groter meldt), wat leidt tot iets betere OpenCL-prestaties. Als uw stuurprogramma geen vrije handvatten meer heeft, zult u falende OpenCL-kernels ervaren met de foutmelding ‘CL_OUT_OF_RESOURCES’ of zelfs crashes of het systeem loopt vast. (Als je dit probleem tegenkomt, open dan een github-probleem); Een waarde van 0 zorgt ervoor dat darktable geen gebeurtenishandles gebruikt. Dit voorkomt dat darktable het succes van uw OpenCL-kernels goed kan controleren, maar bespaart wat driver-overhead, wat leidt tot iets betere prestaties (minder dan 5%). Het gevolg is dat alle fouten zullen leiden tot verminkte uitvoer zonder dat darktable het merkt. Dit is alleen aan te raden als u zeker weet dat uw systeem goed werkt.
g. asynchrone modus: 1 = gebruik asynchrone modus; 0 = niet gebruiken (standaard); Deze vlag bepaalt hoe vaak darktable de OpenCL pixelpijp blokkeert om een status te krijgen op succes/mislukking van de kernels die zijn uitgevoerd. Voor een optimale vertraging zet je dit op 1, zodat darktable de pixelpijp asynchroon laat lopen en zo min mogelijk interrupts/events probeert te gebruiken. Als je OpenCL-fouten ervaart, zoals falende kernels, stel je de parameter in op 0. Dit zorgt ervoor dat darktable na elke module wordt onderbroken, zodat u eventuele problemen gemakkelijker kunt isoleren. Er zijn problemen gemeld met sommige oudere AMD/ATI-kaarten (zoals de HD57xx) die vervormde uitvoer kunnen produceren als deze parameter is ingesteld op 1. Laat deze bij twijfel op de standaardwaarde 0 staan.
h. apparaat uitschakelen: 0 = apparaat inschakelen; 1 = apparaat uitschakelen; Als darktable een defect apparaat detecteert, wordt dit automatisch als zodanig gemarkeerd door deze parameter in te stellen op 1. Als u een apparaat heeft dat veel fouten meldt, kunt u dit handmatig uitschakelen door dit veld op 1 in te stellen. Als darktable het apparaat heeft uitgeschakeld, maar u zeker weet dat het moet worden gebruikt, kunt u het opnieuw inschakelen door dit veld op 0 te zetten.

i. reserved

j. voordeel: Dit definieert de advantage hint beschreven in de balanced OpenCL versus CPU tiling sectie. Als je een snelle grafische kaart met veel geheugen hebt, kun je dit veilig op de standaardwaarde van 0,000 laten staan. Als je dit getal echter wilt aanpassen aan je eigen systeem, moet je het volgende proces gebruiken:

Start darktable met de tiling debug optie (darktable -d tiling) en begin met het bewerken van een afbeelding in de donkere kamer. Open de module highlight reconstruction en gebruik de methode “guided laplacians”, waarbij je de “diameter of reconstruction” op een hoge waarde zet, terwijl je ervoor zorgt dat er geen tiling optreedt (controleer de debug-informatie in je terminalsessie terwijl je de schuifregelaar aanpast).
Controleer de uitvoeringstijden van deze module met OpenCL aan en uit (door darktable -d perf uit te voeren om de prestaties te onderzoeken).
Stel de “voordeel hint optie” in op ongeveer (CPU uitvoeringstijd / GPU uitvoeringstijd).

k. gedeelde geheugenfractie: Sommige OpenCL-apparaten hebben geen speciaal geheugen, maar delen dit met de CPU - Apple ARM-silicium is een voorbeeld, maar ook ingebouwde apparaten van Intel-, AMD- of ARM-SOC’s. Omdat we het systeemgeheugen beschikbaar willen houden voor caching of CPU-codepaden, beperken we de hoeveelheid van al het gebruikte geheugen tot de gegeven fractie. Dus met de standaardwaarde van 0,5 en een Apple-computer met 16 GB systeem-RAM zou OpenCL gebruik kunnen maken van 8 GB.

Opmerking: als darktable een “buggy” apparaat-configuratiesleutel detecteert, wordt deze teruggeschreven naar de standaardwaarden.

🔗id-specifieke OpenCL configuratie

Er wordt ook een tweede apparaatspecifieke configuratiesleutel meegeleverd, die rekening houdt met zowel de apparaatnaam en het apparaat-ID (voor het geval je twee identieke apparaten hebt). In dit geval wordt de gebruikelijke sleutelnaam cldevice_version_canonicalname gevolgd door _idX waarbij X het apparaat-ID is. Als het bovenstaande voorbeeldapparaat bijvoorbeeld apparaat 0 werd genoemd, zou de tweede configuratie-instelling (standaard) cldevice_v5_quadrortx4000_id0=600 zijn.

Voor deze configuratiesleutel is momenteel slechts één parameter gedefinieerd:

geforceerde hoofdruimte (standaard 600): De hoeveelheid geheugen (in MB) die niet door darktable zal worden gebruikt tijdens OpenCL-verwerking. Deze instelling is alleen geldig als u voorkeuren > verwerking > OpenCL > gebruik volledige geheugen instelt op “aan”.; Als je zeker weet dat er geen apps (of je besturingssysteem) gebruik maken van het specifieke apparaat, kun je deze parameter instellen op 0 voor het anders ongebruikte apparaat, zodat darktable al het geheugen van dat apparaat zal gebruiken.; De standaardwaarde van 600 MB zou voor de meeste systemen goed moeten zijn. Als u merkt dat u prestatieproblemen ondervindt, doordat darktable terugvalt op de CPU, probeer deze dan te wijzigen in 800 of hoger.

🔗andere configuratiesleutels

De volgende aanvullende configuratiesleutels zijn ook beschikbaar in darktablerc:

cldevice_versie_canoniekenaam_gebouw: Deze optie wordt gebruikt bij het compileren van OpenCL-kernels en kan beschikbaar zijn voor het afstemmen van de prestaties of om bugs te omzeilen. Je moet alle bestaande kernels verwijderen om ze opnieuw te kunnen compileren met de nieuwe opties. Geef een lege tekenreeks op om opnieuw te compileren zonder enige opties. Verwijder de instelling volledig om opnieuw te compileren met standaardopties, standaard is -cl-fast-relaxed-math voor nvidia-stuurprogramma’s, bij alle andere kaarten is deze compileroptie niet ingesteld.; De optie -cl-fast-relaxed-math verbetert de prestaties aanzienlijk, maar verandert de wiskunde in de verwerkingscode van de module, wat mogelijk tot andere resultaten kan leiden. Voor huidige Intel-implementaties leidt deze compilervlag tot zichtbaar verkeerde resultaten, op AMD-kaarten zijn de resultaten niet doorslaggevend. Sommige kaart/driver-combinaties zijn prima, andere niet. Omdat de AMD-stuurprogramma’s voortdurend veranderen, raden we af om deze op AMD-kaarten te gebruiken.
opencl_synch_cache: Indien ingesteld op “true”, zal deze parameter darktable dwingen om na elke module beeldbuffers van jouw GPU op te halen en op te slaan in de pixelpijp-cache. Dit is een arbeidsintensieve bewerking, maar kan zinvol zijn, afhankelijk van jouw GPU (ook als de GPU nogal traag is). In dit geval kan darktable in feite wat tijd besparen wanneer moduleparameters zijn gewijzigd, omdat het terug kan gaan naar een tussenliggende status in de cache en slechts een deel van de pixelpijp opnieuw hoeft te verwerken. Sinds darktable 4.4 is de efficiëntie van de pixelpijp-cache veel verbeterd, dus het instellen ervan op “actieve module” (de standaard) is in de meeste gevallen goed.
opencl_mandatory_timeout: standaard 400; Als darktable gebruik wil maken van een OpenCL-apparaat, moet het dit reserveren voor verder gebruik. Als dat apparaat momenteel wordt gebruikt, wacht darktable tot opencl_mandatory_timeout * 5ms voordat het terugvalt naar de CPU. Verhoog deze waarde als u liever OpenCL gebruikt (omdat uw kaart erg snel is en uw CPU niet).