geheugen

de geheugenvereisten van darktable zijn hoog. Een simpele rekensom maakt dit duidelijk. Als je een afbeelding van 20 MPx hebt, zal darktable dit om precisieredenen intern opslaan als een 4 x 32-bits drijvende-kommacel voor elke pixel. Elke volledige afbeelding van deze grootte heeft dus ongeveer 300 MB geheugen nodig. Omdat we de afbeelding willen verwerken, hebben we voor elke module minimaal twee buffers nodig: één voor invoer en één voor uitvoer. Als we een complexere module hebben, kan het algoritme ervan bovendien meerdere tussenliggende buffers van dezelfde grootte vereisen. Zonder verdere optimalisatie zou alles tussen 600 MB en 3 GB alleen nodig zijn om afbeeldingsgegevens op te slaan en te verwerken. Bovendien hebben we het codesegment van darktable, de code en gegevens van alle dynamisch gekoppelde systeembibliotheken, en niet te vergeten, verdere buffers waar darktable tussenliggende afbeeldingen opslaat voor snelle toegang tijdens interactief werk (mip-mapcache).

Al met al heeft darktable minimaal ongeveer 4 GB geheugen nodig om goed te kunnen werken.

🔗totaal systeemgeheugen

Uit de bovenstaande analyse is het duidelijk dat jouw computer een gezonde geheugenconfiguratie nodig heeft om darktable goed te laten werken. We raden jou aan minimaal 4 GB fysiek RAM plus 4 tot 8 GB extra swapruimte te installeren.

Theoretisch zou je darktable met lagere hoeveelheden fysiek RAM kunnen gebruiken en dit in evenwicht brengen met voldoende swapruimte. Dit zou er echter voor kunnen zorgen dat jouw systeem “thrasht”, terwijl het gegevenspagina’s van en naar de harde schijf leest of schrijft. We hebben positieve berichten dat dit goed werkt voor verschillende gebruikers, maar dat het voor anderen nog steeds extreem traag kan worden. Een solid-state schijf kan de pijn enigszins verlichten.

🔗beschikbare adresruimte

Naast de totale hoeveelheid systeemgeheugen is er nog een beperkende factor: de beschikbare adresruimte van jouw hardware-architectuur. Hoeveel geheugen kan worden aangesproken door een proces, hangt af van het aantal adresbits dat jouw CPU biedt. Voor een CPU met 32-bits adresregisters is dit 2^32 bytes, wat een totaal van 4 GB maakt. Dit is de absolute bovengrens van het geheugen dat door een proces kan worden gebruikt en het vormt een krappe situatie voor darktable, zoals we hierboven hebben gezien.

De ontsnappingsroute van darktable wordt betegeling genoemd. In plaats van een afbeelding in één grote brok te verwerken, splitst darktable de afbeelding op in kleinere delen voor elke verwerkingsmodule. Dit vereist nog steeds één volledige invoer- en uitvoerbuffer, maar tussentijdse buffers kunnen klein genoeg worden gemaakt om alles binnen de limieten van de hardware te passen.

🔗geheugenfragmentatie

Helaas is dit nog niet het volledige verhaal. Een effect dat geheugenfragmentatie wordt genoemd, kan en zal software treffen die uitgebreid geheugenbeheer moet uitvoeren. Als zo’n programma 5 keer 300 MB per keer toewijst en weer vrijmaakt, zou dat geheugen normaal gesproken daarna beschikbaar moeten zijn voor één grote toewijzing van 1,5 GB. Dit is echter vaak niet het geval. De geheugentoewijzer van het systeem ziet dit gebied mogelijk niet langer als één aaneengesloten blok van 1,5 GB, maar als een rij van afzonderlijke gebieden van 300 MB. Als er geen ander vrij gebied van 1,5 GB beschikbaar is, zou een volgende toewijzing mislukken. Tijdens het uitvoeren van een programma zal dit mechanisme steeds meer van de grotere geheugenblokken wegnemen ten gunste van kleinere. Darktable’s mip map cache wijst meerdere kleine geheugenblokken toe per miniatuur, dus dit probleem is nog groter. Om deze reden is 32-bits ondersteuning vanaf darktable 2.0 soft-verouderd.

🔗verdere beperkingen

Alsof dit nog niet uitdagend genoeg was, zijn er nog andere dingen die de toegang van darktable tot het geheugen kunnen beperken. Op sommige oudere moederborden moet je de BIOS-optie “memory mapping” activeren om al het fysiek geïnstalleerde geheugen aan te zetten. Als je bovendien een 32-bits besturingssysteem gebruikt, heb je waarschijnlijk een kernelversie nodig waarop “Physical Address Extension” (PAE) is ingeschakeld. Dit is vaak, maar niet altijd het geval voor Linux. Veel distributies leveren verschillende kernels, sommige met en sommige zonder PAE geactiveerd; je moet de juiste kiezen. Om te controleren of het systeem correct is ingesteld, gebruik je het commando “free” in een terminal en onderzoek je de uitvoer. Als de output minder RAM rapporteert dan je hebt geïnstalleerd, heb je een probleem dat moet worden gecorrigeerd; je hebt bijvoorbeeld 4 GB op je bord, maar je kernel ziet slechts 3 GB of minder. Raadpleeg jouw BIOS-handleiding en de informatie over jouw Linux-variant voor meer hulp.

🔗darktable instellen op 32-bits systemen

Zoals we hebben gezien, zijn 32-bits systemen moeilijke omgevingen voor darktable. Toch gebruiken sommige gebruikers er darktable op, als de basisvereisten met betrekking tot het totale systeemgeheugen en de onderwerpen die in de bovenstaande paragrafen worden genoemd goed worden behandeld.

