MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY. programovatelných GPU a CPU (grafických procesorů

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

}

w A| y < 5 4 23 1 0 / -. , )+ ( %&' $ # !"         

Æ  

    


Srovna´nı´ vy´pocˇetnı´ho vy´konu programovatelny´ch GPU a CPU (graficky´ch procesoru˚ a univerza´lnı´ch procesoru˚) BAKALA´RˇSKA´ PRA´CE

Jirˇı´ Sˇima´cˇek

Brno, 2006

Prohla´sˇenı´ Prohlasˇuji, zˇe tato bakala´rˇska´ pra´ce je my´m pu˚vodnı´m autorsky´m dı´lem, ktere´ jsem vypracoval samostatneˇ. Vsˇechny zdroje, prameny a literaturu, ktere´ jsem prˇi vypracova´nı´ pouzˇ´ıval nebo z nich cˇerpal, v pra´ci rˇa´dneˇ cituji s uvedenı´m u´plne´ho odkazu na prˇ´ıslusˇny´ zdroj.

Vedoucı´ pra´ce: Mgr. Martin Kuba ii

Podeˇkova´nı´ Tı´mto bych chteˇl podeˇkovat vedoucı´mu te´to pra´ce Mgr. Martinu Kubovi za vynikajı´cı´ podporu prˇi rˇesˇenı´ nescˇetny´ch proble´mu˚ souvisejı´cı´ch s vypracova´nı´m tohoto te´matu.

iii

Shrnutı´ Tato pra´ce se zaby´va´ vyuzˇitı´m vy´pocˇetnı´ho potencia´lu graficke´ho procesoru (GPU) pro u´cˇely obecny´ch vy´pocˇetnı´ch u´loh. Strucˇneˇ jsou rozebra´ny neˇktere´ techniky a prˇ´ıstupy, ktere´ lze aplikovat prˇi analy´ze proble´mu˚, stejneˇ jako typicke´ situace, ve ktery´ch je vhodne´ obecne´ vy´pocˇty na GPU prova´deˇt. Dalsˇ´ı cˇa´st pra´ce se zaby´va´ dostupny´mi prostrˇedky pro programova´nı´ graficky´ch karet, podrobneˇji je rozebra´n na´stroj BrookGPU. Na za´veˇr jsou uvedeny vy´sledky srovna´nı´ vy´konu univerza´lnı´ho a graficke´ho procesoru prˇi prova´deˇnı´ vy´pocˇtu˚.

iv

Klı´cˇova´ slova gpu, vy´kon, BrookGPU, paralelizace, migrace vy´pocˇtu˚

v

Obsah ´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 U 2 Za´kladnı´ principy zobrazova´nı´ trˇ´ırozmeˇrny´ch sce´n . . . 3 Potencia´lnı´ oblasti vyuzˇitı´ GPU . . . . . . . . . . . . . . 3.1 Techniky vy´pocˇtu˚ . . . . . . . . . . . . . . . . . . . . 3.2 Datove´ struktury . . . . . . . . . . . . . . . . . . . . 3.3 Aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 4 Profily programovatelny´ch jednotek . . . . . . . . . . . 4.1 Instrukcˇnı´ sady . . . . . . . . . . . . . . . . . . . . . 4.2 Prˇ´ıklad ko´du . . . . . . . . . . . . . . . . . . . . . . . 5 Platformy pro komunikaci s GPU . . . . . . . . . . . . . 5.1 Nı´zkou´rovnˇova´ komunikace . . . . . . . . . . . . . . 5.2 Vysˇsˇ´ı programovacı´ jazyky . . . . . . . . . . . . . . . 5.3 Transparentnı´ komunikace . . . . . . . . . . . . . . . 5.4 Srovna´nı´ na´stroju˚ . . . . . . . . . . . . . . . . . . . . 6 BrookGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Jazyk . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . 6.3 Prˇ´ıklad - vy´pocˇet frakta´lu . . . . . . . . . . . . . . . 7 Testova´nı´ vy´konu . . . . . . . . . . . . . . . . . . . . . . . 7.1 Pouzˇity´ hardware . . . . . . . . . . . . . . . . . . . . 7.2 Prˇesnost vy´pocˇtu . . . . . . . . . . . . . . . . . . . . 7.3 Forma´t dat . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Velikost dat . . . . . . . . . . . . . . . . . . . . . . . 7.5 Slozˇitost vy´pocˇtu . . . . . . . . . . . . . . . . . . . . 7.6 Testy jednoduchy´ch operacı´ . . . . . . . . . . . . . . 8 Za´veˇr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Mozˇnost vyuzˇitı´ GPU na operacˇnı´m syste´mu Linux Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 7 8 10 10 12 13 13 16 16 18 20 22 23 23 25 26 28 28 28 30 31 34 34 37 37 38

Kapitola 1

´ vod U Hernı´ pru˚mysl je dnes z hlediska objemu peneˇz, ktere´ se v neˇm tocˇ´ı, velmi perspektivnı´ oblastı´. Na trhu panuje silna´ konkurence, softwarove´ spolecˇnosti se prˇedha´neˇjı´ v kvaliteˇ vyda´vany´ch titulu˚. Jednı´m z hlavnı´ch aspektu˚ teˇchto aplikacı´ je graficky´ vzhled programu, protozˇe ten hraje cˇasto hlavnı´ roli prˇi prvnı´m dojmu ze hry. Na´vrha´rˇi her ruku v ruce s vy´robci hardwaru tedy posouvajı´ lat’ku v tomto odveˇvı´ neusta´le vy´sˇ, a to ve sta´le kratsˇ´ıch cˇasovy´ch intervalech. Na´ru˚st popta´vky zaprˇ´ıcˇinil vznik technologiı´, ktere´ i prˇesto, zˇe jsou GPU (graphics processing unit – graficky´ procesor) prima´rneˇ urcˇeny pro vy´pocˇet vizua´lnı´ch sce´n, umozˇnˇujı´ tyto procesory vyuzˇ´ıt k na´rocˇny´m matematicky´m vy´pocˇtu˚m. Vzhledem k povaze u´loh, pro ktere´ jsou urcˇeny, se prˇi vy´pocˇtu hojneˇ vyuzˇ´ıva´ paralelizace, cozˇ da´va´ v soucˇtu hrube´ sı´ly neˇkolikana´sobneˇ vysˇsˇ´ı vy´kon nezˇ u dnes beˇzˇny´ch univerza´lnı´ch procesoru˚. Oblastı´ univerza´lnı´ch vy´pocˇtu˚ na graficke´m hardware se v soucˇasnosti zaby´va´ skupina GPGPU - General-Purpose computation on GPUs, jejı´zˇ domovske´ stra´nky jsou na http://www.gpgpu.org/ [16. kveˇtna 2006]. Cı´lem te´to pra´ce bylo zjistit, jake´ jsou mozˇnosti vyuzˇitı´ soucˇasne´ho graficke´ho hardware prˇi prova´deˇnı´ obecny´ch vy´pocˇtu˚, vymezit potencia´lnı´ oblasti uplatneˇnı´ a porovnat vy´kon s variantami, ktere´ beˇzˇ´ı na CPU. Soucˇasneˇ byly take´ prozkouma´ny mozˇnosti na´stroju˚ pro komunikaci s graficky´mi procesory (Cg, Sh, BrookGPU). ´ vodnı´ kapitola obsahuje historicky´ podtext a obecne´ nahle´dnutı´ do U procesu vizualizace trˇ´ırozmeˇrny´ch sce´n. V druhe´ kapitole je shrnuto neˇkolik poznatku˚ o tom, v jaky´ch oblastech lze vy´pocˇetnı´ sı´ly GPU vyuzˇ´ıt a jake´ techniky se prˇi vy´pocˇtech pouzˇ´ıvajı´. Dalsˇ´ı kapitola rozebı´ra´ jednotlive´ trˇ´ıdy programovatelne´ho hardware. Na´sledujı´cı´ dveˇ kapitoly probı´rajı´ neˇktere´ na´stroje, ktere´ je mozˇno prˇi programova´nı´ GPU pouzˇ´ıt, zejme´na kapitola BrookGPU obsahuje podrobneˇjsˇ´ı popis (tento na´stroj byl pouzˇit prˇi prova´deˇnı´ testu˚). Prˇedposlednı´ kapitola je veˇnova´na vy´sledku˚m, ktere´ byly nameˇrˇeny prˇi testova´nı´ vy´konu a jsou zhodnoceny v za´veˇru te´to pra´ce.

2

Kapitola 2

Za´kladnı´ principy zobrazova´nı´ trˇı´rozmeˇrny´ch sce´n Na pocˇa´tku 90. let 20.stoletı´ vykona´val v PC vsˇechny vy´pocˇty souvisejı´cı´ s beˇhem programu univerza´lnı´ procesor. Z tohoto du˚vodu byla graficka´ u´rovenˇ tehdejsˇ´ıch aplikacı´ znacˇneˇ limitova´na jeho vy´konem. Navı´c se logika aplikacı´ (zejme´na pocˇ´ıtacˇovy´ch her) sta´vala na´rocˇneˇjsˇ´ı a nebylo tedy mozˇne´ spotrˇebovat vsˇechen cˇas procesoru na vykreslova´nı´ sce´ny. V roce 1994 se na trhu objevila prvnı´ prˇ´ıdavna´ karta, ktera´ cˇa´stecˇneˇ prˇebı´rala zobrazova´nı´ trˇ´ırozmeˇrny´ch modelu˚ - 3Dfx Voodoo Graphics. Tento model meˇl pevneˇ naprogramovanou sekvenci kroku˚, ktere´ se prˇi vykreslova´nı´ prova´´ lohou programa´tora tedy bylo vytvorˇit trˇ´ırozmeˇrny´ model a nahra´t deˇly. U ho do prˇ´ıdavne´ karty. Od te´to chvı´le zacˇal vy´kon graficky´ch karet stoupat a tak se zacˇala do poprˇedı´ dosta´vat ota´zka kvality obrazu. V praxi v te´ dobeˇ existovaly pro tvorbu animacı´ syste´my, ktere´ sice nepracovaly v rea´lne´m cˇase, zato byla kvalita produkovany´ch sce´n mnohem vysˇsˇ´ı. Jednı´m z nich byl naprˇ´ıklad program RenderMan od firmy Pixar Animation Studios, ktery´ umozˇnˇoval prova´deˇt na jednotlivy´ch cˇa´stech sce´ny uzˇivatelem definovane´ operace a tı´m dosahoval pozoruhodny´ch vy´sledku˚. Tohoto na´padu se ujali vy´robci graficky´ch procesoru˚ a zacˇali do pevne´ vykreslovacı´ sekvence prˇida´vat programovatelne´ jednotky (pixel shaders a vertex shaders). Jednı´m z prvnı´ch graficky´ch procesoru˚, ktery´ umozˇnoval prova´deˇt programovatelne´ zobrazova´nı´, byl Radeon 9700 (R300). Veˇtsˇina dnesˇnı´ch zobrazovacı´ch syste´mu˚ je zalozˇena na vykreslova´nı´ dvourozmeˇrne´ matice bodu˚. Vzhledem k tomuto faktu je u´kolem graficke´ho procesoru v prˇ´ıpadeˇ konvencˇnı´ho vyuzˇitı´ prˇeve´st trˇ´ırozmeˇrnou sce´nu prostoru popsanou vektoroveˇ do dvourozmeˇrne´ho rastrove´ho obra´zku. Pro tento proces existuje neˇkolik metod (naprˇ´ıklad raytracing nebo radiosita), nicme´neˇ v praxi se prˇi zobrazova´nı´ v rea´lne´m cˇase z vy´konnostnı´ch du˚vodu˚ vyuzˇ´ıva´ nejcˇasteˇji rasterizace. Tato metoda je velmi rychla´, avsˇak narozdı´l od ostatnı´ch variant nenı´ zalozˇena na fyzika´lnı´m modelu sveˇtla, cozˇ je prˇ´ıcˇinou toho, zˇe obecneˇ produkuje nerea´lne´ vy´sledky. Transformace zalozˇene´ na rasterizaci lze rozdeˇlit do neˇkolika fa´zı´: transformace modelu, osveˇtlenı´, 3

2. ZA´KLADNI´ PRINCIPY ZOBRAZOVA´NI´ TRˇI´ROZMEˇRNY´CH SCE´N transformace pohledu, projekce, orˇeza´nı´, rasterizace, texturova´nı´ a stı´nova´nı´ a zobrazenı´. Transformace modelu Na vstupu te´to fa´ze jsou trˇ´ırozmeˇrne´ geometricke´ objekty umı´steˇne´ programa´torem do abstraktnı´ho prostoru. Tyto objekty jsou tvorˇeny sı´tı´ hran a vrcholu˚, ktera´ je popsa´na mnozˇinou bodu˚ se sourˇadnicemi a informacı´ o tom, ktere´ body jsou spojeny. Prˇi vytva´rˇenı´ modelu lze navı´c vyuzˇ´ıt skla´da´nı´ geometricky´ch primitiv a loka´lnı´ transformace jako naprˇ´ıklad posuny a rotace. Osveˇtlenı´ V abstraktnı´m prostoru jsou kromeˇ sı´t’ovy´ch modelu˚ umı´steˇny na definovany´ch pozicı´ch take´ zdroje sveˇtla, ktere´ vytva´rˇ´ı osveˇtlenı´ sce´ny. Toto osveˇtlenı´ se skla´da´ ze sveˇtla, ktere´ dopada´ prˇ´ımo, prˇ´ıpadneˇ take´ z odrazu˚ od ostatnı´ch objektu˚ nebo neˇktery´ch specia´lnı´ch efektu˚ zpu˚sobeny´ch vlastnostmi povrchu. Soucˇasne´ graficke´ procesory pocˇ´ıtajı´ osveˇtlenı´ pouze na jednotlivy´ch hrana´ch mnohou´helnı´ku˚, ktere´ majı´ by´t vykresleny. Ve fa´zi rasterizace jsou hodnoty osveˇtlenı´ pro jednotlive´ body vypocˇ´ıta´ny pomocı´ interpolace hodnot na hrana´ch. U modernı´ch GPU je navı´c mozˇne´ vypocˇ´ıtat osveˇtlenı´ pro jednotlive´ body pomocı´ programovatelny´ch jednotek (pixel shaders). Transformace pohledu V abstraktnı´m prostoru je take´ stanovena pozice pozorovatele a smeˇr jeho pohledu. V te´to fa´zi docha´zı´ k transformaci objektu˚ mezi sourˇadny´m syste´mem sce´ny na sourˇadny´ syste´m zalozˇeny´m na pohledu, ktery´ ma´ by´t zobrazen. Projekce Prˇi projekci jsou objekty v trˇ´ırozmeˇrne´m prostoru promı´tnuty do dvourozmeˇrne´ plochy tak, jak budou vypadat ve vy´sledne´m zobrazenı´. Orˇeza´nı´ Vzhledem k faktu, zˇe zobrazovacı´ zarˇ´ızenı´ ma´ konecˇnou plochu, cˇa´st graficky´ch primitiv se mu˚zˇe nacha´zet v prostoru, ktery´ nespada´ do zobrazovane´ho vy´rˇezu. Tato primitiva jsou ve fa´zi orˇeza´nı´ odstraneˇna. Orˇeza´nı´ nenı´ 4

2. ZA´KLADNI´ PRINCIPY ZOBRAZOVA´NI´ TRˇI´ROZMEˇRNY´CH SCE´N nevyhnutelneˇ nutne´ k tomu, aby byla sce´na zobrazena korektneˇ, nicme´neˇ jeho pouzˇitı´ znacˇneˇ urychluje dalsˇ´ı kroky vy´pocˇtu, protozˇe eliminuje nepotrˇebnou rasterizaci a dalsˇ´ı zpracova´nı´ obrazu v mı´stech, ktera´ nejsou viditelna´. Rasterizace Rasterizace je proces, prˇi ktere´m je dvourozmeˇrna´ vektorova´ reprezentace sce´ny prˇevedena do dvourozmeˇrne´ mrˇ´ızˇky odpovı´dajı´cı´ forma´tu vy´stupnı´ho zarˇ´ızenı´. Texturova´nı´ a stı´nova´nı´ V tomto sta´diu je k jednotlivy´m cˇa´stem sce´ny prˇirˇazena barva na za´kladeˇ hodnot interpolovany´ch z hran objektu˚ prˇi rasterizaci nebo na za´kladeˇ textury v pameˇti (textura je obra´zek - obvykle bitova´ mapa - urcˇeny´ k nanesenı´ na prostorovy´ model, ktery´ urcˇuje vy´slednou podobu povrchu). Zobrazenı´ Vy´sledna´ mrˇ´ızˇka slozˇena´ z barevny´ch bodu˚ mu˚zˇe by´t zobrazena na vy´stupnı´m zarˇ´ızenı´. Implementace zobrazovacı´ho procesu V praxi nejprve graficky´ procesor nacˇte z pameˇti posloupnost hran. Tyto hrany pak podstupujı´ proces transformace a hranove´ho osveˇtlenı´. V tomto bodeˇ mu˚zˇe by´t u programovatelne´ho GPU vlozˇen uzˇivatelsky´ program pro zpracova´nı´ hran (vertex shader), ktery´ ma´ mozˇnost manipulovat s daty prˇed tı´m, nezˇ dojde k rasterizaci. Po dokoncˇenı´ transformace a osveˇtlenı´ dojde k orˇeza´nı´ neviditelny´ch fragmentu˚ a zbyle´ cˇa´sti jsou prˇevedeny do rastru. Na vy´sledek lze aplikovat program pro zpracova´nı´ bodu˚ (pixel shader), ktery´ upravuje vzhled jednotlivy´ch cˇa´stı´ a vytva´rˇ´ı vy´slednou podobu sce´ny, ktera´ je da´le zobrazena. Prˇedchozı´ posloupnost kroku˚ je vhodny´m modelem pro hardwarove´ zpracova´nı´. Jednotlive´ hrany a fragmenty sce´ny mohou by´t zpracova´va´ny neza´visle, cozˇ umozˇnuje graficke´mu procesoru pracovat v proudove´m rezˇimu a jednotlive´ fa´ze procesu mohou probı´hat paralelneˇ. Zatı´mco tedy neˇktere´ cˇa´sti sce´ny jsou transformova´ny do rastru, jine´ se nacha´zejı´ naprˇ´ıklad ve fa´zi osveˇtlova´nı´. Navı´c lze zna´sobenı´m pocˇtu vy´pocˇetnı´ch jednotek zajistit, zˇe se v prˇ´ıslusˇny´ch fa´zı´ch mu˚zˇe zpracova´vat vı´ce hran a fragmentu˚ 5

2. ZA´KLADNI´ PRINCIPY ZOBRAZOVA´NI´ TRˇI´ROZMEˇRNY´CH SCE´N soucˇasneˇ, a tedy dosa´hnout vysˇsˇ´ıho vy´konu. Na obra´zku 2.1 je zobrazeno jednoduche´ sche´ma architektury graficky´ch procesoru˚.

Sı´t’ovy´ model

?

Zpracova´nı´ hran (vertex shaders)

?

Transformace pohledu Orˇeza´nı´

?

Rasterizace

?

?




?

?

Zpracova´nı´ bodu˚ (pixel shaders)

?




? Zobrazenı´

Obra´zek 2.1: Sche´ma architektury GPU

6

Kapitola 3

Potencia´lnı´ oblasti vyuzˇitı´ GPU Vy´pocˇetnı´ sı´la graficky´ch procesoru˚ je vy´sledkem u´zce specializovane´ architektury, ktera´ je jizˇ pomeˇrneˇ dlouhou dobu vyvı´jena za u´cˇelem dosazˇenı´ maxima´lnı´ho vy´konu u silneˇ paralelnı´ch u´loh prˇi vykreslova´nı´ pocˇ´ıtacˇove´ grafiky. Roustoucı´ flexibilita vy´pocˇetnı´ch jednotek graficky´ch procesoru˚ spolecˇneˇ s rostoucı´m za´jmem vy´voja´rˇu˚ o obecne´ vy´pocˇty prova´deˇne´ na graficky´ch karta´ch dnes umozˇnˇuje vyuzˇ´ıt GPU i pro aplikace, ktere´ spadajı´ mimo vyhraneˇnou oblast. Sta´le vsˇak existuje mnoho aplikacı´, ktere´ zatı´m nejsou (a mozˇna´ nikdy nebudou) vhodne´ k vykona´va´nı´ na GPU. Zpracova´nı´ a sazba textu je typicky´m prˇ´ıkladem aplikace, ve ktere´ dominujı´ nehomogenı´ pameˇt’ove´ operace a ktera´ je obtı´zˇneˇ paralelizovatelna´. Dnesˇnı´ graficke´ procesory navı´c postra´dajı´ neˇktera´ za´kladnı´ programovacı´ paradigmata, jako naprˇ´ıklad operace s cely´mi cˇ´ısly. Souvisejı´cı´ neprˇ´ıtomnost operacı´ bitovy´ch posunu˚ a logicky´ch operacı´ cˇinı´ tyto vy´pocˇetnı´ jednotky nepouzˇitelne´ v oblasti neˇktery´ch intenzivnı´ch vy´pocˇtu˚, jakou je trˇeba kryptografie. Neˇktere´ dalsˇ´ı u´lohy vyzˇadujı´cı´ vysokou prˇenost jsou nynı´ take´ obtı´zˇneˇ aplikovatelne´, protozˇe podpora cˇ´ısel s plovoucı´ rˇa´dovou cˇa´rkou o sˇ´ırˇce 64 bitu˚ nebude pravdeˇpodobneˇ v dohledne´ dobeˇ v GPU implementova´na. Existuje vsˇak neˇkolik prˇeka´zˇek i pro proble´my, ktere´ lze na graficky´ch procesorech rˇesˇit efektivneˇ. Navzdory programovatelnosti a mozˇnosti vyuzˇ´ıt vysˇsˇ´ı programovacı´ jazyky zu˚sta´va´ tento vy´pocˇetnı´ prostrˇedek obtı´zˇneˇ pouzˇitelny´ pro nevizua´lnı´ u´lohy. V tomto prˇ´ıpadeˇ je totizˇ pouzˇit neobvykly´ programovacı´ model a programova´nı´ tedy nenı´ pouze za´lezˇitostı´ nastudova´nı´ nove´ho jazyka nebo napsa´nı´ nove´ho genera´toru ko´du prˇekladacˇe. Algoritmy je nutne´ prˇeformulovat do terminologie zobrazova´nı´ vizua´lnı´ch dat, cozˇ vyzˇaduje programa´tora zbeˇhle´ho ve vy´voji graficky´ch aplikacı´, na´vrhu prˇ´ıslusˇne´ho hardwaru a jeho omezenı´. Tyto prˇeka´zˇky jsou zpu˚sobeny pouze specializacı´ GPU na vykreslova´nı´ trˇ´ırozmeˇrny´ch sce´n nikoliv vsˇak chybny´m na´vrhem graficky´ch karet. Nelze tedy pouze vycˇka´vat na prˇ´ıchod jedne´ nebo dvou dalsˇ´ıch generacı´, ktere´ prˇinesou vysˇsˇ´ı prˇesnost a bohatsˇ´ı instrukcˇnı´ sadu. Vyuzˇitı´ graficke´ho procesoru pro u´cˇely obecny´ch vy´pocˇtu˚ 7

3. POTENCIA´LNI´ OBLASTI VYUZˇITI´ GPU vyzˇaduje znalosti jednak v oboru pocˇ´ıtacˇove´ grafiky a soucˇasneˇ v prˇ´ıslusˇne´ veˇdecke´ nebo prakticke´ oblasti. Vzhledem k faktu, zˇe dnesˇnı´ graficke´ procesory vykazujı´ pokrocˇilou architekturu a jejich vy´kon roste mnohem rychleji nezˇ u procesoru˚ univerza´lnı´ch, nenı´ mozˇno i prˇes vsˇechny prˇeka´zˇky v programovacı´m modelu jejich potencia´lnı´ prˇ´ınos prˇehle´dnout. Tato kapitola da´le rozebı´ra´ ru˚zne´ oblasti vyuzˇitı´ graficky´ch procesoru˚ v prakticky´ch aplikacı´ch. Informace jsou cˇerpa´ny prˇeva´zˇneˇ z [4] a [7], kde je problematika rozebra´na podrobneˇji.

3.1 Techniky vy´pocˇtu˚ Z abstraktnı´ho pohledu je model programova´nı´ GPU podobny´ pra´ci s proudem neza´visly´ch dat. Existuje neˇkolik za´kladnı´ch operacı´, ktere´ mohou by´t s proudy dat prova´deˇny a ktere´ pouzˇ´ıva´ mnoho aplikacı´ pracujı´cı´ch s graficky´mi procesory. Mezi neˇ patrˇ´ı mapova´nı´, redukce, neprˇ´ıme´ cˇtenı´ a neprˇ´ımy´ za´pis, filtrova´nı´, rˇazenı´ a vyhleda´va´nı´. Mapova´nı´ Jednou z nejednodusˇsˇ´ıch technik vyuzˇitelny´ch prˇi pra´ci s proudy dat je mapova´nı´. Princip spocˇ´ıva´ v aplikaci dane´ funkce na jednotlive´ elementy vstupu. Implementace pomocı´ GPU je prˇ´ımocˇara´, vstupnı´ data se nahrajı´ do pameˇti jako textura a funkce se naprogramuje do GPU, ktere´ ji v pru˚beˇhu generova´nı´ sce´ny aplikuje na kazˇdy´ element textury. Redukce Prˇi vy´pocˇtu mu˚zˇe dojı´t k situaci, kdy je trˇeba ze vstupnı´ho proudu vytvorˇit vy´stupnı´ proud, ktery´ obsahuje me´neˇ, prˇ´ıpadneˇ pouze jeden prvek. Jedna´ se tedy o redukci. Na graficky´ch procesorech lze redukci prova´deˇt pomocı´ strˇ´ıdave´ho zpracova´va´nı´ dvou textur, prˇitom v kazˇde´m pru˚chodu se velikost vy´stupu snı´zˇ´ı na polovinu. Obecneˇ lze redukci vypocˇ´ıtat v logaritmicke´m pocˇtu kroku˚ na paralelnı´m GPU oproti linea´rnı´mu pocˇtu kroku˚ na CPU. Neprˇı´me´ cˇtenı´ a neprˇ´ımy´ za´pis Prˇi transformaci textur prova´dı´ GPU vy´pocˇet postupneˇ se vsˇemi prvky. Prˇi kazˇde´m kroku se urcˇ´ı adresa bodu (pixelu), ktery´ bude zpracova´n a za´rovenˇ se vypocˇ´ıta´ mı´sto, kde bude ulozˇen vy´sledek. Programy mohou prˇebı´rat obecneˇ vı´ce vstupu˚, ale mohou produkovat pouze jednu vy´stupnı´ hodnotu.

8

3. POTENCIA´LNI´ OBLASTI VYUZˇITI´ GPU Vy´pocˇetnı´ jednotky jsou vybaveny instrukcemi, ktere´ umozˇnˇujı´ cˇ´ıst data z libovolne´ pozice v pameˇti (textury) – neprˇ´ıme´ cˇtenı´ (gather). Fakt, zˇe je adresa vy´stupu urcˇena prˇed spusˇteˇnı´m programu, znemozˇnuje prˇ´ımocˇarˇe prova´deˇt neprˇ´ımy´ za´pis (scatter). Z tohoto du˚vodu byly vyvinuty neˇktere´ metody, ktere´ umozˇnujı´ operaci neprˇ´ıme´ho za´pisu obejı´ – je naprˇ´ıklad mozˇne´ vy´sledek nejprve ulozˇit na stanovenou adresu a pozdeˇji data serˇadit. Filtrova´nı´ V prˇ´ıpadeˇ filtrova´nı´ se jedna´ o vy´beˇr neˇktery´ch prvku˚ z datove´ho proudu podle zadane´ho krite´ria. V terminologii GPU jde v podstateˇ o specia´lnı´ prˇ´ıpad redukce, nicme´neˇ vzhledem k faktu, zˇe adresa ani pocˇet prvku˚ nenı´ zna´m prˇedem, nelze tyto operace prova´deˇt stejny´m zpu˚sobem. Filtrova´nı´ lze dosa´hnout kombinacı´ neˇkolika ru˚zny´ch metod s vı´cena´sobny´mi pru˚chody dat. ˇ azenı´ R Rˇazenı´ je operace ktera´ prˇeskla´da´ prvky v datove´m proudu tak, aby jejich porˇadı´ vyhovovalo dane´ relaci usporˇa´da´nı´. Pro rˇazenı´ pomocı´ univerza´lnı´ch procesoru˚ bylo navrzˇeno neˇkolik technik, ktere´ vsˇak veˇtsˇinou u GPU nelze pouzˇ´ıt, protozˇe jejich kroky jsou datoveˇ za´visle´ a obecneˇ vyzˇadujı´ operaci rozpty´lenı´. Veˇtsˇina implementacı´ pro graficke´ procesory je zalozˇena na rˇadı´cı´ch sı´tı´ch. Za´kladnı´ mysˇlenkou u tohoto prˇ´ıstupu je princip rˇazenı´ zalozˇeny´ na pevneˇ stanovene´m pocˇtu kroku˚, ktery´ je neza´visly´ na vstupnı´ch datech. Navı´c majı´ vsˇechny uzly v rˇadı´cı´ sı´ti pevne´ komunikacˇnı´ cesty, proble´m lze tedy formulovat pomocı´ operaci shroma´zˇdeˇnı´ namı´sto rozpty´lenı´ a stanoveny´ pocˇet fa´zı´ pro dany´ vstup umozˇnˇuje eliminovat datoveˇ za´visle´ veˇtvenı´. Celkoveˇ je tak mozˇne´ docı´lit usporˇa´da´nı´ proudu v O (n log2 (n)) krocı´ch. U rˇazenı´ byly take´ zkouma´ny metody, ktere´ vyuzˇ´ıvajı´ texturovacı´ fa´ze procesu vykreslova´nı´ sce´ny a plneˇ eliminujı´ potrˇebu programovatelny´ch jednotek. Vyhleda´va´nı´ Prˇi vyhleda´va´nı´ je cı´lem nale´zt jisty´ prvek v proudu dat, prˇ´ıpadneˇ mnozˇinu prvku˚, ktere´ jsou hledane´mu prvku nejblı´zˇe (naprˇ´ıklad databa´zove´ dotazy). U implementacı´ pro GPU je efektivnı´ prova´deˇt neˇkolik vyhleda´va´nı´ soucˇasneˇ, a tı´m zvy´sˇit propustnost. Za´kladnı´ variantou je bina´rnı´ vyhleda´va´nı´, ktere´ pracuje nad serˇazeny´m seznamem a v kazˇde´m kroku porovna´va´ prostrˇednı´ prvek s prvkem, ktery´ 9

3. POTENCIA´LNI´ OBLASTI VYUZˇITI´ GPU je hleda´n. Na za´kladeˇ vy´sledku aplikuje stejny´ postup na levou nebo pravou polovinu dat, dokud nenajde prˇ´ıslusˇny´ prvek nebo neurcˇ´ı, zˇe takovy´ prvek neexistuje. Algoritmus bina´rnı´ vyhleda´va´nı´ je vnitrˇneˇ sekvencˇnı´, nelze tedy paralelizovat vyhleda´va´nı´ jedine´ho prvku. Pomocı´ graficke´ho procesoru vsˇak lze jednodusˇe prova´deˇt soucˇasneˇ vyhleda´va´nı´ vı´ce prvku˚ ve stejny´ch datech.

3.2 Datove´ struktury Kazˇdy´ algoritmus pracuje s daty, ktera´ jsou ulozˇena v neˇjake´ datove´ strukturˇe. Datove´ struktury, ktere´ se vyuzˇ´ıvajı´ prˇi vy´pocˇtech na GPU musı´ podporovat rychly´ a bezpecˇny´ch prˇ´ıstup (z hlediska synchronizace) a soucˇasneˇ efektivnı´ paralelnı´ iteraci. Za´rovenˇ je zˇa´doucı´ aby cˇinnost datove´ struktury respektovala vnitrˇnı´ pameˇt’ovy´ model GPU a proces tak bylo mozˇne´ prova´deˇt efektivneˇ. Hodnoty jsou v tomto prˇ´ıpadeˇ v pameˇti ulozˇeny te´meˇrˇ vzˇdy v podobeˇ textury, ktera´ ma´ dva rozmeˇry. Jednorozmeˇrna´ data by mohla by´t ulozˇena jako jeden rˇa´dek, nicme´neˇ maxima´lnı´ velikost textury v jednom rozmeˇru by´va´ omezena, proto se obvykle pouzˇ´ıva´ mapova´nı´ z jednodimenziona´lnı´ho do dvoudimenziona´lnı´ho prostoru.

3.3 Aplikace Diferencia´lnı´ rovnice Diferencia´lnı´ rovnice se pouzˇ´ıvajı´ v mnoha oblastech vy´zkumu a inzˇeny´rstvı´. Jejich efektivnı´ rˇesˇenı´ je zvla´sˇteˇ nezbytne´ pro simulova´nı´ fyzika´lnı´ch jevu˚. V typicke´m prˇ´ıpadeˇ se obvykle rˇesˇ´ı vy´pocˇet pro velkou sadu dat, tento proble´m je tedy prˇirozeneˇ paralelizovatelny´ a lze jej pohodlneˇ rˇesˇit pomocı´ GPU. Linea´rnı´ algebra Operace s vektory a maticemi mohou by´t opeˇt dobrˇe decomponova´ny na neza´visle´ paralelnı´ u´lohy. Bylo uka´za´no, zˇe operace jako na´sobenı´ matic lze pomocı´ GPU prova´deˇt rychleji nezˇ prˇi tradicˇnı´m prˇ´ıstupu. Prˇi vy´zkumu v te´to oblasti byl odhalen fakt, zˇe jsou tyto operace znacˇneˇ omezeny pameˇt’ovou propustnostı´ a byly navrzˇeny neˇktere´ zmeˇny v na´vrhu graficky´ch procesoru˚, ktere´ by tyto proble´my redukovaly a posunuly tak vy´kon v teˇchto vy´pocˇtech na vysˇsˇ´ı u´rovenˇ. 10

3. POTENCIA´LNI´ OBLASTI VYUZˇITI´ GPU Ostatnı´ oblasti vyuzˇitı´ Vy´pocˇetnı´ho vy´konu GPU lze vyuzˇ´ıt i v mnoha dalsˇ´ıch oblastech jako jsou trˇeba databa´zove´ syste´my, u ktery´ch lze snadno implementovat vy´pocˇet agregacˇnı´ch funkcı´ typu pru˚meˇrna´ hodnota, maximum, apod., prˇ´ıpadneˇ vyuzˇ´ıt mozˇnosti soubeˇzˇne´ho vyhleda´va´nı´. Vhodneˇ lze paralelizovat take´ u´lohy, ktere´ prova´deˇjı´ zpracova´nı´ signa´lu, da´le take´ ru˚zne´ metody vy´pocˇtu globa´lnı´ho osveˇtlenı´, mezi ktere´ patrˇ´ı raytracing, fotonove´ mapy, radiosita nebo subsurface scattering, cˇi geometricke´ vy´pocˇty.

11

Kapitola 4

Profily programovatelny´ch jednotek S vy´vojem vy´pocˇetnı´ch jednotek se take´ vyvı´jely na´roky, ktere´ byly na tyto jednotky kladeny. Na pocˇa´tku bylo umozˇneˇno pouzˇ´ıvat pouze velmi kra´tke´ programy, navı´c bez podmı´neˇne´ho veˇtvenı´, ktere´ meˇly k dispozici pouze neˇkolik ma´lo registru˚. Schopnosti cˇipu˚ se rozsˇirˇovaly, za´rovenˇ se vsˇak odlisˇovaly mezi jednotlivy´mi vy´robci. Aby mohly by´t tyto vy´pocˇetnı´ prostrˇedky vyuzˇity v praxi, vznikla potrˇeba jiste´ klasifikace. Za tı´mto u´cˇelem byly vytvorˇeny trˇ´ıdy (shader model – SM), ktere´ specifikujı´, jake´ minima´lnı´ pozˇadavky musı´ cˇip splnˇovat. V tabulce 4.1 jsou uvedeny prˇ´ıklady vlastnostı´ a hodnot pro trˇ´ıdy SM 2.0 a 3.0 (jednotky pro zpracova´nı´ pixelu˚). Informace v te´to kapitole byly z cˇa´sti cˇerpa´ny z vy´vojove´ sady DirectX SDK[5]. vlastnost max. de´lka programu max. pocˇet vykonany´ch instrukcı´ max. pocˇet texturovacı´ch instrukcı´ pozicˇnı´ registr pocˇet interpolacˇnı´ch registru˚ predikce instrukcı´ registry pro indexova´nı´ vstupu docˇasne´ registry registry konstant prˇechodove´ instrukce cˇ´ıtacˇ cyklu dynamicka´ kontrola toku

SM 2.0 96 96 32 ne 10 ne ne 12 32 ne ne ne

SM 3.0 512 65535 bez omezenı´ ano 10 ano ano 32 224 ano ano 24

Tabulka 4.1: Srovna´nı´ trˇ´ıd Shader Model 2.0 a Shader Model 3.0 Z tabulky 4.1 je patrne´, zˇe programovatelnost jednotek je znacˇneˇ za´visla´ na implementovane´m modelu. Navı´c zde nejsou uvedena neˇktera´ dalsˇ´ı omezenı´, jako naprˇ´ıklad fakt, zˇe doposud nenı´ mozˇne´ vytvorˇit pocˇ´ıtany´ cyklus s pocˇtem opakova´nı´ prˇesahujı´cı´m 255 iteracı´. Podobna´ omezenı´ budou pravdeˇpodobneˇ odstraneˇna v neˇktere´m z dalsˇ´ıch modelu˚ – v soucˇas12

4. PROFILY PROGRAMOVATELNY´CH JEDNOTEK nosti je ve vy´voji Shader Model 4.0, jehozˇ uvedenı´ bude doprova´zet vyda´nı´ nove´ verze aplikacˇnı´ho rozhranı´ DirectX pro syste´my Microsoft Windows. Dnesˇnı´ graficke´ procesory podporujı´ nejcˇasteˇji Shader Model 3.0. V tabulce 4.2 jsou uvedeny prˇ´ıklady GPU a prˇ´ıslusˇne´ verze hardwarovy´ch profilu˚. cˇip Radeon 9800 (R350) Radeon X800 (R420) Radeon X1800 (R520) GeForce FX (NV30) GeForce 6 (NV40) GeForce 7 (G70)

profil SM 2.0 SM 2.0 SM 3.0 SM 2.0 SM 3.0 SM 3.0

Tabulka 4.2: Podpora hardwarovy´ch profilu˚

4.1 Instrukcˇnı´ sady Vzhledem k tomu, zˇe graficke´ procesory jsou urcˇeny ke zcela odlisˇne´mu u´cˇelu, nezˇ procesory univerza´lnı´, vypadajı´ take´ instrukcˇnı´ sady odlisˇneˇ. U univerza´lnı´ch procesoru˚ se vyskytuje sada instrukcı´ pro aritmeticke´ operace s cely´mi cˇ´ısly a cˇ´ısly s plovoucı´ rˇa´dovou cˇa´rkou, instrukce pro bitove´ posuny a rotace, instrukce pro logicke´ operace a instrukce pro rˇ´ızenı´ toku programu. Navı´c dnesˇnı´ procesory obsahujı´ instrukce MMX a SSE, ktere´ umozˇnˇujı´ vektorove´ a maticove´ operace. Naproti tomu GPU zatı´m obsahujı´ pouze aritmeticke´ instrukce pro pra´ci s cˇ´ısly s plovoucı´ rˇa´dovou cˇa´rkou, a to jak se skala´rnı´mi hodnotami, tak s vektorovy´mi i maticovy´mi daty. Shader Model 3.0 prˇida´va´ instrukce pro podmı´neˇne´ veˇtvenı´ programu. Naopak chybı´ naprˇ´ıklad celocˇ´ıselne´ instrukce a instrukce pro logicke´ operace, ty vsˇak budou pravdeˇpodobneˇ uvedeny v nadcha´zejı´cı´ trˇ´ıdeˇ Shader Model 4.0. V tabulce 4.3 jsou uvedeny neˇktere´ instrukce graficky´ch procesoru˚.

4.2 Prˇı´klad ko´du Prˇekladacˇ BrookGPU vygeneruje z programu kernel void multiply( float4 a<>, out float f<> ) { f = a.x * a.y + a.z * a.w; } na´sledujı´cı´ ko´d:

13

4. PROFILY PROGRAMOVATELNY´CH JEDNOTEK ps_3_0 def c0, 1, 0, 0, 0 dcl_texcoord v0.xy dcl_2d s0 mul r0, v0.xyxx, c0.xxyy texldl r0, r0, s0 dp2add oC0.x, r0.xzzw, r0.ywzw, c0.y mov oC0.yzw, c0.y Prvnı´m prˇ´ıkazem je pseudoinstrukce, ktera´ urcˇuje verzi hardwarove´ho profilu, pro ktery´ je ko´d napsa´n. Instrukce def c0, 1, 0, 0, 0 definuje konstantu c0, ktera´ ma´ 4 slozˇky – 1, 0, 0 a 0. dcl_texcoord v0.xy nadeklaruje registr se sourˇadnicemi v texturˇe (jeho obsah je stanoven v prˇedchozı´ch fa´zı´ch vy´pocˇtu). dcl_2d s0 nadeklaruje vstupnı´ registr programu – v tomto prˇ´ıpadeˇ vzorkovacı´ registr textury. Instrukce ps, def a dcl* musı´ prˇedcha´zet vsˇechny funkcˇnı´ instrukce, jinak by program nebylo mozˇne´ prove´st. mul r0, v0.xyxx, c0.xxyy provede vyna´sobenı´ registru v0 a konstanty c0, vy´sledek ulozˇ´ı do r0. Notace v0.xyxx zpu˚sobı´, zˇe se operand v0 chova´, jako by jeho slozˇky x, y, z, w obsahovaly postupneˇ hodnoty slozˇek x, y, x a x. Hodnota teˇchto slozˇek v pu˚vodnı´m operandu zu˚stane nezmeˇneˇna. Instrukce texldl r0, r0, s0 nacˇte z textury (reprezentovane´ vzorkovacı´m registrem s0) hodnotu bodu na sourˇadnocı´ch ulozˇeny´ch v registru r0 a ulozˇ´ı ji do r0. dp2add oC0.x, r0.xzzw, r0.ywzw, c0.y provede skala´rnı´ soucˇin na prvnı´ch dvou slozˇka´ch operandu˚ r0.xzzw a r0.ywzw, k vy´sledku prˇicˇte c0.y (v tomto prˇ´ıpadeˇ 0) a ulozˇ´ı do vy´stupnı´ho registru oC0. mov oC0.yzw, c0.y nakonec vynuluje ostatnı´ slozˇky registru oC0.

14

4. PROFILY PROGRAMOVATELNY´CH JEDNOTEK

symbolicky´ za´pis nop ps def mov add mul lrp dp4 tex dcl dp2add abs min sincos texldl call crs label loop

uvedeno v modelu SM 1.0 SM 1.0 SM 1.0 SM 1.0 SM 1.0 SM 1.0 SM 1.0 SM 1.0 SM 1.0 SM 2.0 SM 2.0 SM 2.0 SM 2.0 SM 2.0 SM 3.0 SM 3.0 SM 3.0 SM 3.0 SM 3.0

popis zˇa´dna´ operace pseudoinstrukce urcˇujı´cı´ hw. profil definice konstanty prˇesun hodnoty soucˇet soucˇin linea´rnı´ interpolace 4-slozˇkovy´ skala´rnı´ soucˇin navzorkova´nı´ textury deklarace vstupnı´ho registru 2-slozˇkovy´ skala´rnı´ soucˇin a prˇicˇtenı´ absolutnı´ hodnota minimum sinus a kosinus navzorkova´nı´ textury s u´rovnı´ detailu vola´nı´ podprogramu vektorovy´ soucˇin na´veˇsˇtı´ zacˇa´tek cyklu

Tabulka 4.3: Neˇktere´ instrukce graficky´ch procesoru˚

15

Kapitola 5

Platformy pro komunikaci s GPU V soucˇasnosti existuje neˇkolik platforem, ktere´ umozˇnujı´ programa´torovi komunikaci s GPU na ru˚zny´ch u´rovnı´ch abstrakce. V te´to kapitole jsou strucˇneˇ popsa´ny neˇktere´ z rozsˇ´ırˇeny´ch na´stroju˚. Tyto obvykle komunikujı´ s hardwarem pomocı´ aplikacˇnı´ho rozhranı´ DirectX nebo OpenGL, neˇktere´ z nich umozˇnujı´ rozhranı´ vybrat. Podle abstrakce, na ktere´ se uzˇivatel prˇi pra´ci pohybuje, lze interakci s graficky´mi vy´pocˇetnı´mi prostrˇedky rozdeˇlit na 

nı´zkou´rovnˇovou,



na u´rovni vysˇsˇ´ıch programovacı´ch jazyku˚ a



transparentnı´.

5.1 Nı´zkou´rovnˇova´ komunikace S vyuzˇitı´m rozhranı´ OpenGL nebo DirectX lze do programovatelny´ch jednotek nahra´vat prˇ´ımo strojovy´ ko´d (symbolicke´ instrukce). Tento prˇ´ıstup ma´ vsˇak podobne´ nevy´hody jako programova´nı´ CPU v asembleru. Vyvı´jet programy tı´mto zpu˚sobem je tedy cˇasoveˇ na´rocˇne´ a vy´sledny´ ko´d je za´visly´ na konkre´tnı´ instrukcˇnı´ sadeˇ.

DirectX DirectX je aplikacˇnı´ rozhranı´ beˇzˇ´ıcı´ na operacˇnı´ch syste´mech Microsoft Windows vyvinute´ firmou Microsoft, ktere´ umozˇnˇuje komunikovat s hardware pocˇ´ıtacˇe s minima´lnı´ rezˇiı´. Jeho za´beˇr se nevztahuje pouze na oblast grafiky, nicme´neˇ ta je jeho steˇzˇejnı´ soucˇa´stı´. Rozhranı´ je postaveno na modelu COM, je tedy mozˇne´ jej vyuzˇ´ıt v libovolne´m vy´vojove´m prostrˇedı´, ktere´ tento bina´rnı´ standard podporuje. Tato platforma je vyuzˇ´ıva´na veˇtsˇinou vy´robcu˚ pocˇ´ıtacˇovy´ch her. Nahra´nı´ programu do GPU mu˚zˇe probı´hat na´sledovneˇ: ID3DXEffect* g_pEffect = NULL; D3DXCreateEffectFromFile( pd3dDevice, ”program.fx”, NULL,

16

5. PLATFORMY PRO KOMUNIKACI S GPU NULL, 0, &g_pEffect, NULL ); Po inicializaci rozhranı´ DirectX (viz. [5]), prˇi ktere´m je vytvorˇen objekt zprˇ´ıstupnˇujı´cı´ sluzˇby zarˇ´ızenı´ (pd3dDevice), je mozˇne´ ze souboru nacˇ´ıst program zapsany´ v symbolicky´ch instrukcı´ch. Prˇi zava´deˇnı´ je za´rovenˇ pomocı´ sluzˇeb ovladacˇe graficke´ karty zajisˇteˇn prˇeklad teˇchto instrukcı´ do strojove´ho ko´du konkre´tnı´ho GPU. V mı´steˇ programu, kde je prova´deˇno vykreslova´nı´ sce´ny lze pote´ umı´stit na´sledujı´cı´ operace: g_pEffect->Begin(&cPasses, 0); for (iPass = 0; iPass < cPasses; iPass++) { g_pEffect->BeginPass(iPass); g_pMesh->DrawSubset(0); g_pEffect->EndPass(); } g_pEffect->End(); Prˇ´ıkaz g_pEffect->Begin(&cPasses, 0) prˇipravı´ program k vykona´nı´ a soucˇasneˇ zjistı´, kolik pru˚chodu˚ je prˇi vy´pocˇtu nutne´ prove´st. Zavola´nı´ metody g_pMesh->DrawSubset(0) provede vykreslenı´ objektu a tı´m zpu˚sobı´ vykona´nı´ programu – neexistuje zˇa´dny´ jiny´ zpu˚sob, jak donutit GPU, aby dany´ program spustilo. g_pEffect->EndPass() ukoncˇ´ı vykona´nı´ aktua´lnı´ho pru˚chodu a nakonec g_pEffect->End() ohla´sı´ syste´mu, zˇe kreslenı´ pomocı´ programu skoncˇilo.

OpenGL OpenGL je aplikacˇnı´ rozhranı´ vyvinute´ spolecˇnostı´ Silicon Graphics. Narozdı´l od DirectX je zameˇrˇeno pouze na komunikaci s graficky´m hardware a je dostupne´ na mnoha odlisˇny´ch operacˇnı´ch syste´mech a platforma´ch. Tato knihovna je soubor prˇiblizˇneˇ 250 funkcı´ ve stylu jazyka C a lze ji vyuzˇ´ıt te´meˇrˇ v libovolne´m prostrˇedı´. Dı´ky portabiliteˇ je OpenGL vyuzˇ´ıva´no v profesiona´lnı´ch aplikacı´ch, CAD syste´mech, prˇi vizualizaci veˇdecky´ch vy´pocˇtu˚ a take´ v pocˇ´ıtacˇovy´ch hra´ch. V OpenGL slouzˇ´ı pro pra´ci s programovatelny´mi jednotkami neˇkolik funkcı´. Stejneˇ jako u DirectX je nejprve nutne´ vhodneˇ inicializovat sce´nu. Povolenı´ rozsˇ´ırˇenı´ OpenGL, ktere´ umozˇnˇuje pra´ci s programovatelny´mi jednotkami, zajistı´ vola´nı´ glEnable(GL_FRAGMENT_PROGRAM_ARB).Nynı´ je nutne´ prˇirˇadit programu cˇ´ıslo, pomocı´ ktere´ho bude program identifikova´n. To zajistı´ dvojice prˇ´ıkazu˚ glGenProgramsARB(1, &id); glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, id);

