A PC-k hőskorában még örülhettünk, ha grafikus kártyánk már elboldogult az SVGA-felbontással és az egyszerűbb játékokkal, hiszen akkoriban szó sem volt HD-ről vagy fotorealisztikus háromdimenziós megjelenítésről. Arról pedig álmodni sem mertünk, hogy a VGA-kártya egyszer a CPU babérjaira tör – márpedig most éppen ez történik.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.
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 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.
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...
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.
Real Time 3D Fluid and Particle Simulation and Rendering
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.
Az első OpenCL demó ami a GPU-t használja
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...
írta Papp Gábor, 2009. február 09.
Bejegyzések
0 megjegyzés :
Megjegyzés küldése