Az NVIDIA ígéretéhez híven kiadta a CUDA 5.0 nevű fejlesztőkörnyezet végleges verzióját, mely elsősorban az érkező Tesla K20-as termékhez készült, de természetesen a többi GPU-t is támogatja az adott hardver tudásának megfelelően. A kijelölt fejlesztők az előzetes verziókat már korábban megkapták, és a tapasztalatok kedvezőek, mivel gyorsabb programokat lehet készíteni az új CUDA Toolkit bevetésével.
Az NVIDIA a fejlesztőkörnyezetben bevezeti a Dynamic Parallelism szolgáltatás támogatását, mely a Tesla K20 mellett érhető majd el. Ezzel a funkcióval a GPU kihasználtságát lehet növelni a központi és grafikus processzor közötti kommunikáció eliminálásával. Korábban a processzor több szituációban is korlátozta a GPU-t, mivel minden kernelt a processzor indított a grafikus vezérlőn. A GK110 esetében ez nem feltétlenül szükséges, ugyanis a beágyazott kernelekkel a rendszer képes tovább dolgozni anélkül, hogy a processzor segítségét venné igénybe. Tulajdonképpen bármelyik kernel képes egy új kernelt indítani anélkül, hogy processzor beavatkozására lenne szükség. Lényegében ez a legjelentősebb újítás, de fontos megjegyezni az RDMA GPUDirect támogatást. Ennek segítségével egy szerverbe épített grafikus vezérlő direkten elérheti egy másik szerverben található GPU memóriáját. Tulajdonképpen itt az újdonság abban rejlik, hogy a CUDA 4.0-ban alkalmazott megoldással a szükséges adat elérése sokkal hosszabb ideig tartott. A kérés után ugyanis a GPU először a rendszermemória erre fenntartott szeletébe másolta az adatot, onnan pedig bekerült a processzor memóriaszeletébe, és csak ezután lett átküldve a másik szerverben található GPU-nak, amely az információt igényelte. Az RDMA GPUDirect támogatással ez a rendszermemóriás kitérő teljesen kihagyható, ami jelentősen meggyorsíthatja az egyes alkalmazásokat.
Újítás még a GPU Library Object Linking funkció. A CUDA 4.0-ban az összes GPU kernel forrását egy fájlba kellett összesíteni, ami a programozó szemszögéből nem könnyíti meg az alkalmazásfejlesztést. A CUDA 5.0-ban már külön lefordíthatók a kód részei, majd ezek az objektumfájlok összeköthetők egy alkalmazássá. Ez a megoldás lehetőséget ad az objektumfájlok harmadik féltől származó, statikus könyvtárakkal való linkelésére is. Ez értékes a kódok újrahasznosításánál, és a fordítási idő lerövidítésénél, ami a nagyobb alkalmazások esetében fontos szempont. Az új CUDA Toolkit része még az Nsight Eclipse Edition, ami Linux és Mac OS X alatt egyszerűbbé teszi a CUDA programok fejlesztését.
Nem mindenki örül
Bár a felsorolt újítások hasznosak, a fejlesztők egy része mégis szomorúan fogadta a CUDA 5.0-t. Az NVIDIA ugyanis úgy döntött, hogy némileg leépíti a fejlesztőkörnyezet OpenCL részét. Sok programozó számára ez kellemetlen, ugyanis CUDA SDK-t használnak az OpenCL programok fejlesztéséhez. Az új csomagból kikerültek az OpenCL példaprogramok, ami a tapasztalt fejlesztőknek talán nem jelent gondot, de a kezdő programozók a példákból sokat tanulnak, és nem mellesleg látják, hogy miképp érdemes a GeForce termékekre optimalizálni. Ez a döntés egy alapvető felháborodást váltott ki a fejlesztők körében, és egy petíció keretében követelik az NVIDIA-tól az OpenCL komolyabb támogatását. Az valószínűtlen, hogy az NVIDIA-t ez meggyőzi, hiszen már egy ideje nem nagyon törődnek az OpenCL-lel. A 38 példaprogramjukból mindössze négy frissült 2011-ben, emellett a Linuxra írt példák nem is működnek, mivel pár fájlt hiányolnak. Ennél nagyobb gond, hogy semmilyen formában nem készült még OpenCL 1.2-es driver a GeForce-okhoz, miközben az AMD már végleges eszközillesztővel támogatja termékeit, míg az Intel egy béta állapotban lévő fejlesztőkörnyezetben kínál a processzorokhoz OpenCL 1.2-t támogató meghajtót.
Az NVIDIA a fejlesztők számára elmondta, hogy az új CUDA SDK-ból az OpenCL-es példaprogramok azért kerültek ki, hogy csökkentsék a fejlesztőkörnyezet méretét. Ezek azonban nem tűntek el, mivel letölthetők az NVIDIA OpenCL-hez kapcsolódó oldaláról, amit a vállalat kezdőoldalán már egyetlen linken sem lehet elérni, de a Google természetesen kisegíti a programozókat, így az említett oldal itt megtalálható. Megjegyzendő azonban, hogy korábban az OpenCL-ről jóval többet írt a cég, például nyáron az előbb linkelt oldalon sokkal több információt lehetett találni. Persze a fejlesztőknek nem csak az OpenCL-es példák kihagyásával van gondjuk, ugyanis a CUDA 5.0-ban a visual profiler már nem működik OpenCL kódon, miközben a 4.0-s SDK-val még működött. Ez ugyan lehet, hogy csak egy szimpla hiba, de a fentiek mellett már rosszabb eshetőségek is felmerültek.
Természetesen stratégiailag érthető az NVIDIA döntése, mivel az OpenCL a fejlesztők számára sokkal kedvezőbb alternatíva, mint a CUDA, hiszen nyílt platformról van szó, így az alkalmazás gyakorlatilag nem lesz egy gyártóra korlátozva, vagyis a potenciális felvevőpiac lényegesen nagyobb. A CUDA Toolkitet kedvelő fejlesztőknek ez az egész nyilván kellemetlen, de az adott cég számára mindig az üzleti érdek lesz az első, ami az NVIDIA esetében jelenleg biztosan a CUDA-hoz kötődik.