Er zijn verschillende parameters die moeten worden aangepast om het werkend te krijgen. Als je vers installeert, zal darktable jouw systeem detecteren en standaard conservatieve waarden instellen. Als je darktable echter upgradet van een oudere versie, is de kans groot dat je ongunstige instellingen in je voorkeuren hebt. De gevolgen kunnen zijn dat de darktable wordt afgebroken vanwege mislukte toewijzingen of – heel typisch – dat darktable een nieuwe filmrol niet goed kan importeren. Als een veel voorkomend symptoom krijg je doodskoppen weergegeven in plaats van miniaturen voor veel van jouw foto’s.

Als dit het geval is, neem dan even de tijd om jouw voorkeursinstellingen te optimaliseren. Je vindt ze in voorkeuren > verwerken > cpu/gpu/geheugen.

Hier volgt een korte uitleg van de relevante parameters en hun voorgestelde instellingen:

aantal achtergrondthreads: Deze parameter definieert het maximale aantal threads dat parallel mag lopen bij het importeren van filmrollen of het doen van andere achtergrondtaken. Om voor de hand liggende redenen kan je op 32-bits systemen slechts één thread tegelijk hebben die resources verbruikt. Je moet deze parameter dus instellen op 1; alles wat hoger is, zal jou het leven zuur maken.
hostgeheugenlimiet (in MB) voor tegelverdeling: Deze parameter vertelt darktable hoeveel geheugen (in MB) het moet aannemen dat er beschikbaar is om beeldbuffers op te slaan tijdens modulebewerkingen. Als een afbeelding niet binnen deze limieten in één brok kan worden verwerkt, zal tegelverdeling het overnemen en de afbeelding in verschillende delen, de een na de ander, verwerken. Stel dit als uitgangspunt in op de laagst mogelijke waarde van 500. Je kan later experimenteren of je het iets kan verhogen om de overhead van tegels te verminderen.
minimale hoeveelheid geheugen (in MB) voor een enkele buffer in tegelverdeling: Dit is een tweede parameter die tegels regelt. Het stelt een ondergrens in voor de grootte van tussenliggende afbeeldingsbuffers in megabytes. De parameter is nodig om in sommige gevallen (voor sommige modules) overmatige tegelverdeling te voorkomen. Stel deze parameter in op een lage waarde van 8. Je kan deze later eventueel verhogen tot 16.
geheugen in megabytes om te gebruiken voor miniatuurcache: Dit bepaalt hoeveel miniaturen (of mip-kaarten) tegelijk in het geheugen kunnen worden opgeslagen. Stel dit als uitgangspunt in op ongeveer 256 MB. Sinds darktable 2.0 wijst de cache een paar kleine buffers per miniatuur in de cache toe, waardoor er aanzienlijke geheugenfragmentatie ontstaat. Zoals eerder uitgelegd, vormt dit een probleem voor 32-bits systemen. Om deze reden is 32-bits ondersteuning vanaf darktable 2.0 zwak-verouderd.

🔗darktable op 64-bits systemen

Er valt hier niet veel te zeggen. Natuurlijk hebben 64-bits systemen ook voldoende werkgeheugen nodig, dus de aanbeveling van 4 GB plus swap geldt. Aan de andere kant hebben 64-bit-architecturen geen last van de specifieke 32-bits beperkingen zoals kleine adresruimte en fragmentatiegekte.

De meeste moderne Intel of AMD 64-bit CPU’s hebben een beschikbare adresruimte in het bereik van enkele Terabytes. Het woord ‘modern’ is in deze context relatief: alle AMD- en Intel-CPU’s die sinds respectievelijk 2003 en 2004 zijn geïntroduceerd, bieden een 64-bits modus. Linux 64-bit is al vele jaren beschikbaar.

Alle relevante Linux-distributies geven je de keuze om een 32-bits of een 64-bits versie te installeren zonder extra kosten. Je kunt zelfs oude 32-bits binaire bestanden op een 64-bits Linux draaien. Het enige dat je hoeft te doen, is wat tijd investeren in de migratie. Uiteindelijk raden we ten zeerste aan om over te stappen op een 64-bits versie van Linux. Er is echt geen reden om het niet te doen.

Op een 64-bits systeem kan je de tegel-gerelateerde configuratieparameters veilig op hun standaardwaarden laten: “hostgeheugenlimiet (in MB) voor tiling” moet een waarde hebben van 1500 en “minimale hoeveelheid geheugen (in MB) voor een enkele buffer in tegeling” moet worden ingesteld op 16. Als je migreert van een 32-bits naar een 64-bits systeem, moet je deze instellingen controleren en indien nodig handmatig wijzigen in het voorkeurenvenster van darktable.

Meestal is het niet nodig om jezelf te beperken in het aantal achtergrondthreads op een 64-bits systeem. Op een systeem met meerdere processors kan een aantal van twee tot acht threads het genereren van miniaturen aanzienlijk versnellen in vergelijking met slechts één thread. De reden is niet zozeer het maximaal profiteren van al jouw CPU-kernen - de pixelpijp van darktable gebruikt ze toch allemaal parallel - maar het verbergen van I/O-vertraging.

Een uitzondering is het vermelden waard. Als je darktable gebruikt om samengevoegde panorama’s te verwerken (bijv. TIFF’s zoals gegenereerd door Hugin), kunnen deze afbeeldingen aanzienlijke afmetingen bereiken. Elke achtergrondthread moet voldoende geheugen toewijzen om één volledige afbeelding plus tussenproducten en uitvoer in zijn buffers te bewaren. Dit kan er snel toe leiden dat zelfs een goed uitgerust 64-bits systeem onvoldoende geheugen heeft. Verlaag in dat geval het aantal achtergrondthreads tot slechts één.