Memory und Leistungs-Optimierung

🔗Memory Anforderungen

Die Bearbeitung eines RAW Bildes in darktable braucht sehr viel Speicher. Eine ganz einfache Rechnung kann das zeigen: FĂŒr eine 20 Megapixel-Bild braucht darktable eine 4x32-bit Fliesskomma-Zelle, um jedes Pixel zu speichern, was bedeutet, jedes ganze Bild dieser Grösse wird deshalb ca 300 MB Speicher erfordern, um die Bilddaten zu speichern. Um dieses Bild nun tatsĂ€chlich in einem bestimmten Modul zu bearbeiten, braucht darktable zwei Pufferspeicher dieser Grösse (fĂŒr die Eingabe und fĂŒr die Ausgabe). Wenn wir ein komplexeres Modul haben, werden dessen Algorithmen zusĂ€tzlich mehrere zusĂ€tzliche Speicher fĂŒr Zwischendaten erfordern. Ohne zusĂ€tzliche Optimierung, werden so irgendetwas zwischen 600MB und 3 GB von Speicher werden nötig sein, nur um die Bilddaten zu speichern und die Bilddaten zu bearbeiten. DarĂŒber hinaus haben wir noch darktables Code Segment, den Code und die Daten aller dynamisch verbundenen Libraries, und auch zusĂ€tzlicher Puffer, dort wo darktable Bilder fĂŒr einen schnellen Zugriff wĂ€hrend dem Interaktiven arbeiten, zwischenspeichert (cache) fĂŒr einen schnellen Zugriff beim interaktiven Arbeiten..

Zusammen erfordert darktable mindestens 4GB physikalisches RAM plus 8GB zusĂ€tzlichen Speicher fĂŒr die Auslagerung, aber es wird besser laufen, je mehr Speicher du hast.

Wie auch mit der AusfĂŒhrung in der CPU, haben viele Module von darktable Implementationen von OpenCL, um die Vorteile von parallelen Verarbeitungen deiner Grafikkarte (GPU) mitzunehmen. Ähnlcih auch ier, je mehr GPU Speicher du hast, umso besser wird darktable laufen.

🔗Kacheln

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, in 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 zwar die Bearbeitung von Bildern mit einem viel kleineren Speicher ermöglicht, gibt es auch Nachteile:

  • Kacheln ist immer langsamer – oft bis zu 10x langsamer, obwohl fĂŒr gewisse Module der Unterschied vernachlĂ€ssigbar ist,

  • Kacheln ist fĂŒr gewisse Module technisch wegen der nötigen 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, mit effizienteren interaktiven Prozessen in der Dunkelkammer. FĂŒr die beste Performance (und um Kacheln zu verhindern), solltest du darktable mit möglichst wenigen andern Applikationen parallel laufen lassen und darktable dahingehend konfigurieren, so viel des GPU Memory zu nutzen wie möglich.

🔗Abstimmung der Performance

Es gibt eine Anzahl von Konfigurationsparametern, die helfen, die Performance des Systems fein abzustimmen. Gewisse dieser Parameter sind zu finden in darktable Voreinstellungen > Bearbeiten > CPU/GPU/Speicher, aber andere mĂŒssen direkt in der Konfigurationsdatei von darktable (zu finden in $HOME/.config/darktable/darktablerc) modifiziert werden.

Dieser Abschnitt gibt dafĂŒr 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 Beispiel-Bilder und eine Methode zur Beurteilung der Geschwindigkeit der Pixelpipe,

FĂŒr Beispiel-Bilder empfiehlt es sich intensivere Module, wie zum Beispiel Diffusion SchĂ€rfe oder Entrauschen Profi. Exporte werden zwischen Pipe-Runs wohl mehr konsistente und vergleichbare Zeiten ergeben im Vergleich zu interaktiv arbeiten, sie werden aber auch die Hardware mehr fordern.

Um Informationen ĂŒber das Profilieren zu erhalten, musst du darktable vom Terminal neu starten mit darktable -d opencl -d perf. Falls du mehr Informationen ĂŒber Kacheln solltest du darktable -d opencl -d tiling -d perf nutzen.

