Optimierung der Performance

Es gibt eine Anzahl von Konfigurations-Parametern in $HOME/.config/darktable/darktablerc, die helfen können die Open CL Performance deines Systems fein abzustimmen: Performance in diesem Zusammenhang bedeutet meistens die Latenzzeit von darktable während des interaktiven Arbeitens (z.B. wie lange es geht, um die Pixelpipe aufzuarbeiten). Für ein komfortables Arbeiten ist es wichtig, die Latenzzeit kurz zu halten.

Um Informationen über das Profilieren zu erhalten, musst du darktable vom Terminal neu starten mit darktable -d opencl -d perf.

Nach jedem Abarbeiten der Pixelpipe – verursacht durch Modul-Parameter-Änderungen, zoomen, schwenken, etc. – 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. Bitte beachte, dass die angegebenen Zeiten für alle individuellen Module unzuverlässig sind, wenn die Open CL Pixelpipe asynchron läuft, (siehe opencl_async_pixelpipe unten).

Um eine schnelle Abarbeitung der Pixelpipe mit OpenCL zu gewährleisten, ist es essentiell, dass wir die GPU arbeiten lassen. Jegliche Unterbrechung oder stockender Datenfluss verlängert die Verarbeitungszeit. Dies ist besonders wichtig für die kleinen Bildpuffer, mit denen wir bei der interaktiven Tätigkeit zu tun haben. Diese können rasch von einer schnellen GPU verarbeitet werden. 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 ausschließlich von unseren Algorithmen und den Pferdestärken deiner Grafikkarte bestimmt. Kurze Unterbrechungen werden keine merkliche Auswirkung auf die Dauer des Exports haben.

darktable hat Standardeinstellungen, die auf den meisten Systemen zu einer annehmbaren Grafikperformanz führen sollten. Wenn du aber selber etwas daran herumschrauben und die Dinge noch ein wenig optimieren möchtest, folgt hier eine Beschreibung der relevanten Konfigurationsparameter.

opencl_async_pixelpipe
dieser Statusindikator (flag) beeinflusst wie oft darktable die OpenCL Pixelpipe blockiert, um den Status hinsichtlich Erfolg/Fehler der gestarteten Kerne zu erhalten. Für eine optimale Latenzzeit setze diesen auf TRUE (wahr), so dass darktable die Pixelpipe asynchron abarbeitet und so wenig wie möglich Interrupts benutzt. Wenn es zu OpenCL-Fehlern kommt wie fehlgeschlagenen Kernen (kernels), setze den Parameter auf FALSE (falsch, unwahr). darktable wird dann nach jedem Modul unterbrechen, sodass du das Problem leichter isolieren kannst. Probleme wurden von einigen älteren AMD/ATI-Karten berichtet, wie der HD57xx, die dann ein verstümmeltes Output produzieren, wenn dieser Parameter auf TRUE gesetzt ist. Im Zweifel lasse ihn auf dem Standard FALSE eingestellt.

opencl_number_event_handles Event handles werden benutzt, damit darktable den Erfolg/Fehler von Kernen und Profilierungsinformationen monitoren kann, selbst wenn die Pixelpipe asynchron abgearbeitet wird. Die Anzahl der Event handles ist eine begrenzte Resource deines OpenCL-Treibers. Selbstverständlich können diese recycled werden, aber es gibt nur eine begrenzte Anzahl, die gleichzeitig benutzt werden kann. Unglücklicherweise gibt es keine Möglichkeit herauszufinden, wo die Begrenzung dieser Resource ist, daher muss darktable dies schätzen. Der Standardwert von 25 ist ziemlich konservativ. Vielleicht möchtest du ausprobieren, ob höhere Werte wie 100 zu einer besseren OpenCL-Leistung führen. Wenn dein Treiber keine freien handles mehr bereitstellen kann, wirst du versagende OpenCL-Kerne mit dem Fehlercode -5 (CL_OUT_OF_RESOURCES), oder sogar Abstürze oder ein Einfrieren des Systems, bemerken. Wenn das geschieht, reduziere wieder die Anzahl. Eine Eingabe von 0 verhindert, dass darktable überhaupt Event handles benutzt. Dies verhindert zwar, dass darktable deine OpenCL-Kerne ordnungsgemäß überwachen kann, spart andererseits aber auch Treiber-Overhead. Die Konsequenz ist, dass jedweder Fehler zu einer verstümmelten Darstellung führt, ohne dass darktable dies merkt. Dies wird nur empfohlen, wenn du sicher weißt, dass dein System absolut stabil läuft. Du kannst diesen Parameter auch auf -1 setzen, was bedeutet, dass darktable davon ausgeht, dass es keine Beschränkung hinsichtlich der Anzahl der Event handles gibt. Dies wird nicht empfohlen.