17

5. PLATFORMY PRO KOMUNIKACI S GPU Promeˇnna´ id obsahuje identifika´tor, ke ktere´mu se budou vztahovat na´sledujı´cı´ operace. V dalsˇ´ım kroku lze nacˇ´ıst samotny´ program, ktery´ je opeˇt zapsa´n pomocı´ symbolicky´ch instrukcı´. Ten je nejdrˇ´ıve nutne´ libovolny´m zpu˚sobem nahra´t do pameˇti a pote´ prˇedat GPU: char* buffer[65536]; FILE* fprg = fopen(”program.cg”, ”rb”); buffer[fread(buffer, 65535, 1, fprg)] = 0; glProgramStringARB( GL_FRAGMENT_PROGRAM_ARB, GL_PROGRAM_FORMAT_ASCII_ARB, strlen(buffer), buffer ); V tomto momenteˇ knihovna spolecˇneˇ s ovladacˇem graficke´ karty opeˇt zajistı´ prˇeklad do strojove´ho ko´du pro konkre´tnı´ hardware. V poslednı´m kroku lze opeˇt zaka´zat podporu rozsˇ´ırˇenı´ pro programovatelne´ jednotky (aby nebyly nechteˇneˇ pouzˇity prˇi vykreslova´nı´) prˇ´ıkazem glDisable(GL_FRAGMENT_PROGRAM_ARB). Stejneˇ jako u DirectX je program spusˇteˇn prˇi vykreslova´nı´ neˇktere´ho objektu. V OpenGL zajistı´ aktivaci programu na´sledujı´cı´ posloupnost prˇ´ıkazu˚ prˇi vykreslova´nı´ sce´ny: glEnable(GL_FRAGMENT_PROGRAM_ARB); glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, id); ... /* vykreslenı ´ objektu ˚ */ glDisable(GL_FRAGMENT_PROGRAM_ARB);