Jedes Mal, wenn die Pixelpipe im Prozess ist (wenn du Modul-Parameter Ă€nderst, zoomen, schwenken, exportieren etc.) in der Session des Terminals wirst du die benötigte Gesamtzeit in der Pixelpipe und die benötigte Zeit in jedem der Open CL Kernels. Der zuverlĂ€ssigste Wert ist die benötigte Zeit in der Pixelpipe und du solltest das fĂŒr die Bewertung heranziehen.


Beachte: Die Zeitmessungen fĂŒr jedes einzelne Modul sind unzuverlĂ€ssig, wenn die Pixelpipe der OpenCL asynchron laufen (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 stockender Datenfluss verlĂ€ngert die Verarbeitungszeit. Dies ist besonders wichtig fĂŒr die kleinen Bildpuffer, die wĂ€hrend dem interaktiven Arbeiten gebraucht werden, welche 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 PferdestÀrken 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/GPU/Speicher) erlaubt es dir zwischen vier unterschiedlichen Herangehensweisen die Ressourcen an darktable zuzuweisen. Jede dieser Optionen kontrolliert viele individuelle Parameter, die jeder fĂŒr sich definiert sind, in $HOME/.config/darktable/darktablerc. Du kannst jeden davon in deiner darktablerc Datei, um Werte fĂŒr deinen Level von Ressourcen zu optimieren, obwohl du auch deinen Ressourcen-Level aus der Dropdown Liste hinzufĂŒgen kannst.

Jede der vier “Ressourcen von darktable”-Optionen werden wie folgt definiert:

Ressource_Standard=512 8 128 700
Ressource_gross=700 16 128 900
Ressource_klein=128 4 64 400
Ressource_unbeschrÀnkt=16384 1024 128 900

Allgemeiner können dies auch vorgestellt werden als Ressource_level=a b c d worin a - d wie folgt definiert werden:

a. Systemspeicher fĂŒr die Bearbeitung von Modulen
der maximale Teil des Systemspeichers wird fĂŒr die Bearbeitung von Modulen bereitgestellt. Kleiner Werte bewirken, dass speicherhungrige Module vermehrt mit Kacheln bearbeiten. Diese Zahl ist ein Teil des Gesamtwertes des System-Speichers geteilt durch 1024. Zum Beispiel in einem System mit 16 GB Systemspeicher, ist der Teil der als Standard-Ressource (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 Fraktion des gesamten Systemspeichers. Zum Beispiel wird bei einem System mit 16GB Systemspeichers ist die Höhe der zugewiesenen durch Standard Ressource (in GB) ist 16 * 8 / 1024, oder 0.125GB des System RAM. Beachte, dass diese Einstellung zur Hauptsache historisch und praktisch nicht mehr lĂ€nger in Betrieb ist – es wird geraten, das beim Standard zu belassen.
c. Cache Memory fĂŒr die Miniaturansichten
Die Grösse des Memory fĂŒr das Cache der Miniaturansichten. Auch das wird ausgedrĂŒckt als Bruchteil des System-Memory, und auf einem 16GB System ist die zugeteilte Grösse durch Standard Ressource ist 16 * 128 / 1024, oder 2GB des System RAM.
d. speicher fĂŒr OpenCL
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 wird schwierig 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). Deshalb beinhaltet der Anteil der GPU Memory einen Freiraum von 400MB Speicher, um eine zu hohe Zuteilung zu vermeiden. Zum Beispiel wird bei einer GPU von 6GB Memory darktable ungefĂ€hr (6 - 0.4) * 700 / 1024, oder 3.8GB vom GPU RAM beim Niveau der Standard Ressource.

ZusÀtzlich zu den Anteilen der Ressourcen, 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 Kacheln-Störungen da und bei der Test-Performance von gewöhnlichen Systemen auf grösseren Entwickler-Maschinen. Dabei gibt es die folgenden Optionen:

  • “mini” (1GB RAM, 2MB Einzel-Speicher, 128MB Miniaturanzeigen-Cache, 200MB OpenCL memory)

  • “notebook” (4GBRAM, 32MB Einzel-Speicher, 512MB Miniaturanzeigen-Cache, 1GB OpenCL memory)

  • “reference” (8GB RAM, 32MB Einzel-Speicher, 512MB Miniaturanzeigen Cache, 2GB OpenCL memory)

🔗Abstimmung des Gebrauches des GPU Memory

