Ansel entdeckt OpenCL-Laufzeitfehler automatisch. Nach einem Fehler wird alles erneut über die CPU berechnet. Das verringert zwar die Verarbeitungsgeschwindigkeit, sollte aber nicht das Endergebnis ändern.
Es gibt unterschiedliche Gründe, warum OpenCL während der Initialisierung fehlschlägt. OpenCL hängt von den Hardware-Anforderungen ab und von gewissen Treibern und Bibliotheken. Zusätzlich müssen alle diese hinsichtlich Hersteller, Modell und Revisionsnummer zusammenpassen. Falls etwas nicht stimmt (z.B. der Grafiktreiber, als Kernel Modul geladen, passt nicht zur Version der libOpenCL.so), wird eine OpenCL-Unterstützung wohl nicht verfügbar sein.
In einem solchen Fall ist es das Beste, Ansel in einer Konsole mit Ansel -d opencl zu starten.
Dies liefert zusätzliche Debugging-Informationen zur Intialisierung und Verwendung von OpenCL. Zunächst zeigt eine Zeile, die mit [opencl_init] FINALLY ... beginnt, ob OpenCL-Unterstützung vorhanden ist oder nicht. Falls die Initialisierung misslingt, hilft die Suche nach Meldungen der Art could not be detected oder could not be created, und der Hinweis dort, was falsch lief.
Hier ein paar Fälle, die in der Vergangenheit beobachtet wurden:
Ansel states that no OpenCL aware graphics card is detected or that the available memory on your GPU is too low and the device is discarded. In that case you might need to buy a new card if you really want OpenCL support.
Ansel finds your
libOpenCL.sobut then tell you that it couldn’t get a platform. NVIDIA drivers will often give error code -1001 in this case. This happens becauselibOpenCL.sois only a wrapper library. For the real work further vendor-specific libraries need to be loaded. This has failed for some reason. There is a structure of files in/etc/OpenCLon your system thatlibOpenCL.soconsults to find these libraries. See if you can find something fishy in there and try to fix it. Often the required libraries cannot be found by your system’s dynamic loader. Giving full path names might help.Ansel states that a context could not be created. This often indicates a version mismatch between the loaded graphics driver and libOpenCL. Check if you have left-over kernel modules or graphics libraries from an older installation and take appropriate action. When in doubt, perform a clean reinstall of your graphics driver. Sometimes, immediately after a driver update, the loaded kernel driver does not match the newly installed libraries. In this case reboot your system before trying again.
Ansel crashes during startup. This can happen if your OpenCL setup is completely broken or if your driver/library contains a severe bug. If you can’t fix it, you can still use Ansel with option
--disable-opencl, which will skip the entire OpenCL initialization step.Ansel fails to compile its OpenCL source files at run-time. In this case you will see a number of error messages looking like typical compiler errors. This could indicate an incompatibility between your OpenCL implementation and Ansel’s interpretation of the standard. In that case please raise an issue on github and we will try to assist. Please also report if you see significant differences between CPU and GPU processing of an image.
When the GPU result differs from the CPU result
The cases above are about OpenCL failing to start. A rarer and more confusing situation is OpenCL starting perfectly and then producing different pixels from the CPU. Ansel computes the same thing either way, so a visible difference means something below Ansel is not doing the arithmetic it claims.
The usual culprit is the accuracy of the graphics driver’s own math library. Ansel used to ask
its kernels to be compiled with -cl-unsafe-math-optimizations, an option that allows a driver
to substitute an approximate implementation for any standard mathematical function. Most drivers
do this harmlessly. Some do not: on Intel integrated graphics, that option makes erf() return
exactly zero for small arguments and pow() wrong by tens of percent, which visibly corrupted
the AI raw denoise module and,
to a lesser degree, anything using gamma curves.
Current versions no longer request that option, for any vendor. However, updating Ansel is not
enough to fix an affected installation. The kernel compilation options are stored per device in
Anselrc, written the first time a device is seen and never overwritten afterwards, so an old
setting survives an upgrade. Look for:
1cldevice_v4/<number>/<device-name>/building=...If the value still contains -cl-fast-relaxed-math or -cl-unsafe-math-optimizations, replace
it with:
1cldevice_v4/<number>/<device-name>/building=-cl-mad-enable -cl-no-signed-zerosthen delete the compiled kernel cache so the kernels are rebuilt with the new options:
1rm -rf ~/.cache/ansel/cached_kernels_for_*Deleting the whole building line works too — Ansel will rewrite it with its current default.
Two tools help you decide whether this applies to you. tools/opencl-math-accuracy.c in the
Ansel sources is a small standalone program (it does not link against Ansel) that scores every
OpenCL device on your machine, under every combination of compilation options, against a
high-precision reference, and prints the exact Anselrc line for any device that needs one. And
Ansel-nn-parity checks the neural denoiser
specifically, telling you whether the CPU, the GPU or neither is the one disagreeing.
Es gibt auch einige OpenCL-Anwendungen auf CPU, sie kommen als Treiber von INTEL oder AMD. Wir haben beobachtet, dass diese keinen Gewinn an Schnelligkeit im Vergleich zu unseren CPU-kodierten Einheiten erbringen. Deshalb löscht Ansel diese als Standard. Dieses Verhalten kann geändert werdenn, indem die Konfiguration-Variable opencl_use_cpu_devices (in $HOME/.config/Anselrc) auf TRUE.