Returncodes versus asynchrone fouten

CUDA meldt problemen op twee manieren: een directe retourcode van API-aanroepen en vertraagde asynchrone fouten van kernels. Beide kennen is essentieel. 🧭

De meeste CUDA-runtimeaanroepen geven een cudaError_t terug. De waarde cudaSuccess betekent dat alles goed is; elke andere waarde wijst op een probleem waarop je kunt reageren.

Bij synchrone aanroepen zoals cudaMalloc is de teruggegeven code definitief. Vergelijk die onmiddellijk met cudaSuccess en reageer voordat je verdergaat.

Een kernelstart met triple brackets heeft geen retourwaarde die je kunt controleren. Startfouten kunnen dus niet op dezelfde eenvoudige manier worden gemeld.

Starts zijn asynchroon: de CPU zet het werk in de wachtrij en gaat meteen verder. De GPU is mogelijk nog niet eens begonnen wanneer je volgende regel wordt uitgevoerd.

Omdat het werk later wordt uitgevoerd, wordt een crash van een kernel een asynchrone fout. Die verschijnt bij een latere aanroep, niet op de regel van de start zelf.

Als je nooit controleert, faalt een kapotte kernel stil. Je programma lijkt te werken, terwijl het onzin of nullen als uitvoer produceert.

Starts kunnen op twee momenten falen: een slechte configuratie die bij de start wordt ontdekt, en een runtimefout zoals een toegang buiten de grenzen die tijdens de uitvoering wordt ontdekt.

Een ernstige fout laat de context achter in een blijvende fouttoestand. Elke latere CUDA-aanroep geeft dan dezelfde fout terug totdat je opnieuw start.

Roep cudaDeviceSynchronize aan om een verborgen fout zichtbaar te maken. De aanroep wacht op de kernel en geeft elke runtimefout terug die deze tegenkwam.

Vuistregel: controleer de retourcode van elke API-aanroep en synchroniseer om kernels te controleren. Samen laten ze geen fout onopgemerkt.

API-aanroepen geven direct een retourcode, terwijl kernels asynchroon falen. Controleer codes en synchroniseer, zodat niets onopgemerkt blijft. 🎉