5.2 Vysˇsˇı´ programovacı´ jazyky Za´vislost na instrukcˇnı´ sadeˇ lze odstranit pouzˇitı´m vysˇsˇ´ıho programovacı´ho jazyka a prˇekladacˇe, ktery´ generuje ko´d v za´vislosti na konkre´tnı´ platformeˇ. Soucˇasneˇ se tı´m vy´razneˇ zjednodusˇsˇ´ı a zrychly´ vy´voj programu˚. I prˇesto vsˇak ani tato varianta nenı´ prˇ´ılisˇ vhodna´ pro obecne´ vy´pocˇty na GPU, protozˇe programa´tor musı´ ovla´dat principy pouzˇ´ıvane´ v pocˇ´ıtacˇove´ grafice.

HLSL High Level Shading Language (HLSL) [6] je programovacı´ jazyk urcˇeny´ pro vy´voj programu˚ pro GPU, jehozˇ syntakticke´ konstrukce jsou podobne´ jazyku C. HLSL je podporova´n prˇ´ımo rozhranı´m DirectX, ktere´ umozˇnuje prˇekla´dat ko´d za beˇhu,

18

5. PLATFORMY PRO KOMUNIKACI S GPU nicme´neˇ Microsoft poskytuje take´ samostatny´ prˇekladacˇ fxc. Za´pis v HLSL mu˚zˇe vypadat na´sledovneˇ: struct v2p { float4 color: COLOR0; }; struct p2f { float4 color: COLOR0; }; void main(in v2p IN, out p2f OUT) { float4 t = IN.color*float4(0.299, 0.587, 0.114, 0); float grey = t.x + t.y + t.z; OUT.color = float4(grey, grey, grey, IN.w); } Prˇedchozı´ program prova´dı´ jednoduchou cˇinnost – prˇevod barevne´ho obra´zku na stupneˇ sˇede´ barvy. Struktura v2p definuje forma´t vstupnı´ch parametru˚, ktere´ jsou vypocˇ´ıta´ny v prˇedchozı´ch fa´zı´ch procesu. p2f definuje forma´t vy´stupnı´ch parametru˚. Teˇlo programu je zapsa´no ve funkci main. Nejdrˇ´ıve se ze vstupu prˇecˇte hodnota barvy zpracova´vane´ho bodu, ktera´ se po slozˇka´ch vyna´sobı´ koeficienty intenzity pro jednotlive´ barvy (cˇervena´, zelena´, modra´). Vy´sledna´ hodnota se da´le secˇte a ulozˇ´ı do pomocne´ promeˇnne´, ktera´ pote´ obsahuje vy´slednou intenzitu. Ta se pak ulozˇ´ı do vsˇech barevny´ch slozˇek vy´stupu. Typ float4 je struktura, ktera´ obsahuje 4 polozˇky typu float – x, y, z, w. V prˇ´ıpadech, kdy promeˇnna´ tohoto typu obsahuje u´daje o barveˇ, je slozˇka w obvykle vyuzˇita pro urcˇenı´ pru˚hlednosti bodu.

