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.

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 is gesteld voor moduleverwerking. Net als bij systeemgeheugen, zullen lagere waarden geheugen-hongerige modules dwingen om afbeeldingen met een toenemend aantal tegels te verwerken. Uw GPU-geheugen wordt waarschijnlijk ook gebruikt door andere toepassingen op uw systeem. In tegenstelling tot systeemgeheugen kan uw GPU echter geen voordeel halen uit swap-bestanden en kan het voor darktable moeilijk zijn om precies 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 (die aanzienlijk langzamer zal zijn). Om deze reden bevat de GPU-geheugen-parameter fractie ook een extra 400 MB aan hoofdruimte in een poging om over-toewijzing van geheugen te voorkomen. Op een GPU met 6 GB geheugen zal darktable bijvoorbeeld ongeveer (6 - 0,4) * 700/1024 gebruiken, of 3,8 GB GPU RAM bij gebruik van het resource_standaard-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.
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.
Stel voorkeuren > verwerken > cpu / gpu / memory > instellen OpenCL prestatie in op “geheugengrootte”, dat al het geheugen van uw apparaat zal gebruiken , minus een hoofdruimte van 400 MB. Zie de sectie hieronder voor andere opties met betrekking tot deze instelling.

🔗balanced OpenCL versus CPU tiling

In most cases, running a processing module on a high-powered GPU (the OpenCL codepath) is significantly faster than running the same module using the CPU codepath. However, many users have fast multi-core CPUs with a large amount of system RAM, but a GPU with significantly lower capabilities (typically, integrated graphics with small amounts of dedicated memory). Use of OpenCL code in these cases can lead to excessive tiling, and it is often better to run a module without tiling using the CPU codepath than to attempt to use OpenCL with heavy tiling.

While processing the pipeline, darktable attempts to determine which mode will be best for a given module by estimating the expected workloads for both OpenCL and CPU codepaths. In most cases it will prefer the OpenCL codepath even if that would mean tiling the image, since OpenCL is typically much faster than running the CPU code (often as much as 10 times faster if it is a dedicated card).

If the ratio of estimated workloads (CPU vs GPU) is larger than the advantage hint (see below), darktable will use the CPU for processing that module, else it will use the GPU.

🔗apparaat-specifieke OpenCL-configuratie

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

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

cldevice_v4_quadrortx4000=0 250 0 16 16 1024 0 0 0.017853 20.000

of, meer in het algemeen

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

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 - i zijn als volgt gedefinieerd en kunnen handmatig worden bewerkt:

a. vermijd atomen: 1 = vermijd atomen; 0 = gebruik atomen; 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 de huidige systemen ben je redelijk veilig met de standaardwaarde, zelfs voor geïntegreerde grafische kaarten. Als u meerdere apparaten gebruikt of uw discrete GPU niet gebruikt om op uw scherm te tekenen, kan deze waarde worden ingesteld op 0 voor de niet-desktopapparaat.
c. vastgezet geheugen: 0 = gebruik gui om modus te selecteren; 1 = vastgezette overdracht afdwingen; 2 = zet vastgezette overdracht uit; 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 is geen veilige methode of algemene regel om te voorspellen of deze parameter een prestatievoordeel zal opleveren, dus u zult zelf moeten experimenteren. Deze modus kan ook globaal worden ingesteld door de optie “instellen OpenCL prestatie” in te stellen op “geheugen overdracht” (in [voorkeuren > verwerken > cpu/gpu/memory](../preferences-settings/processing.md#cpu–gpu –memory)), in welk geval deze parameter moet worden ingesteld op 0. Anders kunt u deze parameter op apparaat-niveau in-/uitschakelen met behulp van deze parameter.
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 event-handles: Event-handles worden door darktable gebruikt om het succes/falen van kernels te controleren en profileringsinformatie te verstrekken, zelfs als de pixelpijp asynchroon wordt uitgevoerd. Het aantal event-handles is een beperkte hulpbron 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 resource-limieten zijn voor een bepaald apparaat, dus darktable gebruikt standaard een zeer conservatieve schatting van 128. Op de meeste huidige apparaten en stuurprogramma’s kunt u een aantal tot 1024 verwachten om veilig te zijn en tot iets betere OpenCL-prestaties te leiden. Als uw stuurprogramma geen vrije handvatten meer heeft, zult u te maken krijgen met falende OpenCL-kernels met de foutmelding CL_OUT_OF_RESOURCES of zelfs crashes of het systeem loopt vast.; Een waarde van 0 blokkeert darktable van het gebruik van eventhandles. Dit zal voorkomen dat darktable het succes van uw OpenCL-kernels goed bewaakt, maar bespaart enige driver-overhead, wat leidt tot betere prestaties. Het gevolg is dat eventuele storingen waarschijnlijk zullen leiden tot verminkte output zonder dat de darktable het merkt. Dit is alleen aan te raden als je zeker weet dat je systeem ijzersterk draait.
g. asynchrone modus: 1 = gebruik asynchrone modus; 0 = niet gebruiken; 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 (standaard). 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.
i. benchmark: Wanneer darktable een nieuw apparaat op uw systeem detecteert, zal het een kleine benchmark uitvoeren en het resultaat hier opslaan. Je kunt dit terugzetten naar 0 om darktable te dwingen de benchmark opnieuw uit te voeren, maar in de meeste gevallen bewerk je deze instelling niet.
j. advantage hint: This defines the advantage hint described in the balanced OpenCL versus CPU tiling section. If you have a fast graphics card with plenty of memory you can safely leave this at its default value of 0.000. However, if you want to adapt this number to your own system, you should use the following process:

Start darktable with the tiling debug option (darktable -d tiling) and start editing an image in the darkroom. Open the highlight reconstruction module and use the “guided laplacians” method, setting the “diameter of reconstruction” to a high value, while ensuring that tiling does not occur (check the debug information in your terminal session while adjusting the slider).
Check the execution times of this module with OpenCL on and off (by running darktable -d perf to examine the performance).
Set the “advantage hint option” to approximately (CPU execution time / GPU execution time).

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

🔗id-specifieke OpenCL configuratie

A second device-specific configuration key is also provided, which takes into account both the device name and the device id (just in case you have two identical devices). In this case, the usual key name cldevice_version_canonicalname is followed by _idX with X being the device id. For example, if the above example device was referred to as device 0, the second configuration setting would (by default) be cldevice_v4_quadrortx4000_id0=400.

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

geforceerde hoofdruimte (standaard 400): De hoeveelheid geheugen (in MB) die niet door darktable zal worden gebruikt tijdens OpenCL-verwerking. Deze instelling is alleen geldig als u voorkeuren > verwerken > instellen OpenCL prestatie instelt op “geheugengrootte”.; Als u deze parameter op nul (0) zet, zal darktable bij de eerste run van een pixelpijp proberen te bepalen hoeveel GPU-geheugen daadwerkelijk beschikbaar is en dit (met een veiligheidsmarge van 100 MB) als het maximum gebruiken hoeveelheid geheugen die darktable zal gebruiken voor de rest van uw sessie. Dit is meestal veilig, tenzij u andere toepassingen start (die een redelijke hoeveelheid GPU-geheugen gebruiken) terwijl darktable draait. Anders kan het gebruik van deze optie leiden tot onvoldoende geheugen, waardoor darktable terugvalt naar de CPU, waardoor de prestaties aanzienlijk afnemen. U kunt deze optie uit- en weer inschakelen om darktable te vragen zijn geheugenberekening opnieuw uit te voeren (aan het begin van de volgende pijprun). Merk op dat er bekende problemen zijn met automatische geheugendetectie op nieuwere Nvidia-stuurprogramma’s, dus automatische detectie moet met zorg worden gebruikt en is daarom standaard uitgeschakeld.; Als je zeker weet dat er geen apps (of je besturingssysteem) gebruik maken van het specifieke apparaat, kun je deze parameter instellen op 1 voor het anders ongebruikte apparaat, zodat darktable al het geheugen van dat apparaat zal gebruiken.; De standaardwaarde van 400 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 600 of “afstemmen op geheugengrootte” uit te schakelen.

🔗andere configuratiesleutels

De volgende aanvullende configuratiesleutels zijn ook beschikbaar in darktablerc:

cldevice_version_canonicalname_building: Deze optie wordt gebruikt bij het compileren van OpenCL-kernels en kan worden geleverd voor het afstemmen van de prestaties of om bugs te omzeilen. Je moet alle bestaande kernels verwijderen om ze opnieuw te compileren met de nieuwe opties. Geef een lege tekenreeks op om zonder opties opnieuw te compileren. Verwijder de instelling volledig om opnieuw te compileren met standaardopties, standaard is -cl-fast-relaxed-math
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. In veel gevallen moet deze parameter worden ingesteld op “actieve module” (de standaardinstelling), die alleen de invoer van de momenteel gefocuste module in de cache zal opslaan.