Ansel detecteert automatisch OpenCL-runtime-fouten. Bij het detecteren van een fout, zal het vervolgens alles op de CPU opnieuw verwerken. Hoewel dit de verwerking vertraagt, mag dit het eindresultaat niet beïnvloeden.

Er kunnen verschillende redenen zijn waarom OpenCL tijdens de initialisatiefase zou kunnen mislukken. OpenCL is afhankelijk van hardwarevereisten en van de aanwezigheid van bepaalde stuurprogramma’s en bibliotheken. Bovendien moeten deze allemaal passen qua maker, model en revisienummer. Als iets niet past (bijv. jouw grafisch stuurprogramma (driver) – geladen als een kernelmodule – komt niet overeen met de versie van jouw libOpenCL.so), is OpenCL-ondersteuning waarschijnlijk niet beschikbaar.

In dit geval kan je Ansel het beste starten vanaf een console met Ansel -d opencl.

Dit geeft extra foutopsporingsoutput over de initialisatie en het gebruik van OpenCL. Ten eerste, als je een regel vindt die begint met [opencl_init] FINALLY ..., zou dat je moeten vertellen of OpenCL-ondersteuning voor jou beschikbaar is of niet. Als de initialisatie is mislukt, kijk dan in de bovenstaande berichten voor iets dat leest als ‘kon niet worden gedetecteerd’ of ‘kon niet worden gemaakt’. Controleer of er een hint is over waar het is mislukt.

Hier zijn een paar gevallen die in het verleden zijn waargenomen:

  • 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.so but then tell you that it couldn’t get a platform. NVIDIA drivers will often give error code -1001 in this case. This happens because libOpenCL.so is 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/OpenCL on your system that libOpenCL.so consults 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-zeros

then 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.

Er bestaan ook enkele on-CPU-implementaties van OpenCL, die worden geleverd als stuurprogramma’s die worden geleverd door INTEL of AMD. We hebben vastgesteld dat ze geen snelheidswinst opleveren in vergelijking met onze met de hand geoptimaliseerde CPU-code. Daarom negeert Ansel deze apparaten gewoon standaard. Dit gedrag kan worden gewijzigd door de configuratievariabele opencl_use_cpu_devices (in $HOME/.config/Anselrc) in te stellen op TRUE.