Speicher- und Leistungseinstellungen

🔗Speicheranforderungen

Die Verarbeitung eines RAW-Bildes in darktable benötigt sehr viel Arbeitsspeicher. Eine ganz einfache Rechnung kann das zeigen: Für ein Bild mit 20 Megapixel benötigt darktable eine 4x32 Bit Fliesskomma-Zelle, um ein einzelnes Pixel zu speichern, sodass jedes Bild dieser Grösse deshalb ca. 300 MB Speicher erfordert, nur um die Bilddaten zu speichern. Um dieses Bild nun in einem bestimmten Modul zu bearbeiten, benötigt darktable zwei Pufferspeicher dieser Grösse (für Ein- und Ausgabe). Wenn wir ein komplexeres Modul haben, werden dessen Algorithmen zusätzlich Speicherplatz für Zwischendaten erfordern. Ohne zusätzliche Optimierung werden während der Pixelpipe-Ausführung daher zwischen 600MB und 3 GB an Speicher benötigt, nur um die Bilddaten zu speichern und zu bearbeiten. Dazu kommt noch der Programmcode von darktable, der Code und die Daten aller dynamisch verbundenen Libraries, und zusätzlicher Puffer, in den darktable Zwischenstände für einen schnellen Zugriff während des interaktiven Arbeits abspeichert (Cache).

Insgesamt benötigt darktable mindestens 4GB physikalisches RAM plus 8GB zusätzlichen Speicher für die Auslagerung. Je mehr Speicher verfügbar ist, umso besser wird die Performance des Programmes sein.

Neben der Verarbeitung mit der CPU haben viele Module von darktable auch eine OpenCL-Implementierung, um die Vorteile der parallelen Verarbeitung durch eine Grafikkarte (GPU) nutzen zu können.. Auch hierbei gilt: Je mehr GPU-Speicher verfügbar ist, umso besser wird die Performance von darktable sein.

🔗Kachelung

Wenn darktable nicht genügend Speicher für die Bearbeitung eines ganzen Bildes in einem Durchgang hat, dann werden die Module eine “Kachel-Strategie” wählen, bei der das Bild in kleinere Teile (Kacheln) aufgeteilt wird, welche dann unabhängig bearbeitet und am Ende wieder zusammengefügt werden. Während diese Art die Bearbeitung von Bildern mit einem viel kleineren Speicher ermöglicht, gibt es auch Nachteile:

Kachelung ist immer langsamer – oft bis zu 10x langsamer, obwohl für gewisse Module der Unterschied vernachlässigbar ist,
Kacheln ist für gewisse Module wegen der verendeten Algorithmen nicht möglich

Für die meisten Systeme wird Kacheln vermutlich nur für den Export von Bildern voller Grösse nötig sein, während die interaktive Bearbeitung in der Dunkelkammer effizienter verarbeitet werden kann. Für die beste Performance (und um Kacheln zu verhindern), solltest du darktable mit möglichst wenigen andern Applikationen parallel verwenden und darktable dahingehend konfigurieren, so viel GPU-Speicher wie möglich zu nutzen.

🔗Abstimmung der Performance

Es gibt eine Anzahl von Konfigurationsparametern, die helfen, die Performance des Systems fein abzustimmen. Einige dieser Parameter sind in darktable Voreinstellungen > Bearbeiten > CPU / Speicher zu finden, andere müssen direkt in der Konfigurationsdatei darktablerc im [Konfigurationsverzeichnis}(../preferences-settings/config-directory.md) modifiziert werden.

Dieser Abschnitt gibt einige Leitlinien, wie man diese Einstellungen anpassen kann.

🔗Wie Testen

Um herauszufinden, um wie viel deine Anpassungen die Leistung von darktable erhöhen (oder nicht), brauchst du für das Testen eines oder mehrere Beispielbilder und eine Methode zur Beurteilung der Geschwindigkeit der Pixelpipe,

Für Beispielbilder empfiehlt es sich intensivere Module, wie zum Beispiel Diffusion Schärfe oder Entrauschen Profi zu verwenden. Exporte werden zwischen verschiedenen Läufen eher konsistente und vergleichbare Zeiten ergeben als interaktives Arbeiten (und auch die Hardware mehr fordern).