opencl_synch_cache Dieser Parameter, wenn auf “true” gesetzt wird darktable forcieren nach jedem Modul Bilder-Buffer aus der GPU zu holen und diese im Cache der Pixelpipe speichern. Das ist eine Ressourcen-hungrige Operation, kann aber Sinn ergeben, je nach deiner GPU (auch wenn die GPU eher langsam ist). In diesem Fall könnte darktable tatsächlich Zeit sparen, wenn Modul-Parameter geändert haben, da es zu einem gecachten Zwischenstatus zurückgehen kann und nur den Teil der Pixelpipe neu bearbeiten. In vielen Fällen sollte dieser Parameter auf “aktives Modul” (Standard) gesetzt werden, was nur den Input des gegenwärtig fokussierten Moduls cached.

opencl_micro_nap
In einem Idealfall wirst du deine GPU 100 % am Laufen halten, wenn die Pixelpipe aufgearbeitet wird. Das ist gut. Andererseits könnte es auch sein, dass deine GPU auch für andere Aufgaben gebraucht werden könnte, um reguläre GUI Updates zu machen. Es könnte dann sein, dass dafür nicht genügend Zeit bleibt. Die Konsequenz würde eine ruckartige Reaktion deines GUI sein beim Panning, 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 opencl_micro_nap kontrolliert die Dauer dieser Unterbrechungen in Mikrosekunden. Du musst für dein System mit experimentieren einen Optimalwert finden. Werte von 0, 100, 500, und 1000 sind gute Anfangspunkte, um damit anzufangen. Der Standardwert ist 1000.
opencl_use_pinned_memory
Während des Kachelns müssen große Mengen von Speicher zwischen System- und Grafikspeicher hin- und herbewegt werden. Auf gewissen Prozessoren (namentlich AMD) können direkte Speicher-Bewegungen zu und von einem beliebigen System-Speicher-Platz zu einer großen Einbuße der Leistungsfähigkeit führen. Das wird besonders augenfällig beim Export von großen Bildern. Das Setzen dieses Parameters auf TRUE teilt darktable für Datenübertragungen zu Gast-Speichern spezielle Arten von Zwischenspeicher zu nutzen. Auf gewissen Konfigurationen kann dies den Export von großen Dateien um den Faktor 2 bis 3 beschleunigen. NIVIDIA Prozessoren und Treiber scheinen eine effizientere Datenübertragungstechnik sogar für beliebige Speicherregionen zu haben. Da sie keinen Leistungsgewinn aufzeigen und eventuell sogar verstümmelte Ausgaben produzieren, sollte opencl_use_pinned_memory Standard FALSE belassen werden.
OpenCL_building_gpuXXX
Addiere diese Einstellung zu darktablerc, um Extra-Optionen von OpenCL zum Kompilieren deiner GPU(s), bei denen der Name XXX ist. Diese Optionen werden für das Kompilieren von OpenCL-Kernels genutzt und können für die Feineinstellung oder für die Umgehung von Bugs vorgesehen werden. Du musst existierende Kernels entfernen, um diese mit neuen Optionen erneut zu kompilieren. Sehe einen leeren String vor, um ohne Optionen zu rekompilieren. Entferne die Einstellung komplett, um mit Standard-Optionen zu kompilieren.

Du kannst deine GPU mit deren ID referenzieren (z.B. opencl_building_gpu0) oder mit seinem kanonischen Namen (e.g. opencl_building_gpugeforce10606gb). Starte darktable mit darktable -d OpenCL, u deinen kanonischen Namen und die Standard-Kompilier-Optionen zu finden.

Zum Beispiel würden die folgenden Linien Extra-Kompilation-Optionen für die GPU mit ID 0 und für die GPU mit Namen “geforce10606gb” hinzufügen:

opencl_building_gpu0=-cl-mad-enable -cl-no-signed-zeros -cl-unsafe-math-optimizations -cl-finite-math-only -cl-fast-relaxed-math
opencl_building_gpugeforce10606gb=-cl-mad-enable -cl-no-signed-zeros

translations