geheugenvereisten

Processing a raw image in Ansel requires a great deal of system memory. A simple calculation makes this clear: For a 20 megapixel image, Ansel requires a 4x32-bit floating point cell to store each pixel, meaning that each full image of this size will require approximately 300MB of memory just to store the image data. In order to actually process this image through a given module, Ansel needs at least two buffers (input and output) of this size, with more complex modules potentially requiring several additional buffers for intermediate data. Without further optimization, anything between 600MB and 3GB of memory might be required to store and process image data as the pixelpipe executes. On top of this is Ansel’s code segment, the code and data of any dynamically-linked system libraries, as well as further buffers that Ansel uses to store intermediate states (cache) for quick access during interactive work.

Al met al vereist Ansel 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 Ansel-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 Ansel zal presteren.

tegelen

Als Ansel 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:

  • tiling is always slower – sometimes up to 10x slower, though for some modules the difference is negligible,
  • tiling is not technically possible for some modules because of the nature of the underlying algorithms

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 Ansel naast zo min mogelijk andere toepassingen gebruiken en Ansel configureren om zoveel mogelijk van uw systeem- en GPU-geheugen te gebruiken.

prestatieafstemming

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, GPU, Memory and others need to be modified directly in Ansel’s configuration file (found in $HOME/.config/Ansel/Anselrc).

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

hoe te testen

Om te bepalen in hoeverre uw aanpassingen de Ansel-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.

For sample images, you are advised to use some of the more intensive modules, such as diffuse or sharpen or denoise (profiled). Exports are likely to have more consistent and comparable timings between pipe runs than interactive work (and will also push your hardware more).

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

Each time the pixelpipe is processed (when you change module parameters, zoom, pan, export etc.) you will see (in your terminal session) the total time spent in the pixelpipe and the time spent in each of the OpenCL kernels. The most reliable value is the total time spent the in pixelpipe and you should use this to assess your changes.

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 Ansel 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.

Ansel bronnen

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

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

1resource_standaard=512 8 128 700
2resource_groot=700 16 128 900
3resource_klein=128 4 64 400
4resource_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 Ansel moeilijk zijn om precies te weten hoeveel geheugen er op een bepaald moment beschikbaar is. Als deze parameter te hoog is ingesteld, kan Ansel 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 Ansel 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. Ansel --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” (1GB ram, 2MB single buffer, 128MB thumbnail cache, 200MB OpenCL memory)
  • “notebook” (4GB ram, 32MB single buffer, 512MB thumbnail cache, 1GB OpenCL memory)
  • “reference” (8GB ram, 32MB single buffer, 512MB thumbnail cache, 2GB OpenCL memory)

GPU-geheugengebruik afstemmen

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

  • Choose the “large” resource level. For a 6GB card, this will use approximately 5GB of GPU memory, leaving 1GB for the rest of your system.
  • Alter Anselrc to increase the last number (the OpenCL memory fraction) for your selected resource level. For example, increasing the OpenCL memory fraction to 950 would increase the available memory on a 6GB GPU to approximately 5.3GB.
  • Set preferences > processing > cpu / gpu / memory > tune OpenCL performance to “memory size”, which will use all of your device’s memory, less a 400MB headroom. Please see the section below for other options related to this setting.

apparaat-specifieke OpenCL-configuratie

De standaard Ansel-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 Anselrc-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

of, meer in het algemeen

cldevice_version_canonicalname=a b c d e f g h i

Er wordt automatisch een item gemaakt in Anselrc voor elk nieuw gedetecteerd apparaat wanneer je Ansel 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. avoid atomics
1 = avoid atomics; 0 = use atomics
Atomic operations in OpenCL are a special method of data synchronization and are only used in a few modules. Unfortunately, some old AMD/ATI devices are extremely slow in processing atomics and, on these cards, it is better to process the affected modules on the CPU rather than accepting an ultra-slow GPU codepath. Set this parameter to 1 if you experience slow processing within modules like local contrast or if you get intermittent system freezes. Please note that this should not affect any card manufactured since 2015.
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 Ansel 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 Ansel 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. pinned memory
0 = use gui to select mode; 1 = enforce pinned transfer; 2 = disable pinned transfer
During tiling huge amounts of memory need to be transferred between host and device. On some devices direct memory transfers to and from an arbitrary host memory region may give a large performance penalty. This is especially noticeable when exporting large images on smaller graphics cards or while using newer modules like diffuse or sharpen or the guided laplacians mode in the highlight reconstruction module.

There is no safe method or general rule to predict whether or not this parameter will provide a performance benefit, so you will have to experiment for yourself. This mode can also be set globally by setting the “tune OpenCL performance” option to “memory transfer” (in Preferences > Processing > CPU, GPU, Memory), in which case this parameter should be set to 0. Otherwise, you can enable/disable it at a device level using this 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 Ansel 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 Ansel 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 Ansel van het gebruik van eventhandles. Dit zal voorkomen dat Ansel 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 Ansel 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 Ansel 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 Ansel 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 Ansel 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 Ansel 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 Ansel 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 Ansel te dwingen de benchmark opnieuw uit te voeren, maar in de meeste gevallen bewerk je deze instelling niet.

Opmerking: als Ansel 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:

forced headroom (default 400)
The amount of memory (in MB) that will not be used by Ansel during OpenCL processing. This setting is only valid if you set preferences > processing > tune OpenCL performance to “memory size”.

Als u deze parameter op nul (0) zet, zal Ansel 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 Ansel 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 Ansel draait. Anders kan het gebruik van deze optie leiden tot onvoldoende geheugen, waardoor Ansel terugvalt naar de CPU, waardoor de prestaties aanzienlijk afnemen. U kunt deze optie uit- en weer inschakelen om Ansel 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 Ansel 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 Ansel 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 Anselrc:

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 Ansel 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 Ansel 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.