Um Profiling-Informationen zu erhalten, musst du darktable in einem Terminal mit darktable -d opencl -d perf neu starten. Falls du mehr Informationen über Kachelung erhalten möchtest, solltest du darktable -d opencl -d tiling -d perf nutzen.

Jedes Mal, wenn die Pixelpipe verarbeitet wird (beim Ändern von Modulparametern, Zoomen, Schwenken, Exportieren etc.) wird die benötigte Gesamtzeit für die Ausführung der Pixelpipe und die benötigte Zeit in jedem der OpenCL-Kernels im Terminalfenster angezeigt. Der zuverlässigste Wert für die Bewertung der Änderungen ist die benötigte Zeit in der Pixelpipe.

Hinweis: Die Zeitmessungen für jedes einzelne Modul sind unzuverlässig, wenn die OpenCL-Pixelpipe asynchron läuft (siehe den asynchronen Modus unten).

Um eine effiziente Bearbeitung mit OpenCL zu gewährleisten, ist es essentiell, dass wir die GPU am Laufen gehalten wird. Jegliche Unterbrechung oder ein stockender Datenfluss verlängert die Verarbeitungszeit. Dies ist besonders wichtig für die kleinen Bildpuffer, die während des interaktiven Arbeitens benötigt werden, welche mit einer schnellen GPU verarbeitet werden können. Selbst ein kurzzeitiges Stocken der Pixelpipe kann leicht zu einem Flaschenhals werden.

Auf der anderen Seite wird die Performance von darktable während des Dateiexports mehr oder weniger ausschliesslich von der Schnelligkeit der Algorithmen und den Leistungsfähigkeit deiner Grafikkarte bestimmt. Kurze Unterbrechungen werden keine merkliche Auswirkung auf die Dauer des Exports haben.

🔗Andere Ressourcen von darktable

Die “Ressourcen von darktable” Einstellung (in darktable Voreinstellungen > Bearbeitung > CPU/Speicher) erlaubt es dir zwischen vier unterschiedlichen Herangehensweisen zu wählen, um die Ressourcen an darktable zuzuweisen. Jede dieser Optionen kontrolliert mehrere individuelle Parameter, die jeweils in der Datei darktablerc in darktables Konfigurationsverzeichnis definiert sind. Du kannst jeden davon auch direkt in der darktablerc-Datei verändern, um Werte für deine gewünschte Ressourcezuweisung zu optimieren. Die Definition einer benutzereigenen Option für Ressourcenzuweisung , die in der Einstellung gewählt werden könnte, ist allerdings nicht möglich.

Jede der vier Optionen zur Ressourcenzuweisung ist wie folgt definiert:

Standard=512 8 128 700
groß=700 16 128 900
klein=128 4 64 400

Die Optionen werden in der Form Ressourcenzuweisung=a b c d dargestellt, wobei a - d wie folgt definiert werden:

a. Systemspeicher für die Bearbeitung mit Modulen: der maximale Anteil des Systemspeichers, der für die Bearbeitung von Modulen bereitgestellt wird. Kleinere Werte bewirken, dass speicherhungrige Module vermehrt mit Kacheln bearbeiten. Der Wert gibt die Größe des Speichers in 1024tel des gesamten Hauptspeichers an. So ist zum Beispiel in einem System mit 16 GB Systemspeicher der Speicheranteil mit der Standard-Ressourcenzuteilung (in GB) 16 * 512 / 1024, oder 8GB von System RAM.
b. Minimale Puffergrösse zum Kacheln: Die minimale Grösse eines Puffers zum Kacheln wird als Bruchteil des gesamten Systemspeichers definiert. Zum Beispiel ist bei einem System mit 16GB Systemspeichers die Höhe des zugewiesenen Speichers mit der Standard Ressourcenzuteilung (in GB) der Wert des zugewiesenen Speichers 16 * 8 / 1024oder 0.125GB des System RAM. Beachte, dass diese Einstellung zur Hauptsache historisch ist und praktisch nicht mehr verwendet wird – es wird geraten, den Standardwert beizubehalten.
c. Cache Memory für die Miniaturansichten: Die Grösse des Speichers für den Cache der Miniaturansichten. Auch dieser wird als Bruchteil des System-Memory ausgedrückt. Auf einem 16GB-System ist die zugeteilte Grösse durch die Standard Ressource 16 * 128 / 1024, oder 2GB des System RAM.
d. OpenCL (GPU)-Speicher: Der maximale Anteil des GPU Memory, der für Bearbeitung mit Modulen zur Verfügung gestellt wird. Wie mit dem System Memory, bewirken niedrigere Werte, die Bearbeitung von speicher-hungrigen Modulen, vermehrt mit einer steigenden Zahl von Kacheln zu arbeiten. Deine GPU Memory wird wohl auch für andere Applikationen deines Systems genutzt werden. Jedoch kann deine GPU, im Gegensatz zum System Memory, nicht von einem Swap-Betrieb profitieren und es ist unmöglich für darktable zu wissen, wie viel Speicher genau zu diesem Zeitpunkt zur Verfügung steht. Wenn der Wert zu hoch angesetzt wird, kann es sein, dass darktable auf eine CPU-Bearbeitung zurückfällt (die natürlich bedeutend langsamer ist, aber stabil mit korrekt prozessierten Daten) oder darktable wird abstürzen oder sogar dein System unbrauchbar machen. Deshalb beinhaltet der Anteil der GPU Memory einen Freiraum von 600MB Speicher, um eine zu hohe Zuteilung zu vermeiden. Zum Beispiel wird bei einer GPU von 6GB Memory darktable ungefähr (6 - 0.6) * 700 / 1024, oder 3.5GB vom GPU RAM beim Niveau der Standard Ressource.

Zusätzlich zu den Ressourcenzuweisungen, die in der Benutzeroberfläche angezeigt werden, können noch die folgenden Optionen in der Befehlszeile gesetzt werden (z.B. darktable --conf resourcelevel="notebook"). Diese Modi sind zur Fehlersuche bei Problemen mit der Kachelung und bei Performance-Tests von gewöhnlichen Systemen auf grösseren Entwicklermaschinen gedacht. Dabei gibt es die folgenden Optionen:

“mini” (1GB RAM, 2MB Einzelpuffer, 128MB Cache für Miniaturanzeigen, 200MB OpenCL-Speicher)
“notebook” (4GBRAM, 32MB Einzelpuffer, 512MB Cache für Miniaturanzeigen, 1GB OpenCL-Speicher)
“reference” (8GB RAM, 32MB Einzelpuffer, 512MB Cache für Miniaturanzeigen, 2GB OpenCL-Speicher)
“common2026” (16GB RAM, 64MB Einzelpuffer, 1GB Cache für Miniaturanzeigen, 5.5GB OpenCL-Speicher)

🔗Abstimmung des GPU-Speichers

Wenn du mit OpenCL das Beste aus deinem GPU-Speicher herausholen willst, hast du zwei Optionen:

Wähle den Ressourcenlevel “Groß”. Bei einer Graphikkarte mit 6GB wird das ca. 5GB an GPU-Speicher beanspruchen, 1 GB bleibt für den Rest des Systems zur Verfügung (empfohlen).
Ändere darktablerc, um die letzte Zahl (den OpenCL Memory-Anteil) für deinen ausgewählten Level zu vergrössern. Zum Beispiel, ein Erhöhen des Anteils des OpenCL Memory auf 950 würde das zur Verfügung stehende Memory auf einer 6GB GPU auf ungefähr 5.3GB erhöhen (wird ausdrücklich nicht empfohlen).

🔗Abgestimmte OpenCL- und CPU-Kachelung

