Az NVIDIA új CUDA-funkcióval szabályozná, hogyan osztozik a GPU a munkán

Külön erőforrásokat kaphatnak az eltérő feladatok

A modern GPU-alkalmazásokban gyakran több, egymástól független komponens fut párhuzamosan ugyanazon a grafikus processzoron. Egy késleltetésre érzékeny művelet megoszthatja a hardvert egy nagy áteresztőképességre optimalizált háttérfeladattal, adat-előkészítési szakasz futhat modellkövetkeztetés mellett, vagy egy feldolgozási folyamat több lépése használhatja ugyanazt a GPU-t.

Az NVIDIA szerint az ilyen munkaterhelések korábban kiszámíthatatlanul zavarhatták egymást, miközben a rendelkezésre álló eszközök csak korlátozottan tették lehetővé az erőforrások felosztását. A green context segítségével az alkalmazás kiválaszthatja a végrehajtási erőforrások egy részét, majd közvetlenül ezekre irányíthatja a munkát.

A funkció egyik fő eleme az SM-ek, vagyis a streaming multiprocessorok felosztása. Egy green contexthez kijelölhető az SM-ek egy meghatározott csoportja, így több munkaterhelés egyidejűleg futhat anélkül, hogy ugyanazokért a számítási egységekért versenyezne.

A munkasorok felosztása is szabályozható

A green context nemcsak az SM-eket kezeli. Munkasor-erőforrásokat, workqueue-kat is lehet hozzá rendelni. Az NVIDIA leírása szerint a hagyományos modellben egymástól független, streamhez kötött feladatok ugyanahhoz az alapul szolgáló munkasorhoz kerülhetnek. Ez akkor is nem kívánt sorosítást okozhat, ha elegendő végrehajtási erőforrás áll rendelkezésre.

A munkasorok előzetes kiosztásával az alkalmazás pontosabban fejezheti ki, milyen párhuzamosságot vár el, és csökkentheti az ilyen hamis függőségeket. A green contextek létrehozása és megszüntetése könnyű művelet, és ezek a lépések nem szinkronizálják automatikusan a GPU-n futó, nem kapcsolódó munkát.

A technológia a Driver API-ban már a CUDA 12.4 óta elérhető. A CUDA 13.1-től a Runtime API-n keresztül is használható, így az alkalmazások a saját folyamatukon belül határozhatják meg, hol fusson a munka, és hogyan osszák fel a végrehajtási erőforrásokat.

A fejlesztőnek kell kijelölnie a végrehajtási célt

A hagyományos CUDA Runtime-modellben az alkalmazás a cudaSetDevice() segítségével választ eszközt, majd streameket hoz létre. A stream végrehajtási célját a hívó szál aktuális eszköz- vagy kontextusállapota határozza meg a stream létrehozásakor.

A green context ezt a folyamatot teszi egyértelműbbé. Az alkalmazás először létrehoz egy kontextust a kiválasztott erőforrásokhoz, majd abból hozza létre a streameket. A CUDA Runtime API-ban ehhez a cudaExecutionContext_t típus és a cudaGreenCtxCreate() függvény használható, a stream pedig a cudaExecutionCtxStreamCreate() hívással kapcsolható a kiválasztott kontextushoz.

Az NVIDIA szerint a kód módosítása csekély, miközben világosabbá válik, melyik erőforrásokra kerül a munka. A meglévő, streamalapú CUDA-munkafolyamat továbbra is használható, és azok az alkalmazások is a hagyományos Runtime-modellnél maradhatnak, amelyek a teljes eszközt szeretnék célozni.

A cél a kritikus kernelek várakozásának csökkentése

Az NVIDIA példája egy kis, késleltetésérzékeny kernelt állít szembe egy nagy, áteresztőképességre hangolt munkaterheléssel. A streamprioritás önmagában nem garantálja a magasabb prioritású kernel azonnali futását, ha a nagy kernel már teljesen elfoglalja a GPU SM-jeit. A már futó blokkokat a streamprioritás nem szakítja félbe, ezért a kritikus feladatnak meg kell várnia, amíg valamelyik SM felszabadul.

A green contextes megoldásban a kritikus feladat saját SM-partíciót és munkasort kap. Az NVIDIA tesztjében egy 148 SM-mel rendelkező Blackwell GPU-n a kritikus kernel késleltetése 0,140 ms-ról 0,007 ms-ra csökkent a bemutatott munkaterhelés mellett.

A funkció opt-in és kiegészítő jellegű, ezért a cég szerint a meglévő alkalmazások fokozatosan vezethetik be ott, ahol pontosabb irányításra van szükség az egyidejű GPU-munkák felett. A részletes használathoz az NVIDIA a CUDA Programming Guide green contexts fejezetét és a CUDA Driver API kapcsolódó referenciáját ajánlja.