Már a 90-es évek elején is sokat lehetett hallani a 3D-s gyorsítás fogalmáról. Ez a fogalom akkoriban az otthoni felhasználók körében kimerült az S3 Virge vagy az ATI Rage 3D szerény képességeiben, de az igazi lavinát a 3dfx Voodoo kiegészítő kártyája indította el. Ezt követően egymás után jelentek meg a gyorsabb változatok, majd az SLI-technológia. Időközben azonban az ATI és az NVIDIA is felnőttek ahhoz a feladathoz, hogy igazi 3D-s gyorsítással ellátott kártyát készítsenek – igaz, nem a 3dfx által megvalósított GLide API-vonalon, hanem az OpenGL- és a Direct3D-szabványnak megfelelően.
A Voodoo megjelenése óta eltelt 12 év alatt a grafikus magoknak – röviden GPU-knak – egyre komolyabb feladatokat kell végrehajtaniuk, ezáltal egyre több számítás terhet vesznek le a központi processzor válláról, már ami a megjelenítést illeti. Felépítés szempontjából a grafikus magok rendkívül nagyot léptek előre, komplexitás és gyártástechnológia tekintetében felvehetik a versenyt a CPU-kkal, míg bizonyos feladatoknál számítási kapacitásban már meg is előzték azokat.
Persze a grafikus megjelenítésért felelős lapka a felépítéséből adódóan sokáig nem helyettesíthette a processzort, azonban az új évezred elején debütáló NVIDIA GeForce 3 és az nFinite FX Engine névre hallgató programozható Vertex shader egység, valamint a shader modell első generációjának megjelenése magával hozta a programozható GPU-k korát. Ezt követően a GeForce FX és – az ATI oldaláról – a Radeon 9700 harmadik generációs GPU-k hoztak további fejlődést a shader modell 2.0 és a Vertex mellett már a programozható pixel shader egység megjelenésével.
GPGPU
Természetesen a GPGPU-nak rövidített általános célú (General Purpose) grafikus processzoroknál (GPU) sokkal többről van szó, mint a GeForce 3, az ATI Radeon 9700 vagy az NVIDIA GeForce FX esetében, ám az tagadhatatlan, hogy ebben a tekintetben ezek a lapkák szolgálnak technológiai alappillérként.
Az igazi áttörést a DirectX 10 által megkövetelt egyesített shader architektúra (Unified Shading Architecture) hozta meg, amely leváltotta a külön feladatokra specializálódott pixel és Vertex shader processzorokat. Az NVIDIA G80 és AMD R600 kódnevű lapkák voltak az első grafikus magok, amelyek az említett felépítésnek megfelelően készültek, akárcsak a jelenleg forgalomban lévő G92, GT200 és RV770 magok. Ezek a több mint száz univerzális feldolgozó egységet felvonultató magok olyan speciális párhuzamos adatfeldolgozási feladatokra is rávehetők, amiket korábban csak a CPU tudott kiszámolni. Ez azonban nem jelenti azt, hogy a CPU kiváltható a GPU-val, sőt, ez a közeli jövőben sem várható azon egyszerű oknál fogva, hogy ez az erősen párhuzamosított, grafikus megjelenítésre kihegyezett architektúra – legújabb generációs shader modell esetében – legfeljebb egyszeres pontosságú, 32-bites lebegőpontos számítások esetén használható hatékonyan.
Ezzel szemben egy 64 bites (kétszeres pontosságú) lebegőpontos számításnál már erősen csökken a teljesítmény és a CPU sokkal erősebbnek bizonyul, tehát még várni kell az igazi áttöréssel. Ez elsőre nem látszik a GPU-k adatlapján, így például az RV770 esetében sem. Ott hiába ámuldozott a szakma az 1,2 TFLOPS számítási teljesítményen – ez ugyanis csak az egyszeres pontosságú számításokra vonatkozik. A kétszeres pontosságra vonatkozó adatot az apró betűs részben olvashatjuk, ami csak 240 GFLOPS. Ráadásul a GPU végrehajtó egységei nagyon érzékenyek a kódra, ezért – és a lehető legjobb kihasználtság végett – az erre alkalmas környezetben (mint például az NVIDIA Cuda vagy az AMD CTM fejlesztőkörnyezete) a kódot külön kell optimalizálni és megfelelő nyelvre fordítani.
A jelen: AMD Stream és NVIDIA CUDA
A két nagy gyártó nem meglepő módon saját utakon kezdett bele a GPGPU-képességek kiaknázásába, ennek hála saját SDK-kat (rendszerfejlesztői készlet) fejlesztettek a programozók számára, de olybá tűnik, a CUDA nagyobb népszerűségre tett szert. A PhysX-képességek mellett olyan nagyszerű alkalmazásokat említhetünk meg, mint például a Badaboom konvertálóprogramot, a PowerDirectort vagy a PhotoShop CS4-et (Quadro kártyák esetében Premiere CS4 is) és még 155 más egyéb szoftvert – bár ezek nagy részének otthon nem vesszük semmilyen hasznát. Ezzel szemben az AMD nem adta közre pontosan, hogy mely programok támogatják a Stream-technológiát, de vélhetően jóval kevesebb, ami annak is betudható, hogy a projekt hivatalosan csak december óta létezik.
Mivel az egész GPGPU-téma újdonságnak számít, a támogatottság jelenlegi helyzetéről nehéz többet elmondani. Jó jel, hogy a programozók gyorsan ráharaptak a témára, így további szoftverek támogatása várható még ebben az esztendőben.
OpenCL mindenekelőtt
Mint láthatjuk, a CUDA és Stream – illetve a CTM – legnagyobb hátránya, hogy nem kínálnak egyforma programozási nyelvet a fejlesztők számára, annak ellenére, hogy mindketten a C nyelvet használják. Ez körülbelül olyan helyzetet idéz elő, mint a 3dfx idejében a Glide és a Direct3D esete volt. Elképzelhető tehát, hogy lesznek támogatottsággal kapcsolatos viták. Ennek elkerülése végett a programozók kezébe olyan egységes, platformfüggetlen nyelvet és környezetet kell adni, amely kompatibilis mindegyik gyártó fejlesztésével és a magas mellett natív alacsony szintű hozzáférést enged közvetlenül a hardverhez és a memóriához, így megkerülve az OpenGL és DirectX API-kat. Ilyen például a teljesen ingyenes és nyílt OpenCL-szabvány, amelynek jogait az Apple birtokolja.
A Khronos csoport neve alatt az Apple azonban számos nagyvállalattal (például Intel, NVIDIA, ATI, IBM, 3DLabs, EA) együttműködve közös erővel dolgozik a szabvány tökéletesítésén, mivel a leíró nyelv végleges változata rekordgyorsasággal (már tavaly decemberben) elkészült. Az OpenCL sokak szerint forradalmasítja a számítástechnikát és a lapkákban rejlő erőforrás-kihasználást – és ez alatt nemcsak a grafikus magokat értjük, hanem az akár mobiltelefonokba való processzorokat is. Úgy tűnik, a gyártók is hisznek az újdonság erejében, hiszen az AMD már a kezdetekkor teljes mellszélességgel az OpenCL támogatása mellett döntött, majd az NVIDIA is rábólintott a projektre, ám a CUDA sem merül feledésbe.
Bizonyára sokakban felmerül a kérdés, hogy ez mind szép és jó, de mit lép a Microsoft? Nos, a redmondi óriás sem ül a babérjain és továbbra sem kíván szakítani a hosszú évek alatt kemény munkával felépített DirectX birodalommal, így a 11-es változat része lesz a Compute Shader. Ez gyakorlatilag ilyen formában egy API-hoz kötött GPGPU-támogatás, szemben az OpenCL-lel, amely – mint említettük – független. Nehéz megmondani, melyik szabvány lesz a győztes, hiszen hiába érkezik későn a DirectX 11, a VGA-gyártók természetesen támogatni fogják, ezzel szemben az OpenCL egy jóval kötetlenebb eszközt ad a programozók kezébe, ami nem csak Windows alatt használható, hasonlóan az OpenGL-hez. Továbbá arról sem szabad megfeledkezni, hogy az egész GPGPU-s mizéria többről szól, mint a játékok látványvilága, tehát ez is az OpenCL malmára hajtja a vizet. Azonban még korai találgatásokba bocsátkozni.
Szép új jövő? A GPGPU ma és holnap
Bár mindenki sokat várt a GPGPU-tól, a gyártók nem siették el a támogatását. Az NVIDIA-nál sokáig csak a kiváltságosak érhették el a bétás CUDA GPGPU és PhysX csomagot. Ráadásul üzletpolitikai szempontból csak a G92-es maggal felvértezett GeForce 9-es szériánál használhattuk ki a GPU erejét – később persze minden GeForce 8-as kártyán engedélyezték ezeket a funkciókat. Ugyanígy az AMD-nél sem siettek a nagydobra verni a kártya ezen képességeit, a Folding@Home kliens is csak nemrég került bele a Catalyst telepítőcsomagba.
A döcögős indulás mégsem befolyásolja a GPGPU jövőjét, mert több kutatóintézet és nagy számítási kapacitással operáló vállalat a következő generációs szuperszámítógépeket „szuper gyors” számításokra képes grafikus vezérlőkkel teletömve képzelik el. Igaz, a grafikus vezérlőkön felül vannak még vetélytársak, ilyen például Playstation 3-ból ismert Cell processzor (amelyet már régóta alkalmaznak ilyen célokra, továbbfejlesztett változata pedig a kétszeres pontosságú feladatoknál is meglehetősen fürge), de az Intelnél is erősen készülődnek, hogy új fejlesztésükkel törjenek a babérokra. Összességében véve már nyugodt lélekkel kijelenthetjük, hogy a GPGPU-k jövője biztosított.
A tudományos célokat szolgáló felhasználás minden bizonnyal még erősebb lapkák kifejlesztésére sarkallja a gyártókat, amelyek ugyan nemcsak a játékosok igényeit fogják szem előtt tartani, ám nagyobb számítási kapacitásuk révén a játékosok társadalma is profitálhat majd a folyamatból. Ismerve a grafikuskártya-felhozatalt, nem állíthatjuk, hogy túl sok gyártó van a piacon. Az AMD és NVIDIA mellett még a szebb napokat is látott S3 jelentkezett GPGPU-alkalmazással, ám a kis teljesítménye miatt nem várhatunk tőle csodát, illetve még a támogatottsága is kérdéses. Talán az Intel mozgolódása jelzi, hogy mégis milyen nagy piacot jelent ez a projekt a gyártók számára. Bár nagy a titokzatoskodás a téma körül, az Intel évek óta gőzerővel fejleszti a Larrabee kódnév alatt futó egységet, amelyet elsősorban grafikus magnak szánnak, ám egy egészen új elgondolásnak hála kiválóan alkalmas párhuzamosított számolásokra. A Larrabee érdekessége, hogy egységesíti a grafikus kártyáknál jelenleg is alkalmazott masszív párhuzamosított architektúrát az x86-os utasításkészletű processzorok tudásával (konkrétan egyszerűsített x86-os magokat felhasználva). Ez ily módon nagy átvitelt (pontosabban jobb sávszélesség-kihasználtságot) és remek programozhatóságot biztosít. A Larrabee felépítésének előnye, hogy nem csupán a DirectX és OpenGL grafikus API-kat támogatja, hanem a szoftveres úton megvalósított renderelésben is kiváló teljesítményt nyújt majd, amennyiben elkészül.
Viszlát OpenGL, viszlát DirectX?
Ha már a jövő latolgatásánál és a szoftveres renderelésnél tartunk, érdemes megemlíteni, hogy az egész grafikus megjelenítéssel foglalkozó iparág látszólag elmozdult jól megszokott helyéről és a fix feladatok helyett az általános célú feladatfeldolgozást helyezi előtérbe. E tény részben a klasszikus értelemben vett – tehát csak az előre meghatározott feladatkör elvégzésére alkalmas – grafikus kártya halálát jelenti, amit már évekkel ezelőtt megjósoltak a játékfejlesztők. A kérdés csupán az, hogy mikor fog ez bekövetkezni, viszont jól látható, hogy a fejlesztések gyorsvonat sebességével robognak ebbe az irányba. Ennek következtében valószínűleg vissza fogunk térni a Direct3D és OpenGL API-k előtti időre, amikor a processzor még nyers erővel, szoftveres úton renderelt, csak most a CPU helyett a grafikus kártya fogja ugyanezen számolásokat elvégezni. A programozóknak és fejlesztőknek ez egyaránt azt jelenti, hogy valós programnyelvben kell (például az OpenCL) kódolni, míg ennek következtében a felhasználók számára teljesen mindegy lesz, melyik gyártó kártyáján játszunk. Egyetlen paraméter lesz ugyanis a döntő: a számítási kapacitás.
Ugyanakkor nem szabad azt hinnünk, hogy a programozásban a „szabad kéz” teljes mértékben megoldást jelent minden problémára. Nincs arra garancia, hogy az adott problémára a fejlesztő a legoptimálisabb megoldást találja-e meg, ezáltal esetenként nehezebb dolga is lehet, mint egy előre definiált és adott lehetőségekkel megáldott DirectX esetében. Arra sem számíthatunk, hogy az eddig uralkodó és jól bejáratott alkalmazásprogramozási felületek (DirectX, OpenGL) eltűnnek, de mindenképpen tartaniuk kell a lépést a változással – talán itt jön el ismét az az idő, amikor nem a DirectX-hez igazodik a grafikus kártyák tudása, hanem fordítva, mint a DirectX 9 előtti időkben.