Ein Verarbeitungsmodul das eine leistungsstarken GPU nutzt (OpenCL-Ausführung) ist meist viel schneller als wenn das gleiche Modul die CPU nutzt. Jedoch verwenden viele Nutzer schnelle Multi-Core-CPUs mit viel Arbeitsspeicher (RAM) zusammen mit einer nicht so starken GPU (typischerweise integrierte Onboard-Grafik mit wenig zugewiesenem Speicher). Die Nutzung von OpenCL kann in solchen Fällen zu exzessivem Kacheln führen. So es ist oft besser, ein Modul ohne Kachelung mit der CPU anstatt mit OpenCL und starker Kachelung zu verwenden.

Während der Verarbeitung der Pipeline versucht darktable die zu erwartenden Rechnerleistung für OpenCL- und GPU-Berechnungen abzuschätzen, um für ein gebenes Modul die beste Wahl zu treffen. In den meisten Fällen wird OpenCL bevorzugt, auch wenn ein Bild dafür gekachelt werden muss, da OpenCL normalerweise viel schneller läuft als der CPU-Code (manchmal bis zu 10 mal schneller bei spezifischen Karten).

Wenn das Verhältnis der geschätzten Leistung (CPU vs. GPU) größer wird als der advantage hint (siehe unten), wird darktable die CPU für die Verarbeitung dieses Moduls nutzen, sonst die GPU.

🔗Gerätespezifische Konfiguration von OpenCL

Die darktable Standardeinstellungen, führen auf den meisten Systemen zu einer annehmbaren Grafikperformanz. Wenn du aber selber noch zusätzlich optimieren möchtest, zeigt dieser Abschnitt die Beschreibung der relevanten Konfigurationsparameter (welche alle in deiner darktablerc Datei gesetzt werden).

Die meisten Optionen im Zusammenhang mit OpenCL mit einer “pro Gerät”-Strategie gemanagt. Die Konfigurations-Parameter sehen für jedes Gerät so aus:

cldevice_v7_rusticlamdradeon8060sgraphics=events:on asyncmode:off device:on unifraction: 0.250

oder allgemeiner

cldevice_version_canonicalname=events:on/off asyncmode:on/off device:on/off unifraction: float

Für jedes neu gefundene Gerät wird beim Start von darktable beim ersten Mal ein Eintrag wird in darktablerc erzeugt und mit der korrekten Canonical-Gerätenummer und Versionsnummer versehen. Die Parameter werden wie folgt definiert und können manuell angepasst werden.

events:: on = verwende OpenCl-Events beim Aufruf von Enqueue-Kernels (standard); off = nicht verwenden; Dieses Kennzeichen steuert die Verwendung von OpenCL-Events beim Aufruf von Enquque-Kernels.
asynchroner Modus: on = asynchronen Modus verwenden; 0 = nicht verwenden (Standard)_; Dieses Flag steuert, wie oft darktable die OpenCL-Pixelpipe blockiert, um einen Status über Erfolg/Fehler der ausgeführten Kernel zu erhalten. Setzen Sie dies für eine optimale Latenz auf on, damit darktable die Pixelpipe asynchron ausführt und versucht, so wenig Interrupts/Events wie möglich zu verwenden. Wenn OpenCL-Fehler wie fehlerhafte Kernel auftreten, setzen Sie den Parameter auf off zurück. Dies führt dazu, dass darktable nach jedem Modul unterbrochen wird, sodass Sie Probleme leichter eingrenzen können. Es wurden Probleme mit einigen älteren AMD/ATI-Karten (wie der HD57xx) gemeldet, die eine verstümmelte Ausgabe erzeugen können, wenn dieser Parameter auf on gesetzt ist. Belassen Sie im Zweifelsfall den Standardwert off.
Gerät: on = Gerät aktivieren; off = Gerät deaktivieren; Wenn darktable ein fehlerhaftes Gerät erkennt, wird es automatisch als solches markiert, indem dieser Parameter auf off gesetzt wird. Wenn du ein Gerät hast, das viele Fehler meldet, kannst du es manuell deaktivieren, indem du dieses Feld auf off setzst. Falls darktable das Gerät abgeschaltet hat, aber du der Meinung bist, es sollte eingesetzt werden, dann gib es wieder frei, indem du dieses Feld auf on setzest.
Unifraction: Der Wert “unifraction” ist ein Gleitkommawert und kann vom Benutzer im Bereich von 0,02 bis 0,5 festgelegt werden (Standardwert: 0,25). Einige OpenCL-Geräte haben keinen zugeteilten Speicher, sondern teilen diesen mit der CPU – Apple ARM silicon ist so ein Beispiel, aber auch eingebaute Geräte von Intel, AMD oder ARM SOCs. Da wir aber den Systemspeicher zum Caching oder für Codepaths der CPU bereithalten wollen, beschränken wir den Anteil des gesamten Speichers an diese Fraktion. Mit einem Wert von 0.5 und einem Apple-Computer mit 16GB System-RAM, könnte OpenCL 8GB verwenden.