Wenn du mit OpenCL das Beste aus deinem GPU Memory herausholen willst, hast du drei Optionen:

  • WĂ€hle den Ressourcenlevel “Gross”. FĂŒr eine 6GB Karte wird das ca. 5GB an GPU Memory beanspruchen, 1 GB bleibt fĂŒr den Rest des Systems zur VerfĂŒgung.

  • Ä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.

  • Setze in darktable Voreinstellungen > Bearbeitung > CPU/GPU/Speicher > erhöhe OpenCL Performance auf “Memory-Grösse”, was dann das ganze Memory deines GerĂ€tes, minus 400MB Freiraum. Siehe dazu den Abschnitt unten fĂŒr zusĂ€tzliche Optionen zu diesen Einstellungen.

🔗GerĂ€tespezifische Konfiguration von OpenCL

Die darktable Standardeinstellungen, sollten auf den meisten Systemen zu einer annehmbaren Grafikperformanz fĂŒhren. 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).

Seit darktable 4.0 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_v4_quadrortx4000=0 250 0 16 16 1024 0 0 0.017853

oder allgemeiner

cldevice_version_canonicalname=a b c d e f g h i

Ein Eintrag wird in darktablerc fĂŒr jedes neu gefundene GerĂ€t beim Start von darktable beim ersten Mal mit der korrekten Canonical-GerĂ€tenummer und Versions-Nummer versehen. Die Parameter a - i werden wie folgt definiert und können manuell angepasst werden.

a. avoid atomics
1 = vermeide atomics; 0 = nutze atomics
Atomic Operationen sind in OpenCL eine spezielle Methode zur Datensynchronisierung und werden lediglich in wenigen Modulen verwendet. Leider sind einige alte AMD/ATI Karten extrem langsam bei der Verarbeitung von Atomics und fĂŒr diese Karten ist es besser, die betroffenen Module auf der CPU arbeiten zu lassen, statt eine ultra-langsame GPU Verarbeitung hinzunehmen. Setze diesen Parameter auf 1, wenn du eine langsamme Verarbeitung von Modulen wie Schatten und Lichter, Monochrome, lokaler Kontrast, oder globales tonemapping (veraltet) sehr langsam arbeiten oder der Rechner zwischenzeitlich nicht mehr reagiert. Beachte, dass das Karten nach 2015 nicht beeintrĂ€chtigen sollte.
b. micro nap
Standard 250
In einem Idealfall wirst du deine GPU 100 % am Laufen halten, wenn die Pixelpipe arbeitet. Wenn jedoch deine GPU auch fĂŒr auch deinen Bildschirm updaten muss, und darktable nutzt sie zu 100%, kann es sein, dass nicht genĂŒgend Zeit fĂŒr diese Aufgabe ĂŒbrig bleibt. Normalerweise wird das eine ruckartige Reaktion deines GUI sein beim Schwenken, beim Zoomen oder wenn Schieber bewegt werden. Um das zu lösen, kann darktable kleine Unterbrechungen im Abarbeiten der Pixelpipe einschieben, damit die GPU etwas relaxen kann und GUI bezogenen AktivitĂ€ten ausfĂŒhren kann. Der Parameter “micro nap” kontrolliert die Dauer dieser Unterbrechungen in Mikrosekunden. Bei gegenwĂ€rtigen Systemen bist du mit dem Standard-Wert sehr gut dran, sogar bei integrierten Grafikkarten. Wenn du VielfachgerĂ€te nutzest oder du nutzest dein diskretes GerĂ€t fĂŒr zum Zeichnen auf deinem Bildschirm, kann der Wert fĂŒr das nicht Desktop GerĂ€t auf 0 gesetzt werden.
c. gepinnter Speicher
0 = GUI verwenden, um den Modus auszuwĂ€hlen; 1 = gepinnte Übertragung erzwingen; 2 = gepinnte Übertragung deaktivieren
Beim Kacheln mĂŒssen riesige Speichermengen zwischen Host und GerĂ€t ĂŒbertragen werden. Bei manchen GerĂ€ten können direkte SpeicherĂŒbertragungen zu und von einem beliebigen Host-Speicherbereich zu einer großen Leistungseinbuße fĂŒhren. Dies macht sich besonders bemerkbar, wenn große Bilder auf kleinere Grafikkarten exportiert werden oder neuere Module wie Diffusion / SchĂ€rfen oder gefĂŒhrter Laplacian Modus in dem Spitzlicht Rekonstruktion Modul verwendet werden.