Cg Cg [3] je zkratka vy´razu C for graphics. Jedna´ programovacı´ jazyk s podobny´mi vlastnostmi jako ma´ HLSL. Cg je produkt spolecˇnosti nVidia a je mozˇne´ jej pouzˇ´ıt pomocı´ rozhranı´ DirectX a narozdı´l od HLSL take´ pomocı´ OpenGL. Programy je mozˇne´ prˇekla´dat v dobeˇ beˇhu nebo je mozˇne´ vyuzˇ´ıt externı´ho prˇekladacˇe cg. Na´sleduje prˇ´ıklad jednoduche´ho programu: struct pixel_in { float4 color: COLOR0; }; struct pixel_out { float4 color: COLOR0; }; pixel_out main(pixel_in IN) { pixel_out OUT; float4 t = IN.color*float4(0.299, 0.587, 0.114, 0); float grey = t.x + t.y + t.z;

19

5. PLATFORMY PRO KOMUNIKACI S GPU OUT.color = float4(grey, grey, grey, IN.w); return OUT; } Prˇedchozı´ ko´d opeˇt prova´dı´ prˇevod barevne´ho obra´zku na stupneˇ sˇedi. Na prvnı´ pohled je patrne´, zˇe se struktura programu vy´razneˇ nelisˇ´ı od za´pisu v HLSL. Program obsahuje deklarace vstupu a vy´stupu (pixel_in, pixel_out). Funkce main nynı´ prˇebı´ra´ pouze vstupnı´ parametr a vy´stup vracı´ jako svou na´vratovou hodnotu.