Hinweis: Wenn darktable einen “fehlerhaften” Gerätekonfigurationsschlüssel entdeckt, wird er auf die Standardwerte zurückgesetzt.

🔗Gerätespezifische Deaktivierung von OpenCL

Es ist möglich, ein OpenCL-Gerät für bestimmte Module zu deaktivieren. Dazu werden die Module in einer durch Kommas getrennten Liste unter der Option nocl in der darktablerc-Datei eingetragen. Zum Beispiel:

cldevice_v7_rusticlamdradeon8060sgraphics_nocl=colorbalancergb,denoiseprofile

oder allgemeiner

cldevice_version_canonicalname_nocl=comma,separated,list,of,modules

Module in dieser Liste werden dann von der CPU anstelle mittels OpenCL ausgeführt.

🔗id-spezifische OpenCL-Konfiguration

Ein weiterer gerätespezifischer Konfigurationsschlüssel, der sowohl den Gerätenamen als auch die Geräteidentifikation berücksichtigt (falls zwei identische Geräte vorhanden sind), wird ebenfalls bereitgestellt. In diesem Fall folgt _idX (X ist der Identifikator) auf den üblichen Schlüsselnamen cldevice_version_canonicalname. Wenn also das obige Beispielgerät als Gerät 0 bezeichnet wurde, wäre die Konfigurationseinstellung (standardmäßig) cldevice_v7_rusticlamdradeon8060sgraphics_id0=headroom: 600.

Für diesen Konfigurationsschlüssel ist derzeit nur ein einziger Parameter definiert:

Headroom (Standard 600): Die Speichermenge (in MB), die von darktable während der OpenCL-Verarbeitung nicht verwendet wird. Diese Einstellung ist gültig, wenn du mehr als ein Gerät verwendest und die Einstellung optimierter GPU-Speicher aktiv ist.; Wenn Sie sicher sind, dass keine Apps (oder Ihr Betriebssystem) das spezifische Gerät verwenden, können Sie diesen Parameter für das ansonsten nicht verwendete Gerät auf 0 setzen, damit darktable den gesamten Speicher dieses Geräts verwendet.; Der Standardwert von 600 MB sollte für die meisten Systeme ausreichend sein. Wenn Sie feststellen, dass Leistungsprobleme auftreten, weil darktable auf CPU zurückfällt, versuchen Sie, es auf 800 zu ändern oder grösser zu ändern.

🔗andere Konfigurationsschlüssel

Die folgenden zusätzlichen Konfigurationsschlüssel sind auch in darktablerc verfügbar:

cldevice_version_canonicalname_building Diese Option wird bei der Kompilierung von OpenCL-Kernels verwendet und kann zur Verbesserung der Leistung oder als Workaround für Bugs verwendet werden. Damit die Einstellung effektiv wird, müssen alle existierenden Kernels gelöscht werden, damit sie mit der neuen Einstellung rekompiliert werden. Entferne die Option komplett, um mit Standardeinstellungen zu rekompilieren.

opencl_mandatory_timeout: default 400; Falls darktable irgendein OpenCL Gerät nutzen will, muss dieses für weiteren Gebrauch reservieren. Wenn dieses Gerät gegenwärtig genutzt wird, dann wird darktable waretn auf opencl_mandatory_timeout * 5ms bevor es auf die CPU zurückgreift. Hebe diesen Wert an, falls du es vorziehst OpenCL zu nutzen (weil deine Karte richtig schnell ist und deine CPU ist es nicht).