Es gibt keine sichere Methode oder allgemeine Regel, um vorherzusagen, ob dieser Parameter einen Leistungsvorteil bringt oder nicht, also mĂŒssen Sie selbst experimentieren. Dieser Modus kann auch global eingestellt werden, indem Sie die Option „Abstimmen der Leistung von OpenCL“ auf „Speichertransfer“ setzen (in [darktable-Voreinstellungen > Bearbeitung > CPU/GPU/Speicher](../preferences-settings/processing.md#cpu–gpu –memory)), in diesem Fall sollte dieser Parameter auf 0 gesetzt werden. Andernfalls können Sie ihn mit diesem Parameter auf GerĂ€teebene aktivieren/deaktivieren.

d. clroundup wh / e. clroundup ht
Diese Parameter sollten auf diesem Standardwert belassen werden – Tests haben keinen Vorteil gezeigt, andere Werte zu verwenden.
f. Anzahl der Event-Handles
Event-Handles werden von darktable verwendet, um den Erfolg/Fehler von Kernels zu ĂŒberwachen und Profilinformationen bereitzustellen, selbst wenn die Pixelpipe asynchron ausgefĂŒhrt wird. Die Anzahl der Event-Handles ist eine begrenzte Ressource Ihres OpenCL-Treibers – obwohl sie recycelt werden können, gibt es eine begrenzte Anzahl, die gleichzeitig verwendet werden kann. Leider gibt es keine Möglichkeit, die Ressourcengrenzen fĂŒr ein bestimmtes GerĂ€t herauszufinden, daher verwendet darktable standardmĂ€ĂŸig eine sehr konservative SchĂ€tzung von 128. Auf den meisten aktuellen GerĂ€ten und Treibern können Sie davon ausgehen, dass eine Zahl von bis zu 1024 sicher ist und zu einer etwas besseren OpenCL-Leistung fĂŒhrt. Wenn Ihrem Treiber die freien Handles ausgehen, treten fehlgeschlagene OpenCL-Kernel mit der Fehlermeldung „CL_OUT_OF_RESOURCES“ oder sogar AbstĂŒrze oder Systemeinfrierungen auf.

Ein Wert von 0 verhindert, dass darktable Event-Handles verwendet. Dies verhindert, dass darktable den Erfolg Ihrer OpenCL-Kernel ordnungsgemĂ€ĂŸ ĂŒberwacht, spart jedoch etwas Treiber-Overhead, was zu einer besseren Leistung fĂŒhrt. Die Folge ist, dass alle Fehler wahrscheinlich zu einer verstĂŒmmelten Ausgabe fĂŒhren, ohne dass darktable es bemerkt. Dies wird nur empfohlen, wenn Sie sicher sind, dass Ihr System felsenfest lĂ€uft.

g. asynchroner Modus
1 = asynchronen Modus verwenden; 0 = nicht verwenden
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 1, 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 0 (Standardeinstellung) 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 1 gesetzt ist. Belassen Sie im Zweifelsfall den Standardwert 0.
h. GerÀt deaktivieren
0 = GerÀt aktivieren; 1 = GerÀt deaktivieren
Wenn darktable ein fehlerhaftes GerÀt erkennt, wird es automatisch als solches markiert, indem dieser Parameter auf 1 gesetzt wird. Wenn Sie ein GerÀt haben, das viele Fehler meldet, können Sie es manuell deaktivieren, indem Sie dieses Feld auf 1 setzen
i. Benchmark
Wenn darktable ein neues GerĂ€t auf dem System erkennt, fĂŒhrt es einen kleinen Benchmark durch und speichert das Ergebnis hier. Sie können diesen Wert auf 0 zurĂŒcksetzen, um darktable zu zwingen, den Benchmark erneut durchzufĂŒhren, aber in den meisten FĂ€llen sollten Sie diese Einstellung nicht Ă€ndern.

Note: Wenn darktable einen “fehlerhaften” GerĂ€tekonfigurationsschlĂŒssel entdeckt, wird er auf die Standardwerte zurĂŒckgeschrieben.


🔗id-spezifische OpenCL-Konfiguration

Ein zweiter gerĂ€tespezifischer KonfigurationsschlĂŒssel wird ebenfalls bereitgestellt, der sowohl den GerĂ€tenamen als auch die GerĂ€te-ID berĂŒcksichtigt (nur fĂŒr den Fall, dass Sie zwei identische GerĂ€te haben). In diesem Fall _idX folgt auf den ĂŒblichen SchlĂŒsselnamen cldevice_version_canonicalname, wobei X die GerĂ€te-ID ist. Wenn beispielsweise das obige BeispielgerĂ€t als GerĂ€t 0 bezeichnet wurde, wĂ€re die zweite Konfigurationseinstellung (standardmĂ€ĂŸig) cldevice_v4_quadrortx4000_id0=400.

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

erzwungener Headroom (Standard 400)
Die Speichermenge (in MB), die von darktable wĂ€hrend der OpenCL-Verarbeitung nicht verwendet wird. Diese Einstellung ist nur gĂŒltig, wenn Sie preferences > processing > tune OpenCL performance auf “memory size” setzen.

Wenn Sie diesen Parameter auf Null (0) setzen, wird darktable beim ersten Durchlauf einer Pixelpipe versuchen, festzustellen, wie viel GPU-Speicher tatsĂ€chlich verfĂŒgbar ist, und verwenden diesen (mit einer Sicherheitsspanne von 100 MB) als die maximale Speichermenge, die darktable fĂŒr den Rest seiner Sitzung verwendet. Dies ist normalerweise sicher, es sei denn, Sie starten andere Anwendungen (die eine Menge an GPU-Speicher verwenden), wĂ€hrend darktable ausgefĂŒhrt wird. Andernfalls könnte die Verwendung dieser Option Out-of-Memory Fehler verursachen, die dazu fĂŒhren, dass darktable auf die CPU zurĂŒckgreift und die Leistung erheblich verringert. Sie können diese Option aus- und wieder einschalten, um darktable zu veranlassen, seine Speicherberechnung erneut durchzufĂŒhren (zu Beginn des nĂ€chsten Pipe-Runs). Beachten Sie, dass es bekannte Probleme mit der automatischen Speichererkennung bei neueren Nvidia-Treibern gibt, daher sollte die automatische Erkennung mit Vorsicht verwendet werden und ist daher standardmĂ€ĂŸig deaktiviert.

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 1 setzen, damit darktable den gesamten Speicher dieses GerĂ€ts verwendet.

Der Standardwert von 400 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 600 zu Ă€ndern oder “auf SpeichergrĂ¶ĂŸe abstimmen” zu deaktivieren.

🔗andere KonfigurationsschlĂŒssel

Die folgenden zusĂ€tzlichen KonfigurationsschlĂŒssel sind auch in darktablerc verfĂŒgbar:

cldevice_version_canonicalname_building
Diese Option wird beim Kompilieren von OpenCL-Kernels verwendet und kann zur Leistungsoptimierung oder zur Umgehung von Fehlern bereitgestellt werden. Sie mĂŒssen alle vorhandenen Kernel entfernen, um sie mit den neuen Optionen neu zu kompilieren. Geben Sie eine leere Zeichenfolge an, um Kernel ohne Optionen neu zu kompilieren. Entfernen Sie die Einstellung vollstĂ€ndig, um Kernel mit den Standardoptionen neu zu kompilieren. Der aktuelle Standardwert ist -cl-fast-relaxed-math.
opencl_synch_cache
Wenn dieser Parameter auf „true“ gesetzt ist, zwingt er darktable, Bildpuffer von Ihrer GPU nach jedem Modul abzurufen und sie in seinem Pixelpipe-Cache zu speichern. Dies ist ein ressourcenintensiver Vorgang, kann aber je nach GPU sinnvoll sein (auch wenn die GPU eher langsam ist). In diesem Fall kann darktable tatsĂ€chlich etwas Zeit sparen, wenn sich Modulparameter geĂ€ndert haben, da es zu einem zwischengespeicherten Zwischenzustand zurĂŒckkehren und nur einen Teil der Pixelpipe erneut verarbeiten kann. In vielen FĂ€llen sollte dieser Parameter auf “active module” (Standardeinstellung) eingestellt werden, wodurch nur die Eingabe des aktuell fokussierten Moduls zwischengespeichert wird.

translations