Speicher- und Leistungseinstellungen

🔗Speicheranforderungen

Die Verarbeitung eines RAW-Bildes in darktable braucht sehr viel Arbeitsspeicher. Eine ganz einfache Rechnung kann das zeigen: Für ein Bild mit 20 Megapixel braucht darktable eine 4x32 Bit Fliesskomma-Zelle, um eine einzelnes Pixel zu speichern, sodass jedes Bild dieser Grösse deshalb ca. 300 MB Speicher erfordern, nur um die Bilddaten zu speichern. Um dieses Bild nun in einem bestimmten Modul zu bearbeiten, braucht darktable zwei Pufferspeicher dieser Grösse (für Ein- und 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 während der Pixelpipe-Ausführung daher zwischen 600MB und 3 GB von Speicher benötigt, nur um die Bilddaten zu speichern und zu bearbeiten. Dazu kommt noch der Programm-Code von darktable, der Code und die Daten aller dynamisch verbundenen Libraries, und auch zusätzlicher Puffer, in den darktable Zwischenstände für einen schnellen Zugriff während des interaktiven Arbeits abspeichert (Cache).

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

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 / memory and others need to be modified directly in darktable’s configuration file (found in $HOME/.config/darktable/darktablerc).

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.

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 in the pixelpipe and you should use this to assess your changes.

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

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

Beachte: Der Modus unrestricted umfasst “wirklich alles”. Das wird für die Nutzung die beste Einstellung sein, kann aber, speziell beim Export von grossen Bilddateien in hoher Qualität bei uneingeschränktem Speicher zu Swapping führen, was zu einer beeinträchtigten Leistung oder darktable wird einfach vom System abgeschaltet.

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 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 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 (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 (unbedingt empfohlen).
Set preferences > processing > OpenCL > use all device memory to “on”, which will use all of your device’s memory, less a 600MB headroom. Please see the section below for “per device setting” of headroom.

🔗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_v5_nvidiacudaquadrortx4000=0 250 0 16 16 128 0 0 0.000 0.000 0.500

oder allgemeiner

cldevice_version_canonicalname=a b c d e f g h i j k

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 - k werden wie folgt definiert und können manuell angepasst werden.

a. avoid atomics: 1 = vermeide atomics; 0 = nutze atomics (Standard); 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 allen üblichen Systemen bist du mit dem Standardwert sicher. Falls du Mehrfach-Geräte verwendest oder du nutzt nicht deine diskrete Grafikkarte zum Zeichnen auf dem Bildschirm, kann dieser Wert auf 0 gesetzt werden für alle nicht Desktop Geräte, was zu einer besseren Leistung führt.
c. gepinnter Speicher: _0 = deaktiviere gepinnter Transfer (Standard); 1= erzwinge gepinnter Transfer _; 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ärfe oder Geführter Laplacian-Modus im Modul Spitzlicht-Rekonstruktion verwendet werden.; Es gibt keine sichere Methode oder allgemeine Regel, um vorherzusagen, ob dieser Parameter einen Leistungsvorteil bringt oder nicht, also musst du selbst experimentieren. Jedoch ist die Chance, dass der gepinnte Transfer eine Verbesserung erbringt, sehr klein ist, falls deine Karte nach 2015 hergestellt wurde.
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: Voreinstellung 128; 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 (da darktabledie API von OpenCL V.1.2 zur Unterstütung aller Plattformen nutzt), daher verwendet darktable standardmäßig eine konservative Schätzung von 128 als Standard. Auf den meisten aktuellen Geräten und Treibern können Sie davon ausgehen, dass eine Zahl von bis zu 1024 sicher ist (sobald der Treiber bzw. die Karte OpenCL V.2.0 oder größer nutzt) und zu etwas besserer 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. (Sobald dieses Problem auftritt, bitte auf Github einen Fehlerbericht einstellen.); 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 wenig besseren Leistung führt (unter 5%). 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 (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 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 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. 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 0 setzest.

i. reserved

j. advantage hint: Definiert den “advantage hint”-Wert, der im Abschnitt Abstimmung zwischen OpenCL und CPU-Kachelung beschrieben wird. Bei einer schnellen Grafikkarte mit viel Speicher kann ohne weiteres der Standardwert 0.000 beibehalten werden. Wenn der Wert an den eigenen Rechner angepasst werden soll, ist folgendes zu tun:

darktable mit Kachelung-Debugging starten (darktable -d tiling) und ein Bild in Dunkelkammer bearbeiten. Das Modul Spitzlicht-Rekonstuktion öffnen, “Geführter Laplacian-Modus” auswählen, den “Durchmesser der Rekonstruktion” auf einen hohen Wert setzen, ohne dass die Debugging-Information im Terminal während der Regleranpassung ein Kachelung anzeigt.
Die Ausführungszeiten dieses Moduls mit ein- bzw. ausgeschaltetem OpenCL vergleichen (mit darktable -d perf die Performance ermitteln).
Der Wert für “advatage hint” sollte ungefährt auf das Verhältnis CPU-Ausführungszeit / GPU-Ausführungszeit gesetzt werden.

k. shared memory fraction: Gewisse 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. So mit dem Standard von 0.5 und einem Apple-Computer mit 16GB System-RAM, könnte OpenCL 8GB für sich brauchen.

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äteidentifikation berücksichtigt (falls zwei identische Geräte vorhanden sind). 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 zweite Konfigurationseinstellung (standardmäßig) cldevice_v5_quadrortx4000_id0=600.

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

forced headroom (default 600): The amount of memory (in MB) that will not be used by darktable during OpenCL processing. This setting is only valid if you set preferences > processing > OpenCL > use all device memory to “on”.; 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 zum Kompilieren von OpenCL-Kerneln verwendet und wird zur Leistungsoptimierung oder zur Umgehung von Fehlern bereitgestellt. Alle vorhandenen Kernel müssen entfernen werden, um sie mit den neuen Optionen neuzukompilieren. Mit leerer Zeichenfolge wird der Kernel ohne Optionen neukompiliert. Ohne Einstellung wird der Kernel mit den Standardoptionen neukompiliert. Der Standard ist -cl-fast-relaxed-math für NVIDIA-Treiber. Alle anderen Karten haben keine solche Kompileroption.; -cl-fast-relaxed-math verbessert die Performanz signigikant, doch ändern sich Berechnungen, die möglicherweise zu anderen Ergebnissen führen. Aktuelle Intel-Implementationen dieser Kompileroption erzeugen sichtbar falsche Ergebnisse. Mit AMD-Karten sind die Ergebnisse uneinheitlich. Einige Karten/Treiber-Kombinationen funktionieren, andere nicht. Da sich AMD-Treiber ständig ändern, wird die Option für AMD-Karten nicht empfohlen.
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).