5.3 Transparentnı´ komunikace Pro u´cˇely obecny´ch vy´pocˇtu˚ je vy´hodne´ pouzˇ´ıt na´stroje, ktere´ se pokousˇ´ı skry´t detaily nutne´ prˇi komunikaci s GPU a snazˇ´ı se by´t transparentnı´. V praxi to znamena´, zˇe prˇi psanı´ programu˚ pro GPU mu˚zˇe programa´tor vyuzˇ´ıt podobne´ techniky jako u programu˚ pro CPU.

Sh Pomocı´ Sh [8] lze psa´t aplikace pro graficke´ procesory prˇ´ımo v jazyce C++. Samotny´ na´stroj je v podstateˇ knihovna, ktera´ umozˇnˇuje prˇekla´dat specia´lnı´ konstrukce do strojove´ho ko´du pro GPU. Takto prˇedprˇipravene´ programy pak na vyzˇa´da´nı´ do GPU nahraje a spustı´ vy´pocˇet. Prˇestozˇe je Sh vysoce transparentnı´, lze jej vyuzˇ´ıt k obecny´m vy´pocˇtu˚m stejneˇ jako pro graficke´ aplikace. Programu napsany´ pomocı´ Sh mu˚zˇe vypadat takto: int main() { shInit(); ShProgram prg = SH_BEGIN_PROGRAM(”gpu:stream”) { ShInputColor4f in; ShOutputColor4f out; ShAttrib4f t = in*ShAttrib4f(0.299, 0.587, 0.114, 0); ShAttrib1f grey = t(0) + t(1) + t(2); out = ShOutputColor4f(grey, grey, grey, in(4)); } SH_END; float data[] = { 1.0, 0.5, -0.5, 1 };

20

5. PLATFORMY PRO KOMUNIKACI S GPU ShHostMemoryPtr mem_in = new ShHostMemory( sizeof(float)*4, data, SH_FLOAT ); ShChannel<ShColor4f> in(mem_in, 1); float outdata[4]; ShHostMemoryPtr mem_out = new ShHostMemory( sizeof(float)*4, outdata, SH_FLOAT ); ShChannel<ShColor4f> out(mem_out, 1); out = prg << in; mem_out->hostStorage()->sync(); float* results = static_cast( mem_out->hostStorage()->data() ); std::cout << ”out = (” << results[0] << ”, ” << results[1] << ”, ” << results[2] << ”)” << endl; return 0; } Program opeˇt prova´dı´ prˇevod mezi barevny´mi a sˇedy´mi obra´zky. V tomto prˇ´ıpadeˇ je vsˇak ko´d pro GPU popsa´n specia´lnı´ konstrukcı´ v jazyce C++, ktera´ je definova´na v knihovneˇ Sh (SH_BEGIN_PROGRAM, SH_END). Struktura samotne´ho ko´du je opeˇt velmi podobna´ (prˇ´ıstup k jednotlivy´m slozˇka´m typu˚ Sh* je zajisˇteˇn opera´torem ()). Na rozdı´l od prˇedchozı´ch na´stroju˚ vsˇak Sh umozˇnˇuje take´ samotne´ nacˇtenı´ a spusˇteˇnı´ programu. Nejdrˇ´ıve jsou vytvorˇeny dveˇ textury (new ShHostMemory( ... ), ktere´ jsou sva´za´ny s datovy´mi kana´ly (ShChannel). Pote´ je spusˇteˇn samotny´ program (out = prg << in). Na´sleduje synchronizace, ktera´ po dokoncˇenı´ vy´pocˇtu zkopı´ruje data zpeˇt do syste´move´ pameˇti.

BrookGPU BrookGPU [1, 9] je narozdı´l od prˇedchozı´ch na´stroju˚ urcˇen vy´hradneˇ pro obecne´ vy´pocˇty. Pomocı´ BrookGPU byly prova´deˇny experimenty souvisejı´cı´ s touto pracı´ a podrobneˇji se mu veˇnuje na´sledujı´cı´ kapitola.

21

5. PLATFORMY PRO KOMUNIKACI S GPU

5.4 Srovna´nı´ na´stroju˚ Psanı´ programu˚ v symbolicky´ch instrukcı´ch je pomeˇrneˇ cˇasoveˇ na´rocˇne´ a prˇina´sˇ´ı rˇadu prˇeka´zˇek, ktere´ je nutno prˇi programova´nı´ prˇekonat. Na druhou stranu je to prostrˇedek, ktery´m se da´ dosa´hnout nejlepsˇ´ıho vy´konu provedenı´m optimalizacı´, ktere´ prˇekladacˇ nezvla´dne. Prˇi programova´nı´ graficky´ch aplikacı´ se cˇasto vyuzˇ´ıvajı´ jazyky HLSL nebo Cg, protozˇe umozˇnujı´ psa´t vizua´lnı´ efekty elegantnı´m zpu˚sobem ve stylu jazyka C. Naopak pro psanı´ programu˚ pro obecne´ vy´pocˇty je vhodneˇjsˇ´ı pouzˇ´ıt Sh nebo BrookGPU. Sh prˇedstavuje rozumny´ kompromis, ktery´ jednak obaluje veˇtsˇinu za´kladnı´ch u´konu˚ souvisejı´cı´ch s inicializacı´ GPU a za´rovenˇ ponecha´va´ programa´torovi jistou kontrolu nad prova´deˇny´mi kroky. Naopak BrookGPU je plneˇ transparentnı´, jeho cı´lem je osvobodit uzˇivatele od technologicke´ho pozadı´.

22

Kapitola 6

BrookGPU BrookGPU [1, 9] je na´stroj, ktery´ umozˇnˇuje vyuzˇ´ıvat vy´pocˇetnı´ potencia´l graficky´ch procesoru˚ transparentnı´m zpu˚sobem. Obsahuje prˇekladacˇ jazyka Brook, cozˇ je rozsˇ´ırˇenı´ jazyka C prˇizpu˚sobene´ pro paralelnı´ vy´pocˇty s datovy´mi proudy. Soucˇa´stı´ ´ cˇeje take´ beˇhova´ knihovna, ktera´ zajisˇt’uje komunikaci s graficky´m hardware. U lem tohoto volneˇ sˇirˇitelne´ho balı´ku je kromeˇ zprostrˇedkova´nı´ mozˇnosti vytva´rˇet aplikace pro GPU take´ demonstrace obecny´ch vy´pocˇtu˚ na graficky´ch procesorech a vy´zkum mozˇnostı´ programove´ho modelu zalozˇene´ho na operacı´ch s datovy´mi proudy.

6.1 Jazyk Program se skla´da´ z konstrukcı´ jazyka C, ktere´ jsou obohaceny o mozˇnost deklarovat datove´ proudy a specia´lnı´ funkce oznacˇovane´ jako kernel.

Datove´ Proudy Proud je novy´ datovy´ typ, ktery´ reprezentuje sadu dat, ktera´ mohou by´t zpracova´na paralelneˇ. Deklarace proudu je podobna´ deklaraci pole a vypada´ na´sledovneˇ: float a<8, 8>; Prˇedchozı´ prˇ´ıklad vytva´rˇ´ı dvourozmeˇrny´ datovy´ proud a, jehozˇ prvky jsou typu float. Celkoveˇ proud obsahuje 64 prvku˚ a ma´ podobu matice o rozmeˇrech 8 na 8. Proud ma´ rˇa´dkovou reprezentaci, deklarace typu <10> je ekvivalentnı´ <1, 10>, prˇ´ıpadneˇ <1, 1, 10>. Pra´ce s datovy´mi proudy ma´ na rozdı´l od beˇzˇny´ch polı´ jista´ omezenı´, ktera´ jsou zpu˚sobena vnitrˇnı´ architekturou BrookGPU: 

prˇ´ımy´ prˇ´ıstup (a[1][0]) je prˇ´ıpustny´ pouze uvnitrˇ kernelu˚



nenı´ povolena staticka´ inicializace (float a<10> =



proudy mohou by´t deklarova´ny pouze na za´sobnı´ku (loka´lneˇ)



mimo kernely lze cˇ´ıst z a zapisovat do proudu pouze pomocı´ specia´lnı´ch opera´toru˚ streamRead a streamWrite streamRead(a, data); streamWrite(a, data);

23

2.0, 2.1, ... )

f

6. BROOKGPU Jazyk navı´c kromeˇ standardnı´ho typu float obsahuje take´ typy float2, float3 a float4, ktere´ jsou definova´ny na´sledovneˇ: typedef struct { float x, y; } float2; typedef struct { float x, y, z; } float3; typedef struct { float x, y, z, w; } float4;

Kernely Kernely jsou zvla´sˇtnı´ funkce, ktere´ pracujı´ s datovy´mi proudy a jsou spousˇteˇny paralelneˇ. Zavola´nı´ kernelu na sadu vstupnı´ch proudu˚ ma´ stejny´ efekt jako aplikace teˇla kernelu na kazˇdy´ jednotlivy´ prvek, ovsˇem v tomto prˇ´ıpadeˇ probı´hajı´ vy´pocˇty na neˇkolika prvcı´ch soucˇasneˇ. Pokud se operace prova´dı´ prˇ´ımo na GPU, jsou datove´ proudy prˇeneseny do pameˇti graficke´ho adapte´ru a kernely jsou prˇelozˇeny do strojove´ho ko´du pro graficky´ procesor. Definice kernelu˚ prˇipomı´na´ definici funkce, za´pis navı´c prˇedcha´zı´ klı´cˇove´ slovo kernel a na´vratova´ hodnota kernelu musı´ by´t vzˇdy void. V deklaraci musı´ by´t jeden proud oznacˇen jako vy´stupnı´ klı´cˇovy´m slovem out. Definice mu˚zˇe vypadat takto: kernel void k( float s<>, float3 f, float a[10][10], out float o<> ) { ... } V tomto prˇ´ıpadeˇ bude teˇlo kernelu k zavola´no na kazˇdy´ prvek proudu s. Prˇi vyvola´nı´ teˇla obsahuje promeˇnna´ s hodnotu prˇ´ıslusˇne´ho prvku a nelze do nı´ zapisovat. Promeˇnna´ f je konstantnı´m parametrem, ktery´ bude mı´t pro vsˇechny prvky stejnou hodnotu, stejneˇ jako promeˇnna´ a. Ta ma´ vsˇak charakter dvourozmeˇrne´ho pole, k jehozˇ prvku˚m lze prˇistupovat pomocı´ opera´toru []. Jako vstup v podobeˇ pole mu˚zˇe by´t prˇeda´n libovolny´ datovy´ proud. Kazˇde´ provedenı´ teˇla kernelu produkuje jednu hodnotu ve vy´stupnı´m proudu, kterou zastupuje promeˇnna´ o. Jejı´ hodnotu lze pouze zapisovat. Teˇlo kernelu mu˚zˇe obsahovat pouze konstrukce, ktere´ jsou podporova´ny v jazycı´ch Cg nebo HLSL. Mezi neˇ patrˇ´ı naprˇ´ıklad vektory, matice nebo neˇktere´ beˇzˇneˇ pouzˇ´ıvane´ funkce jako naprˇ´ıklad sinus, kosinus, logaritmus, atd. Vola´nı´ kernelu je stejne´ jako vola´nı´ ostatnı´ch funkcı´: kernel void k( float s<>, float3 f, float a[10][10], out float o<> ); float s1<100>; float s2<100>; float s3<10,10>; streamRead(s1, data1);

24

6. BROOKGPU streamRead(s2, data2); // spus ˇte ˇnı ´ kernelu ’k’ k(s1, 1.0f, s2, s3); streamWrite(s3, result);

Redukce Jazyk podporuje take´ specia´lnı´ varianty kernelu˚ – redukce. Od beˇzˇny´ch kernelu˚ se lisˇ´ı tı´m, zˇe pocˇet prvku˚ ve vy´stupnı´m proudu mu˚zˇe by´t mensˇ´ı nezˇ v proudu vstupnı´m. Z du˚vodu paralelnı´ implementace je vsˇak vyzˇadova´no, aby operace, kterou redukce prova´dı´, byla komutativnı´ a asociativnı´. Tomuto pozˇadavku vyhovujı´ naprˇ´ıklad operace soucˇet, soucˇin, minimum/maximum, logicky´ soucˇet, logicky´ soucˇin nebo logicka´ nonekvivalence (XOR). Operace rozdı´lu nebo podı´lu naopak nejsou komutativnı´ ani asociativnı´, nicme´neˇ prˇekladacˇ tuto chybu nemusı´ odhalit a tedy chybneˇ definovane´ redukce povedou k nespra´vny´m vy´sledku˚m. Na´sleduje prˇ´ıklad secˇtenı´ vsˇech prvku˚ proudu: void reduce sum ( float a<>, reduce float result<> ) { result = result + a; } Redukce prˇebı´ra´ vzˇdy pouze jeden vstupnı´ a jeden vy´stupnı´ proud stejne´ho typu. Ostatnı´ argumenty mohou by´t pouze konstantnı´. Redukce ma´ narozdı´l od kernelu mozˇnost z vy´stupnı´ho parametru cˇ´ıst hodnotu. Pokud je jako vy´stupnı´ parametr prˇeda´na skala´rnı´ promeˇnna´, pak je vy´sledek redukce jedna hodnota. V prˇ´ıpadeˇ proudu se prˇekladacˇ pokusı´ urcˇit redukcˇnı´ pomeˇry a pokud se mu to nepodarˇ´ı, tak ohla´sı´ chybu. Naprˇ´ıklad pro vstupnı´ proud o rozmeˇrech (100, 200) a vy´stupnı´ proud o velikosti (50, 20) bude po provedenı´ v kazˇde´m prvku ulozˇen vy´sledek redukce obde´lnı´kove´ cˇa´sti vstupu o rozmeˇrech 2 a 10. Vı´ce informacı´ o tomto programovacı´m na´stroji spolecˇneˇ s kompletnı´ dokumentacı´ lze nale´zt v [9].

6.2 Architektura BrookGPU obsahuje dveˇ hlavnı´ soucˇa´sti. Prˇekladacˇ BRCC, ktery´ zpracova´va´ zdrojove´ soubory v jazyce BrookGPU (.br) do zdrojovy´ch souboru˚ jazyka C++ (.cpp). Vy´sledne´ soubory lze prˇelozˇit spolecˇneˇ s beˇhovou knihovnou BrookGPU, cozˇ je druha´ soucˇa´st tohoto na´stroje, ktera´ zajisˇt’uje komunikaci s grafickou kartou. Beˇhova´ knihovna obsahuje programovou vrstvu neza´vislou na konkre´tnı´ architekturˇe, ktera´ implementuje podporu pro za´kladnı´ konstrukce Brooku pro prˇ´ıslusˇny´ hardware. Soucˇa´stı´ je knihovna trˇ´ıd, ktera´ poskytuje jednotne´ rozhranı´, ktere´ je pouzˇ´ıva´no prˇekladacˇem. Implementace funkcı´ urcˇeny´ch pro GPU jsou vytvorˇeny v ru˚zny´ch verzı´ch (pro ru˚zne´ profily hardwarovy´ch jednotek a pro CPU).

25

6. BROOKGPU BrookGPU obsahuje podporu pro platformy DirectX9, OpenGL, NVIDIA NV3x a referencˇnı´ implementaci v C++, ktera´ beˇzˇ´ı na CPU. Pomocı´ promeˇnne´ prostrˇedı´ BRT RUNTIME, ktera´ mu˚zˇe obsahovat hodnoty dx9, ogl, nv30gl nebo cpu, lze vybrat rozhranı´, ktere´ se ma´ pouzˇ´ıt prˇi komunikaci s GPU (kromeˇ volby cpu).

6.3 Prˇı´klad - vy´pocˇet frakta´lu Prˇ´ıkladem aplikace, ktera´ je prˇirozeneˇ paralelizovatelna´, je naprˇ´ıklad vy´pocˇet frakta´lu. Jednı´m ze za´kladnı´ch frakta´lu˚ je hranice Mandelbrotovy mnozˇiny, cozˇ je mnozˇina bodu˚ v komplexnı´ rovineˇ, pro neˇzˇ opakovane´ provedenı´ prˇirˇazenı´ 2 z z + (z; 2 C) nevede k nekonec ˇ ne´mu z (obra´zek 6.1).

Obra´zek 6.1: Mandelbrotova mnozˇina (cˇerneˇ) V praxi se obvykle vy´pocˇet aproximuje tak, zˇe za nekonecˇno se povazˇuje moment, kdy jzj > 2. Pro urcˇenı´ prˇ´ıslusˇnosti do te´to mnozˇiny je nutne´ zkoumat kazˇdy´ bod roviny zvla´sˇt’, a protozˇe prˇi vy´pocˇtu nejsou pouzˇity zˇa´dne´ dalsˇ´ı informace, lze tedy vy´pocˇet prova´deˇt na vsˇech bodech roviny soucˇasneˇ. Program vytvorˇeny´ pomocı´ BroogGPU, ktery´ tento frakta´l pocˇ´ıta´, vypada´ na´sledovneˇ:

26

6. BROOKGPU kernel void fractal(float2 plane<>, out float f<>) { float i, x = 0, y = 0, t; for (i = 1; i < 255 && ((x*x + y*y) < 4.); ++i) { t = x*x - y*y + plane.x; y = 2*x*y + plane.y; x = t; } f = ((x*x + y*y) < 4.)?(0):(i); } Promeˇnna´ plane obsahuje sourˇadnice jednotlivy´ch bodu˚ v rovineˇ ( ). Pro 2 kazˇdy´ bod se neˇkolikra´t zopakuje vy´pocˇet z z + a pru ˚ beˇzˇneˇ se zkouma´ velikost absolutnı´ hodnoty. Vy´stupem programu je pocˇet opakova´nı´, ktery´ je nutny´ prove´st, aby absolutnı´ hodnota prˇesa´hla cˇ´ıslo 2, nebo 0, pokud absolutnı´ hodnota te´to hranice nedosa´hla. Tento vy´sledek se pak pouzˇije prˇi vizualizaci (body, jejichzˇ absolutnı´ hodnota neprˇesa´hla 2, jsou zobrazeny cˇerneˇ).

27

Kapitola 7

Testova´nı´ vy´konu Prvnı´ cˇa´st te´to kapitoly je zameˇrˇena na prˇesnost vy´pocˇtu˚ prova´deˇny´ch na GPU, da´le jsou uvedeny vy´sledky dosazˇene´ prˇi meˇrˇenı´ rychlosti vy´pocˇtu˚. Program pro testova´nı´ vy´konu byl vytvorˇen pomocı´ na´stroje BrookGPU. Testy byly zameˇrˇeny na ru˚zne´ aspekty vy´pocˇtu od velikosti dat prˇes komplexnost operacı´ azˇ po vnitrˇnı´ forma´t parametru˚. Jednotlive´ prˇ´ıpady byly testova´ny na GPU i na CPU (v tomto prˇ´ıpadeˇ byla pouzˇita optimalizovana´ verze, protozˇe referencˇnı´ implementace generovana´ BrookGPU vykazuje nizˇsˇ´ı vy´kon a je urcˇena spı´sˇe pro ladicı´ u´cˇely), aby bylo mozˇne´ porovnat prˇ´ınos migrace vy´pocˇtu na graficky´ procesor.

7.1 Pouzˇity´ hardware Pro u´cˇely te´to pra´ce byla porˇ´ızena graficka´ karta ze se´rie ATI Radeon X1900 s pameˇtı´ o velikosti 512 MB vybavena´ cˇipem s oznacˇenı´m R580, ktery´ ma´ na´sledujı´cı´ vlastnosti: 

384 milionu˚ tranzistoru˚, vy´robnı´ proces 90nm



48 procesoru˚ pro zpracovanı´ pixelu˚ (pixel shaders)



8 procesoru˚ pro zpracova´nı´ vektorovy´ch dat (vertext shaders)



256-bitove´ osmikana´love´ pameˇt’ove´ rozhranı´



nativnı´ podpora sbeˇrnice PCI Express x16

Karta byla osazena do pocˇ´ıtacˇe s procesorem AMD Athlon 64 3700+, ktery´ disponuje pameˇtı´ 512 MB. Na tomto stroji byly prova´deˇny vsˇechny souvisejı´cı´ experimenty (pod operacˇnı´m syste´mem Microsoft Windows XP).

7.2 Prˇesnost vy´pocˇtu Mnozˇina rea´lny´ch cˇ´ısel je nekonecˇna´, dnesˇnı´ pocˇ´ıtacˇe vsˇak majı´ pouze konecˇnou pameˇt’. Z tohoto du˚vodu je nutne´ pro pra´ci s rea´lny´mi cˇ´ısly pouzˇ´ıvat konecˇnou aproximaci. Vhodnou variantou jsou cˇ´ısla s plovoucı´ rˇa´dovou cˇa´rkou (floatingpoint numbers). Ty majı´ na´sledujı´cı´ tvar: mantisa
2exponent



28

7. TESTOVA´NI´ VY´KONU Prvnı´ bit uchova´va´ informaci o zname´nku cˇ´ısla, na´sleduje mantisa a exponent, ktery´ uda´va´, o kolik rˇa´du˚ je desetinna´ cˇa´rka posunuta (vlevo nebo vpravo). Vzhledem k tomu, zˇe je tato reprezentace konecˇna´, je take´ konecˇna´ mnozˇina cˇ´ısel, ktere´ lze v tomto forma´tu uchovat. Z toho plyne, zˇe vy´sledek operace (soucˇet, na´sobenı´, atd.) nemusı´ mı´t vzˇdy reprezentaci v ra´mci te´to mnozˇiny. V takove´m prˇ´ıpadeˇ docha´zı´ k zaokrouhlenı´ na neˇkterou z blı´zky´ch hodnot. Prˇ´ıkladem mu˚zˇe by´t na´sledujı´cı´ vy´pocˇet, ktery´ prova´dı´ soucˇet dvou cˇ´ısel s mantisou o sˇ´ırˇce 4 bity: (16 + 1:5)10 = (1:000
24 + 1:100
20 )2 = (1:0011
24 )2 = 17:510 Vy´sledek nelze zapsat do 4 bitu˚, je tedy nutne´ pouzˇ´ıt zaokrouhlenı´. Nejblizˇsˇ´ı hodnoty, ktere´ lze ve vymezene´m prostoru rerezentovat jsou (17)10 = (1:001
24 )2 a (18)10 = (1:010
24 )2 . Norma IEEE 754–1985 rˇ´ıka´, zˇe se zaokrouhluje vzˇdy na nejblizˇsˇ´ı hodnotu, v prˇ´ıpadeˇ shody na hodnotu, ktera´ je suda´. Zaokrouhlovacı´ chyba, ktera´ takto vznikne, je tedy nejvy´sˇe jedna polovina hodnoty jednotky na poslednı´m mı´steˇ (ULP1 ). Na´vrha´rˇi univerza´lnı´ch procesoru˚ se touto normou rˇ´ıdı´, nicme´neˇ u graficky´ch procesoru˚ to neby´va´ pravidlem.

GPU Paranoia Karl Hillesland a Anselmo Lastra [2] vyvinuli program - GPU Paranoia2 , ktery´ pomocı´ empiricky´ch testu˚ zjistı´, jak prˇesneˇ graficky´ procesor postupuje prˇi vy´pocˇtech s cˇ´ısly s plovoucı´ rˇa´dovou cˇa´rkou. V tabulce 7.1 jsou uvedeny intervaly chyb, ktere´ vzniknou prˇi zaokrouhlova´nı´ na nejblizˇsˇ´ı hodnotu a intervaly chyb, ktere´ vzniknou pouhy´m orˇeza´nı´m bitu˚ prˇete´kajı´cı´ch sˇ´ırˇku mantisy. Tabulka 7.2 obsahuje intervaly chyb nameˇrˇene´ u cˇipu R580 a vy´sledky nameˇrˇene´ v [2] u cˇipu˚ R300 (ATI) a NV35 (nVidia). Vy´pocˇty byly prova´deˇny s cˇ´ısly o velikosti 32 bitu˚ (1 bit zname´nko, 23 bitu˚ mantisa, 8 bitu˚ exponent), v prˇ´ıpadeˇ cˇipu R300 je sˇ´ırˇka mantisy pouze 16 bitu˚.

operace scˇ´ıta´nı´ odcˇ´ıta´nı´ na´sobenı´ deˇlenı´

zaokrouhlenı´ (IEEE–754) h-0.500, 0.500i h-0.500, 0.500i h-0.500, 0.500i h-0.500, 0.500i

orˇ´ıznuta´ hodnota (-1.000, 0.000i (-1.000, 1.000) (-1.000, 0.000i (-1.000, 0.000i

Tabulka 7.1: Chyba vy´pocˇtu - prˇesne´ zaokrouhlenı´ a orˇeza´nı´ (ULP) Vzhledem k tomu, zˇe testovacı´ program vyuzˇ´ıva´ pro urcˇenı´ chyby pouze vhodne´ vzory, nenı´ mozˇne´ na rozdı´l od zaokrouhlova´nı´ na nejblizˇsˇ´ı hodnotu nebo orˇeza´nı´ hranici chyby garantovat. Vzory jsou vsˇak vybı´ra´ny tak, aby meˇly dostatecˇneˇ reprezentativnı´ charakter. Z vy´sledku˚ lze odhadovat, zˇe vsˇechny zmı´neˇne´ 1 2

unit in last place na za´kladeˇ starsˇ´ıho programu Paranoia, ktery´ byl urcˇen pro univerza´lnı´ procesory

29

7. TESTOVA´NI´ VY´KONU operace scˇ´ıta´nı´ odcˇ´ıta´nı´ na´sobenı´ deˇlenı´

R580

R300

NV35

h-1.000, 0.000i

h-1.000, 0.000i

h-1.000, 0.000i

h-0.500, 1.000i

h-1.000, 1.000i

h-0.750, 0.750i

(-1.000, 0.001) h-2.000, 1.097)

h-0.989, 0.125i

h-0.782, 0.625i

h-2.869, 0.094i

h-1.199, 1.375i

Tabulka 7.2: Chyba vy´pocˇtu - vy´sledky (ULP) graficke´ procesory vyuzˇ´ıvajı´ prˇi vy´pocˇtech postupy, ktere´ jsou zalozˇeny na kombinaci zaokrouhlenı´ a orˇeza´nı´, v zˇa´dne´m z prˇ´ıpadu˚ vsˇak nedosahujı´ vy´sledku˚ pozˇadovany´ch normou. Operace deˇlenı´ vykazujı´ vysˇsˇ´ı chyby, cozˇ je pravdeˇpodobneˇ zpu˚sobeno tı´m, zˇe deˇlenı´ je pomeˇrneˇ na´rocˇne´ a v GPU se nahrazuje na´sobenı´m prˇevra´cenou hodnotou.

7.3 Forma´t dat Prˇi pra´ci s datovy´mi proudy programa´tora obvykle nezajı´ma´, jaky´ vnitrˇnı´ forma´t data majı´. Vzhledem k faktu, zˇe GPU jsou u´zce specializova´ny, vsˇak existujı´ instance, ktere´ fungujı´ rychleji prˇ´ıpadneˇ pomaleji v za´vislosti na tom, jak je pro neˇ procesor optimalizova´n.

Rozmeˇry proudu BrookGPU mapuje datove´ proudy na textury, ktere´ jsou ulozˇene´ v pameˇti graficke´ karty a na ktery´ch se vy´pocˇet prova´dı´. V graficky´ch aplikacı´ch majı´ textury obvykle cˇtvercovy´ charakter, z tohoto du˚vodu je take´ proces optimalizova´n pro tyto prˇ´ıpady. Odtud plyne, zˇe pro zvy´sˇenı´ vy´konu je vhodne´ mı´sto datove´ho proudu s jednı´m prˇevazˇujı´cı´m rozmeˇrem pouzˇ´ıt datovy´ proud, jehozˇ rozmeˇry majı´ vyrovnany´ pomeˇr. Tento odhad se potvrdil i prˇi experimenta´lnı´m meˇrˇenı´ (graf 7.1). Testy byly prova´deˇny na na´sledujı´cı´m vy´pocˇtu: kernel void t_float( float a<>, float b<>, float c<>, float d<>, out float f<> ) { float i, s = 0; for (i = 0; i < 127 && (s >= 0 || s <= 0); ++i) s = s + a + b + c + d; f = s; } Prˇi testova´nı´ jsem se pokusil kromeˇ efektivnı´ho zisku zmeˇrˇit take´ dobu samotne´ho vy´pocˇtu (bez datovy´ch prˇenosu˚). Vzhledem k povaze u´lohy a transparentnosti BrookGPU vsˇak tento cˇas nebylo mozˇne´ zmeˇrˇit prˇ´ımo. Cˇista´ de´lka vy´pocˇtu

30

7. TESTOVA´NI´ VY´KONU byla tedy odhadnuta z rozdı´lu mezi celkovy´m cˇasem vy´pocˇtu a dobou, kterou trva´ prˇenos dat mezi pameˇtı´ na graficke´ karteˇ a pameˇtı´ syste´movou. Takto upravene´ vy´sledky prˇedchozı´ho testu jsou zaneseny do grafu 7.2.

Vnitrˇnı´ forma´t dat Jednotlive´ varianty ko´du pro GPU byly vytvorˇeny ve trˇech verzı´ch. Vy´sledek vy´pocˇtu je ve vsˇech prˇ´ıpadech stejny´, lisˇ´ı se vsˇak vstupnı´ forma´t dat. Prvnı´ verze prˇebı´ra´ cˇtyrˇi vstupnı´ parametry typu float, dalsˇ´ı verze prˇebı´ra´ dva vstupnı´ parametry typu float2 a poslednı´ verze prˇebı´ra´ jeden parametr typu float4. V jazyku BrookGPU vypada´ za´pis na´sledovneˇ: kernel void v_float( float a<>, float b<>, float c<>, float d<>, out float f<> ) { /* ko ´d */ } kernel void v_float2( float2 a<>, float2 b<>, out float f<> ) { /* ko ´d */ } kernel void v_float4( float4 a<>, out float f<> ) { /* ko ´d */ } Motivacı´ k tomuto testu je fakt, zˇe v graficky´ch aplikacı´ch je prˇirozene´ pracovat s vı´ceslozˇkovy´mi daty (naprˇ´ıklad barvy ve forma´tu RGBA). Opeˇt lze prˇepokla´dat, zˇe varianty s vı´ce slozˇkami budou poda´vat lepsˇ´ı vy´kon. Vy´sledky pro testy na vy´pocˇtu uvedene´m vy´sˇe v grafu 7.3, respektive v grafu 7.4. Z vy´sleku˚ je patrne´, zˇe v rozporu s prˇedpokladem je nejvysˇsˇ´ıho vy´konu dosazˇeno prˇi pouzˇitı´ typu, ktery´ obsahuje pouze jednu slozˇku. Ostatnı´ varianty jsou pomalejsˇ´ı, cozˇ demonstruje zejme´na odhad hrube´ sı´ly. Za povsˇimnutı´ stojı´, zˇe stejny´ experiment provedeny´ na CPU ma´ pozitivnı´ efekt (graf nenı´ uveden). V tomto prˇ´ıpadeˇ je to zpu˚sobeno prˇ´ıtomnostı´ vyrovna´vacı´ch pameˇtı´, u ktery´ch se zvy´sˇenı´ lokality dat (zpu˚sobene´ v tomto prˇ´ıpadeˇ pouzˇitı´m vı´ceslozˇkovy´ch prvku˚) projevuje navy´sˇenı´m vy´konu. Je vsˇak nutno poznamenat, zˇe u GPU nejsou vyrovna´vacı´ pameˇti pouzˇity, protozˇe by byl jejich efekt eliminova´n velky´mi datovy´mi prˇenosy a dosˇlo by tak k degradaci vy´konu.

7.4 Velikost dat Tato cˇa´st se zaby´va´ vlivem objemu dat, nad ktery´m se vy´pocˇet prova´dı´. Proudy jsou prˇi vy´pocˇtu mapova´ny do textur v graficke´ pameˇti, maxima´lnı´ velikost proudu je tedy omezena jejı´ celkovou velikostı´. Navı´c vsˇak u GPU existujı´ hranice zpu˚sobene´ na´vrhem cˇipu, ktere´ vymezujı´ dostupne´ rozmeˇry textur. V prˇ´ıpadeˇ R580 ma´ nejveˇtsˇ´ı textura v obou rozmeˇrech velikost 2 048 bodu˚. Nejveˇtsˇ´ı mozˇny´ pocˇet prvku˚, ktere´

31

7. TESTOVA´NI´ VY´KONU

relativní rychlost (CPU = 1)

7.5

7

6.5

6

5.5

5 (1,2048)

(2,1024)

(4,512)

(8,256)

(16,128)

(32,64)

rozměry proudu

Obra´zek 7.1: Vliv rozmeˇru datovy´ch proudu˚ na vy´kon

relativní rychlost (CPU = 1)

80 70 60 50 40 30 20 10 (1,2048)

(2,1024)

(4,512) (8,256) rozměry proudu

(16,128)

(32,64)

Obra´zek 7.2: Vliv rozmeˇru datovy´ch proudu˚ na vy´kon (cˇisty´ vy´pocˇet)

32

7. TESTOVA´NI´ VY´KONU

relativní rychlost (CPU = 1)

4.8 4.6 4.4 4.2 4 3.8 3.6 3.4 (64,64)

(128,128)

(256,256)

(512,512)

(1024,1024)

(2048,2048)

rozměry proudu float

float2

float4

Obra´zek 7.3: Vliv vnitrˇnı´ho forma´tu a velikosti dat na vy´kon

relativní rychlost (CPU = 1)

55

50

45

40

35 (64,64)

float

(128,128)

(256,256) (512,512) rozměry proudu float2

(1024,1024)

(2048,2048)

float4

Obra´zek 7.4: Vliv vnitrˇnı´ho forma´tu a velikosti na vy´kon (cˇisty´ vy´pocˇet)

33

7. TESTOVA´NI´ VY´KONU lze souvisle zpracovat je tedy 4 194 304. Vliv pocˇtu zpracova´vany´ch prvku˚ na vy´kon lze vyvodit z grafu˚ 7.3 a 7.4. V obou prˇ´ıpadech je zrˇejme´, zˇe GPU vykazuje optima´lnı´ vy´kon prˇi pra´ci s texturami o velikosti 256 na 256 prvku˚.

7.5 Slozˇitost vy´pocˇtu Dalsˇ´ı test zkouma´, jaky´ vliv ma´ na rychlost vy´pocˇtu pocˇet instrukcı´, ktery´ je prova´deˇn s jednı´m prvkem datove´ho proudu. Vy´sledky experimentu jsou zna´zorneˇny v grafech 7.5 a 7.6. Z prvnı´ho grafu plyne, zˇe absolutnı´ vy´kon roste s pocˇtem instrukcı´, ktere´ se nad jednotlivy´mi prvky vykona´vajı´. Je to zpu˚sobeno tı´m, zˇe v nameˇrˇene´m cˇase ma´ u kratsˇ´ıho vy´pocˇtu velky´ podı´l doba, po kterou se data prˇena´sˇ´ı mezi syste´movou pameˇtı´ a pameˇtı´ na graficke´ karteˇ. Prˇi zvysˇova´nı´ pocˇtu instrukcı´ tento podı´l postupneˇ klesa´ a vı´ce se projevuje sı´la GPU. Ze zkouma´nı´ hrube´ho odhadu cˇiste´ doby vy´pocˇtu je patrne´, zˇe cˇisty´ vy´kon vzhledem k pocˇtu vykonany´ch instrukcı´ zu˚sta´va´ na stejne´ u´rovni. Za´rovenˇ se ukazuje, zˇe GPU je optimalizova´no na pra´ci s texturami o rozmeˇrech (256, 256) azˇ (1024, 1024).

7.6 Testy jednoduchy´ch operacı´ V te´to cˇa´sti jsou uvedeny prˇ´ıklady testovacı´ch programu˚ a take´ absolutnı´ doby vy´pocˇtu˚ (tabulka 7.3).

Soucˇet kernel void sum( float a<>, float b<>, float c<>, float d<>, out float f<> ) { f = a + b + c + d; }

Soucˇin kernel void mul( float a<>, float b<>, float c<>, float d<>, out float f<> ) { f = a * b + c * d; }

Goniometricke´ funkce kernel void sincos( float a<>, float b<>, float c<>, float d<>, out float f<> ) { f = sin(a) * cos(b) + sin(c) * cos(d); }

34

7. TESTOVA´NI´ VY´KONU

relativní rychlost (CPU = 1)

16 14 12 10 8 6 4 2 256

512 1024 počet operací na jednom prvku (64,64) (256,256)

2048

(1024,1024)

Obra´zek 7.5: Vliv slozˇitosti vy´pocˇtu na vy´kon

relativní rychlost (CPU = 1)

54 52 50 48 46 44 42 40 256

512 1024 počet operací na jednom prvku (64,64) (256,256)

2048

(1024,1024)

Obra´zek 7.6: Vliv slozˇitosti vy´pocˇtu na vy´kon (cˇisty´)

35

7. TESTOVA´NI´ VY´KONU Vy´sledky rozmeˇr dat (64, 64) (128, 128) (256, 256) (512, 512) (1024, 1024) (64, 64) (128, 128) (256, 256) (512, 512) (1024, 1024) (64, 64) (128, 128) (256, 256) (512, 512) (1024, 1024)

GPU [s] prˇenos dat1 [s] soucˇet 0.00004324 0.00066250 0.00065751 0.00017073 0.002297 0.0022869 0.00079764 0.00893371 0.00887157 0.00364616 0.0373572 0.0371897 0.0133258 0.148429 0.147395 soucˇin 0.00004324 0.00066203 0.00065751 0.00017089 0.00230591 0.0022869 0.00077336 0.00893306 0.00887157 0.0036703 0.0373506 0.0371897 0.0142121 0.148507 0.147395 goniometricke´ funkce 0.00234764 0.00066392 0.00065751 0.00948351 0.00230731 0.0022869 0.0398428 0.00893512 0.00887157 0.163567 0.0373596 0.0371897 0.712587 0.148439 0.147395 CPU [s]

pomeˇr2 0.065 0.074 0.089 0.097 0.09 0.065 0.074 0.086 0.098 0.096 3.536 4.11 4.459 4.378 4.8

Tabulka 7.3: Vy´sledky testu˚ jednoduchy´ch operacı´ Vy´sledky testu˚ uvedene´ v tabulce naznacˇujı´, zˇe velmi kra´tke´ vy´pocˇty (jednoduchy´ soucˇet nebo soucˇin) prova´deˇne´ na graficke´m procesoru vykazujı´ me´neˇ jak desetinovy´ vy´kon ve srovna´nı´ s CPU. Je to zpu˚sobeno tı´m, zˇe v nameˇrˇene´m cˇase ma´ velky´ podı´l doba, po kterou trva´ prˇenos dat z a do syste´move´ pameˇti.

1 2

doba potrˇebna´ k prˇenesenı´ dat do a z graficke´ pameˇti hodnota uda´va´, kolikra´t je vy´pocˇet na GPU rychlejsˇ´ı nezˇ na CPU

36

Kapitola 8

Za´veˇr Ze sady provedeny´ch testu˚ je mozˇne´ vyvodit krite´ria, podle ktery´ch lze urcˇit, v jaky´ch prˇ´ıpadech je vhodne´ prˇemı´stit vy´pocˇet na GPU a za jaky´ch okolnostı´ to naopak vhodne´ nenı´. Za´kladnı´ podmı´nkou pro efektivnı´ vy´pocˇet je mozˇnost paralelizace. V prˇ´ıpadeˇ, zˇe proble´m nelze rozdeˇlit na soubeˇzˇneˇ vykonatelne´ u´lohy, pravdeˇpodobneˇ nepovede vyuzˇitı´ graficke´ho procesoru k rea´lne´mu zvy´sˇenı´ vy´konu. Druhy´m aspektem je mozˇnost soustrˇedit veˇtsˇinu intenzivnı´ch vy´pocˇtu˚ prˇ´ımo na GPU a z toho plynoucı´ minimalizace datovy´ch toku˚ mezi grafickou a syste´movou pameˇtı´. Pokud vy´pocˇet vyzˇaduje vysokou prˇenost, pak dnesˇnı´ GPU nelze vyuzˇ´ıt, protozˇe pocˇ´ıtajı´ pouze s cˇ´ısly o sˇ´ırˇce 32 bitu˚ a prˇesnost vy´sledku˚ operacı´ nenı´ garantova´na normou. Pro optimalizaci vy´pocˇtu na GPU je da´le vhodne´ prove´st na´sledujı´cı´ kroky: 

pouzˇ´ıvat datove´ proudy (textury), ktere´ majı´ pomeˇr dimenzı´ blı´zky´ hodnoteˇ 1 (majı´ cˇtvercovy´ charakter)



pouzˇ´ıvat datove´ proudy (textury) o velikosti, na kterou je konkre´tnı´ GPU optimalizova´no



vyhnout se pouzˇ´ıva´nı´ datovy´ch typu˚ s vı´ce slozˇkami, pokud by to nevedlo ke zvy´sˇenı´ intenzity vy´pocˇtu

Trancoso a Charalambous [10] provedli podobnou sadu meˇrˇenı´ s procesorem Intel Pentium 4 3.2 GHz HT a grafickou kartou nVidia GeForce FX 5700 LE vybavenou cˇipem NV36. Vzhledem k odlisˇnosti obou syste´mu˚ nelze porovna´vat absolutnı´ vy´sledky, nicme´neˇ poznatky, ke ktery´m dosˇli, vesmeˇs souhlası´ se skutecˇnostı´ nameˇrˇenou v te´to pra´ci.

8.1 Mozˇnost vyuzˇitı´ GPU na operacˇnı´m syste´mu Linux Veˇtsˇina technologiı´ je plneˇ portova´na na operacˇnı´ syste´my typu Linux/Unix. Pro u´cˇely testova´nı´ byl naistalova´n OS SUSE verze 10.1 (beta), ktery´ obsahuje Xserver X.Org. Ovladacˇe obsazˇene´ v te´to distribuci neobsahujı´ podporu pro pokrocˇile´ funkce graficky´ch procesoru˚, ktera´ je nutna´ k ovla´da´nı´ programovatelny´ch jednotek. Instalace proprieta´rnı´ch ovladacˇu˚ vydany´ch vy´robcem cˇipu se bohuzˇel nezdarˇila, cozˇ bylo pravdeˇpodobneˇ zpu˚sobeno faktem, zˇe ovladacˇe jesˇteˇ nebyly pro tento hardware odladeˇny. Je vsˇak pravdeˇpodobne´, zˇe v kra´tke´ dobeˇ budou zverˇejneˇny opravy, ktere´ umozˇnı´ plne´ vyuzˇitı´ i v teˇchto podmı´nka´ch.

37

Literatura [1] Buck, I.; Foley, T.; Horn, D.; aj.: Brook for GPUs: Stream computing on graphics hardware. ACM Transactions on Graphics, rocˇnı´k 23, cˇ. 3 (August), 2003. URL https://graphics.stanford.edu/papers/brookgpu/ [2] Hillesland, K. E.; Lastra, A.: GPU Floating-Point Paranoia. In GP2 – 2004 ACM Workshop on General–Purpose Computing on Graphics Processors, Los Angeles, California, August 7–8 2005, s. C–8. URL http://www.cs.unc.edu/˜ibr/projects/paranoia/gpu˙paranoia.pdf [3] Mark, W. R.; Glanville, R. S.; Akeley, K.; aj.: Cg: A system for programming graphics hardware in a C-like language. ACM Transactions on Graphics, August 2003. URL http://www-csl.csres.utexas.edu/users/billmark/pubs/cgpaper.pdf [4] Metelitsa, B.: Comparing Software Development Approaches for General Purpose GPU Computing. In 21st Computer Science Seminar, April 16 2005. URL http://www.rh.edu/˜rhb/cs˙seminar˙2005/SessionA3/metelitsa.pdf [5] Microsoft: DirectX SDK. Online, 2006, [cit. 2006-05-11]. URL http://msdn.microsoft.com/directx/ [6] Neatware: HLSL Introduction. Online, 2004, [cit. 2006-05-11]. URL http://www.neatware.com/lbstudio/web/hlsl.html [7] Owens, J. D.; Luebke, D.; Govindaraju, N.; aj.: A Survey of General-Purpose Computation on Graphics Hardware. In Eurographics 2005, State of the Art Reports, Dublin, Ireland, August 29–September 2 2005, s. 21–51. URL http://graphics.idav.ucdavis.edu/publications/print˙pub?pub˙id=844 [8] RapidMind Inc.: Sh. Online, 2006, [cit. 2006-05-11]. URL http://www.libsh.org/ [9] Stanford Computer Graphics Laboratory: BrookGPU. Online, 2006, [cit. 200605-11]. URL http://graphics.stanford.edu/projects/brookgpu/ [10] Trancoso, P.; Charalambous, M.: Exploring Graphics Processor Performance for General Purpose Applications. In Eighth Euromicro Conference on Digital System Design (DSD 2005), August 30th – September 3rd 2005. URL http://www2.cs.ucy.ac.cy/˜pedro/publications/dsd2005-gpu.pdf

38