Výpočty zapnuté GPU

Technológia CUDA (Compute Unified Device Architecture) je softvérová a hardvérová architektúra, ktorá umožňuje prácu s počítačmi pomocou GPU NVIDIA, ktoré podporujú technológiu GPGPU (arbitrary computing on video cards). Architektúra CUDA sa prvýkrát objavila na trhu s uvedením ôsmej generácie čipu NVIDIA - G80 a je prítomná vo všetkých nasledujúcich sériách grafických čipov, ktoré sa používajú v rodinách akcelerátorov GeForce, ION, Quadro a Tesla.

CUDA SDK umožňuje programátorom implementovať v špeciálnom zjednodušenom dialekte programovacieho jazyka C algoritmy, ktoré možno spustiť na GPU NVIDIA a ktoré obsahujú špeciálne funkcie v texte programu C. CUDA dáva vývojárovi možnosť podľa vlastného uváženia organizovať prístup k inštrukčnej sade grafického akcelerátora a spravovať jeho pamäť, organizovať na ňom zložité paralelné výpočty.

Príbeh

V roku 2003 boli Intel a AMD v spoločnom preteku o najviac výkonný procesor. V priebehu rokov sa taktovanie výrazne zvýšilo v dôsledku tohto závodu, najmä po vydaní Intel Pentium 4.

Po zvýšení taktovacích frekvencií (v rokoch 2001 až 2003 sa taktovacia frekvencia Pentia 4 zdvojnásobila z 1,5 na 3 GHz) sa používatelia museli uspokojiť s desatinami gigahertzov, ktoré výrobcovia priniesli na trh (v rokoch 2003 až 2005 taktovacie frekvencie zvýšená z 3 na 3,8 GHz).

Architektúry optimalizované pre vysoké takty, ako napríklad Prescott, tiež začali pociťovať ťažkosti, a to nielen vo výrobe. Výrobcovia čipov čelili výzvam pri prekonávaní fyzikálnych zákonov. Niektorí analytici dokonca predpovedali, že Moorov zákon prestane fungovať. To sa však nestalo. Pôvodný význam zákona je často skreslený, ale vzťahuje sa na počet tranzistorov na povrchu kremíkového jadra. Na dlhú dobu zvýšenie počtu tranzistorov v CPU bolo sprevádzané zodpovedajúcim zvýšením výkonu - čo viedlo k skresleniu významu. Potom sa však situácia skomplikovala. Konštruktéri architektúry CPU pristúpili k zákonu redukcie zisku: počet tranzistorov, ktoré bolo potrebné pridať pre želaný nárast výkonu, bol čoraz väčší, čo viedlo k slepej uličke.

Dôvod, prečo sa výrobcovia GPU nestretli s týmto problémom, je veľmi jednoduchý: CPU sú navrhnuté tak, aby dosiahli najlepší výkon v prúde inštrukcií, ktoré spracúvajú rôzne dáta (celé čísla aj čísla s pohyblivou rádovou čiarkou), vykonávajú náhodný prístup do pamäte atď. d. Doteraz sa vývojári snažili poskytnúť väčší paralelizmus inštrukcií – teda vykonávať paralelne čo najviac inštrukcií. Tak sa napríklad pri Pentiu objavilo superskalárne vykonávanie, keď za určitých podmienok bolo možné vykonať dve inštrukcie na takt. Pentium Pro dostalo mimo poradia vykonávanie inštrukcií, čo umožnilo optimalizovať výkon výpočtových jednotiek. Problém je v tom, že paralelné vykonávanie sekvenčného prúdu inštrukcií má zjavné obmedzenia, takže slepé zvyšovanie počtu výpočtových jednotiek neprináša zisk, pretože väčšinu času budú stále nečinné.

Ovládanie GPU je pomerne jednoduché. Pozostáva zo zobratia skupiny polygónov na jednej strane a vygenerovania skupiny pixelov na druhej strane. Polygóny a pixely sú na sebe nezávislé, takže je možné ich spracovávať paralelne. V GPU je teda možné vyčleniť veľkú časť kryštálu pre výpočtové jednotky, ktoré sa na rozdiel od CPU reálne využijú.

GPU sa od CPU líši nielen v tomto. Prístup k pamäti v GPU je veľmi prepojený - ak sa číta texel, potom sa po niekoľkých cykloch načíta susedný texel; keď sa zapíše pixel, susedný sa zapíše po niekoľkých cykloch. Inteligentným usporiadaním pamäte môžete dosiahnuť výkon blízko teoretickej šírky pásma. To znamená, že GPU na rozdiel od CPU nevyžaduje veľkú vyrovnávaciu pamäť, pretože jeho úlohou je urýchliť operácie textúrovania. Stačí niekoľko kilobajtov obsahujúcich niekoľko texelov používaných v bilineárnych a trilineárnych filtroch.

Prvé výpočty na GPU

Úplne prvé pokusy o takúto aplikáciu sa obmedzili na využitie niektorých hardvérových funkcií, ako je rasterizácia a Z-buffering. No v súčasnom storočí s príchodom shaderov začali zrýchľovať výpočet matíc. V roku 2003 bola pre SIGGRAPH pridelená samostatná sekcia pre GPU computing s názvom GPGPU (General-Purpose computation on GPU).

Najznámejší BrookGPU je kompilátor programovacieho jazyka Brook stream, určený na vykonávanie negrafických výpočtov na GPU. Pred jeho objavením si vývojári využívajúci možnosti video čipov na výpočty vybrali jedno z dvoch bežných API: Direct3D alebo OpenGL. To vážne obmedzilo použitie GPU, pretože 3D grafika používa shadery a textúry, o ktorých paralelní programátori nemusia vedieť, používajú vlákna a jadrá. Brook im mohol pomôcť uľahčiť ich úlohu. Tieto streamingové rozšírenia do jazyka C vyvinuté na Stanfordskej univerzite skryli 3D API pred programátormi a prezentovali video čip ako paralelný koprocesor. Kompilátor analyzoval súbor .br s kódom C++ a príponami, čím vytvoril kód prepojený s knižnicou s podporou DirectX, OpenGL alebo x86.

Vzhľad Brooka vzbudil záujem NVIDIA a ATI a ďalej otvoril ich úplne nový sektor - paralelné počítače založené na video čipoch.

Ďalej sa niektorí výskumníci z projektu Brook presunuli do vývojového tímu NVIDIA, aby predstavili hardvérovo-softvérovú paralelnú počítačovú stratégiu, čím sa otvoril nový podiel na trhu. A hlavnou výhodou tejto iniciatívy NVIDIA bolo, že vývojári dokonale poznajú všetky možnosti svojich GPU do najmenších detailov a nie je potrebné používať grafické API a s hardvérom môžete pracovať priamo pomocou ovládača. Výsledkom snaženia tohto tímu je NVIDIA CUDA.

Oblasti použitia paralelných výpočtov na GPU

Keď sa výpočty prenesú na GPU, v mnohých úlohách sa dosiahne zrýchlenie 5-30 krát v porovnaní s rýchlymi univerzálnymi procesormi. Najväčšie čísla (rádovo 100x zrýchlenie a ešte viac!) sa dosahujú na kóde, ktorý nie je príliš vhodný na výpočty pomocou blokov SSE, ale je celkom vhodný pre GPU.

Toto sú len niektoré príklady zrýchlenia syntetického kódu na GPU oproti vektorizovanému kódu SSE na CPU (podľa NVIDIA):

Fluorescenčná mikroskopia: 12x.

Molekulárna dynamika (výpočet neviazaných síl): 8-16x;

Elektrostatika (priama a viacúrovňová Coulombova sumacia): 40-120x a 7x.

Tabuľka, ktorú NVIDIA zobrazuje na všetkých prezentáciách a ktorá zobrazuje rýchlosť GPU vzhľadom na CPU.

Zoznam hlavných aplikácií, v ktorých sa používa výpočtová technika GPU: analýza a spracovanie obrazu a signálu, fyzikálna simulácia, výpočtová matematika, výpočtová biológia, finančné výpočty, databázy, dynamika plynov a kvapalín, kryptografia, adaptívna radiačná terapia, astronómia, spracovanie zvuku, bioinformatika, biologické simulácie, počítačové videnie, dolovanie údajov, digitálne kino a televízia, elektromagnetické simulácie, geografické informačné systémy, vojenské aplikácie, plánovanie ťažby, molekulárna dynamika, magnetická rezonancia (MRI), neurónové siete, oceánografický výskum, fyzika častíc, simulácia skladania proteínov, kvantová chémia, sledovanie lúčov, zobrazovanie, radar, simulácia nádrží, umelá inteligencia, analýza satelitných údajov, seizmický prieskum, chirurgia, ultrazvuk, videokonferencie.

Výhody a obmedzenia CUDA

Z pohľadu programátora je grafický pipeline súborom fáz spracovania. Geometrický blok generuje trojuholníky a rasterizačný blok generuje pixely zobrazené na monitore. Tradičný programovací model GPGPU je nasledujúci:

Na prenos výpočtov na GPU v rámci takéhoto modelu je potrebný špeciálny prístup. Dokonca aj pridávanie dvoch vektorov prvok po prvku bude vyžadovať nakreslenie tvaru na obrazovku alebo do vyrovnávacej pamäte mimo obrazovky. Obrázok je rastrovaný, farba každého pixelu je vypočítaná podľa daného programu (pixel shader). Program načíta vstupné dáta z textúr pre každý pixel, sčíta ich a zapíše do výstupnej vyrovnávacej pamäte. A všetky tieto početné operácie sú potrebné na to, čo je napísané jediným operátorom v bežnom programovacom jazyku!

Preto má použitie GPGPU na všeobecné účely výpočtovej techniky obmedzenie v podobe prílišnej zložitosti, ktorú sa vývojári musia učiť. Áno, a je tu dosť ďalších obmedzení, pretože pixel shader je len vzorec pre závislosť výslednej farby pixelu od jeho súradníc a jazyk pixel shader je jazyk na písanie týchto vzorcov so syntaxou podobnou C. Prvé metódy GPGPU sú šikovným trikom na využitie výkonu GPU, ale bez akéhokoľvek pohodlia. Dáta sú tam reprezentované obrázkami (textúrami) a algoritmus je reprezentovaný rasterizačným procesom. Je potrebné poznamenať, a veľmi špecifický model pamäte a vykonávania.

Hardvérová a softvérová architektúra NVIDIA pre výpočty na GPU od NVIDIA sa líši od predchádzajúcich modelov GPGPU tým, že umožňuje písanie programov pre GPU v reálnom C so štandardnou syntaxou, ukazovateľmi a potrebou minimálneho rozšírenia pre prístup k výpočtovým zdrojom video čipov. CUDA nezávisí od grafických rozhraní API a má niektoré funkcie navrhnuté špeciálne pre všeobecné účely.

Výhody CUDA oproti tradičnému prístupu k výpočtovej technike GPGPU

CUDA poskytuje prístup k 16 KB zdieľanej pamäte na multiprocesor, ktorú možno použiť na organizáciu vyrovnávacej pamäte s vyššou šírkou pásma ako pri načítavaní textúr;

Efektívnejší prenos dát medzi systémom a video pamäťou;

Nie sú potrebné grafické API s redundanciou a réžiou;

Lineárne adresovanie pamäte a zhromažďovanie a rozptyl, schopnosť zapisovať na ľubovoľné adresy;

Hardvérová podpora celočíselných a bitových operácií.

Hlavné obmedzenia CUDA:

Nedostatok podpory rekurzie pre spustiteľné funkcie;

Minimálna šírka bloku je 32 vlákien;

Uzavretá architektúra CUDA, ktorú vlastní NVIDIA.

Slabé stránky programovania s predchádzajúcimi metódami GPGPU spočívajú v tom, že tieto metódy nepoužívajú jednotky vykonávania shaderov vertexov v predchádzajúcich nezjednotených architektúrach, údaje sa ukladajú v textúrach a odosielajú sa do vyrovnávacej pamäte mimo obrazovky a viacpriechodové algoritmy používajú jednotky pixel shader. Obmedzenia GPGPU zahŕňajú: nedostatočne efektívne využitie možností hardvéru, obmedzenia šírky pásma pamäte, žiadna operácia rozptylu (iba zhromažďovanie), povinné používanie grafického API.

Hlavné výhody CUDA oproti predchádzajúcim metódam GPGPU vyplývajú zo skutočnosti, na ktorú je táto architektúra navrhnutá efektívne využitie negrafické výpočty na GPU a používa programovací jazyk C bez potreby prenosu algoritmov do formy vhodnej pre koncept grafického potrubia. CUDA ponúka Nová cesta Výpočtová technika GPU, ktorá nepoužíva grafické rozhrania API a ponúka náhodný prístup k pamäti (rozptyl alebo zhromaždenie). Takáto architektúra neobsahuje nevýhody GPGPU a využíva všetky vykonávacie jednotky a tiež rozširuje možnosti prostredníctvom celočíselnej matematiky a operácií bitového posunu.

CUDA otvára niektoré hardvérové ​​funkcie, ktoré nie sú dostupné z grafických rozhraní API, ako napríklad zdieľanú pamäť. Ide o malé množstvo pamäte (16 kilobajtov na multiprocesor), ku ktorej majú prístup bloky vlákien. Umožňuje vám ukladať najčastejšie používané údaje do vyrovnávacej pamäte a môže poskytnúť ďalšie vysoká rýchlosť v porovnaní s použitím načítania textúr pre túto úlohu. To zase znižuje priepustnosť paralelných algoritmov v mnohých aplikáciách. Napríklad je užitočný pre lineárnu algebru, rýchlu Fourierovu transformáciu a filtre na spracovanie obrazu.

Pohodlnejšie v CUDA a prístupe k pamäti. Programový kód v grafickom API vydáva dáta vo forme 32 s jednoduchou presnosťou hodnôt s pohyblivou rádovou čiarkou (hodnoty RGBA súčasne v ôsmich cieľoch vykresľovania) v preddefinovaných oblastiach a CUDA podporuje bodové nahrávanie - neobmedzený počet záznamov na ľubovoľnej adrese . Takéto výhody umožňujú vykonávať niektoré algoritmy na GPU, ktoré nemožno efektívne implementovať pomocou metód GPGPU založených na grafickom API.

Grafické API tiež musia ukladať dáta do textúr, čo si vyžaduje predchádzajúce zabalenie veľkých polí do textúr, čo komplikuje algoritmus a núti použitie špeciálneho adresovania. A CUDA vám umožňuje čítať dáta na akejkoľvek adrese. Ďalšou výhodou CUDA je optimalizovaná komunikácia medzi CPU a GPU. A pre vývojárov, ktorí chcú pristupovať k nízkej úrovni (napríklad pri písaní iného programovacieho jazyka), CUDA ponúka možnosť nízkoúrovňového programovania v assembleri.

Nevýhody CUDA

Jednou z mála nevýhod CUDA je slabá prenosnosť. Táto architektúra funguje iba na video čipoch tejto spoločnosti a nie na všetkých, ale počnúc sériami GeForce 8 a 9 a zodpovedajúcimi Quadro, ION a Tesla. NVIDIA udáva číslo 90 miliónov video čipov kompatibilných s CUDA.

Alternatívy k CUDA

Rámec pre písanie počítačové programy spojené s paralelným výpočtom na rôznych grafických a centrálnych procesoroch. Rámec OpenCL obsahuje programovací jazyk založený na štandarde C99 a aplikačné programové rozhranie (API). OpenCL poskytuje paralelizmus na úrovni inštrukcií a údajov a je implementáciou techniky GPGPU. OpenCL je úplne otvorený štandard a za jeho používanie sa neplatia žiadne licenčné poplatky.

Cieľom OpenCL je doplniť OpenGL a OpenAL, čo sú otvorené priemyselné štandardy pre 3D počítačovú grafiku a zvuk, využitím výkonu GPU. OpenCL vyvíja a spravuje Khronos Group, neziskové konzorcium, ktoré zahŕňa mnoho významných spoločností vrátane Apple, AMD, Intel, nVidia, Sun Microsystems, Sony Computer Entertainment a ďalších.

CAL/IL (výpočtová abstraktná vrstva/stredne pokročilý jazyk)

ATI Stream Technology je súprava hardvéru a softvérové ​​technológie, ktoré umožňujú použiť GPU AMD v spojení s CPU na zrýchlenie mnohých aplikácií (nielen tých grafických).

Aplikačné oblasti ATI Stream sú aplikácie, ktoré sú náročné na výpočtové zdroje, ako napr finančná analýza alebo spracovanie seizmických údajov. Použitie stream procesora umožnilo zvýšiť rýchlosť niektorých finančných výpočtov až 55-krát v porovnaní s riešením rovnakého problému iba pomocou CPU.

NVIDIA nepovažuje technológiu ATI Stream za veľmi silného konkurenta. CUDA a Stream sú dve rôzne technológie, ktoré sú na rôznych úrovniach vývoja. Programovanie produktov ATI je oveľa náročnejšie – ich jazyk pripomína skôr assembler. Na druhej strane CUDA C je jazyk oveľa vyššej úrovne. Písanie na ňom je pohodlnejšie a jednoduchšie. Pre veľké developerské spoločnosti je to veľmi dôležité. Ak hovoríme o výkone, môžeme vidieť, že jeho špičková hodnota v produktoch ATI je vyššia ako v riešeniach NVIDIA. Ale opäť všetko závisí od toho, ako túto silu získať.

DirectX11 (DirectCompute)

Rozhranie na programovanie aplikácií, ktoré je súčasťou DirectX, sady rozhraní API od spoločnosti Microsoft, ktoré je navrhnuté tak, aby fungovalo na počítačoch kompatibilných s IBM PC. operačné systémy Rodina Microsoft Windows. DirectCompute je navrhnutý na vykonávanie všeobecných výpočtov na GPU a je implementáciou konceptu GPGPU. DirectCompute bol pôvodne publikovaný ako súčasť DirectX 11, ale neskôr bol sprístupnený aj pre DirectX 10 a DirectX 10.1.

NVDIA CUDA v ruskej vedeckej komunite.

Od decembra 2009 programovací model CUDA sa vyučuje na 269 univerzitách po celom svete. V Rusku sa školiace kurzy o CUDA vyučujú na univerzitách v Moskve, Petrohrade, Kazani, Novosibirsku a Perme, Medzinárodnej univerzite prírody spoločnosti a človeka „Dubna“, Spoločnom inštitúte pre jadrový výskum, Moskovskom inštitúte elektroniky Technology, Ivanovo State Power Engineering University, BSTU. V. G. Shukhova, MSTU im. Bauman, RKhTU im. Mendelejev, Ruské výskumné centrum „Kurčatovov inštitút“, Medziregionálne superpočítačové centrum Ruskej akadémie vied, Technologický inštitút Taganrog (TTI SFedU).

Funkcie architektúry AMD/ATI Radeon

Je to podobné ako pri zrode nových biologických druhov, keď sa živé bytosti vyvíjajú, aby zlepšili svoju adaptabilitu na prostredie počas vývoja biotopov. Podobne GPU, počnúc zrýchlenou rastrizáciou a textúrovaním trojuholníkov, vyvinuli ďalšie schopnosti na spúšťanie shader programov na farbenie tých istých trojuholníkov. A ukázalo sa, že tieto schopnosti sú žiadané v negrafických výpočtoch, kde v niektorých prípadoch poskytujú významný nárast výkonu v porovnaní s tradičnými riešeniami.

Analógie uvádzame ďalej - po dlhom vývoji na súši prenikli cicavce do mora, odkiaľ vytlačili bežných morských obyvateľov. Cicavce v konkurenčnom boji využívali ako nové pokročilé schopnosti, ktoré sa objavili na zemskom povrchu, tak aj tie špeciálne získané na prispôsobenie sa životu vo vode. Rovnakým spôsobom GPU, založené na výhodách architektúry pre 3D grafiku, čoraz viac získavajú špeciálne funkcie užitočné pre negrafické úlohy.

Čo teda umožňuje GPU uplatniť si svoj vlastný sektor v oblasti programov na všeobecné použitie? Mikroarchitektúra GPU je postavená veľmi odlišne od bežných CPU a už od začiatku má určité výhody. Grafické úlohy zahŕňajú nezávislé paralelné spracovanie údajov a GPU je natívne viacvláknové. Ale táto paralelnosť je pre neho len radosťou. Mikroarchitektúra je navrhnutá tak, aby využívala veľké množstvo vlákien, ktoré je potrebné vykonať.

GPU pozostáva z niekoľkých desiatok (30 pre Nvidia GT200, 20 pre Evergreen, 16 pre Fermi) procesorových jadier, ktoré sa v terminológii Nvidie nazývajú Streaming Multiprocessor a v terminológii ATI SIMD Engine. V rámci tohto článku ich budeme nazývať miniprocesory, pretože vykonávajú niekoľko stoviek programových vlákien a dokážu takmer všetko, čo bežný CPU, no stále nie všetko.

Marketingové názvy sú mätúce - pre väčšiu dôležitosť označujú počet funkčných modulov, ktoré môžu odčítať a násobiť: napríklad 320 vektorových „jadier“ (jadier). Tieto jadrá sú skôr zrnká. Je lepšie si predstaviť GPU ako viacjadrový procesor s mnohými jadrami vykonávajúcimi veľa vlákien súčasne.

Každý miniprocesor má lokálnu pamäť, 16 KB pre GT200, 32 KB pre Evergreen a 64 KB pre Fermi (v podstate programovateľná vyrovnávacia pamäť L1). Má podobný prístupový čas ako vyrovnávacia pamäť L1 bežného CPU a vykonáva podobné funkcie pri doručovaní údajov funkčným modulom čo najrýchlejšie. V architektúre Fermi môže byť časť lokálnej pamäte nakonfigurovaná ako normálna vyrovnávacia pamäť. V GPU sa lokálna pamäť používa na rýchlu výmenu údajov medzi vykonávajúcimi vláknami. Jedna z obvyklých schém pre program GPU je nasledovná: najprv sa do lokálnej pamäte načítajú údaje z globálnej pamäte GPU. Toto je len obyčajná video pamäť umiestnená (napr systémová pamäť) oddelene od "vlastného" procesora - v prípade videa je spájkovaný niekoľkými mikroobvodmi na textolite grafickej karty. Ďalej niekoľko stoviek vlákien pracuje s týmito údajmi v lokálnej pamäti a zapisuje výsledok do globálnej pamäte, po ktorej sa prenesie do CPU. Je na zodpovednosti programátora, aby napísal inštrukcie pre načítanie a vyloženie dát z lokálnej pamäte. V podstate ide o rozdelenie údajov [špecifickej úlohy] na paralelné spracovanie. GPU podporuje aj atómové inštrukcie zápisu/čítania do pamäte, sú však neefektívne a zvyčajne sú potrebné v konečnej fáze na „zlepenie“ výsledkov výpočtov všetkých miniprocesorov.

Lokálna pamäť je spoločná pre všetky vlákna bežiace v miniprocesore, takže napríklad v terminológii Nvidie sa jej hovorí dokonca zdieľaná a pod pojmom lokálna pamäť sa rozumie presný opak, a to: určitá osobná oblasť samostatného vlákna v globálnom meradle. pamäť, viditeľná a prístupná len pre ňu. Ale okrem lokálnej pamäte má miniprocesor ďalšiu pamäťovú oblasť, vo všetkých architektúrach, objemovo asi štyrikrát väčšiu. Je rozdelená rovnomerne medzi všetky vykonávané vlákna, sú to registre na ukladanie premenných a medzivýsledkov výpočtov. Každé vlákno má niekoľko desiatok registrov. Presný počet závisí od počtu vlákien, ktoré miniprocesor beží. Toto číslo je veľmi dôležité, pretože latencia globálnej pamäte je veľmi vysoká, stovky cyklov a pri absencii vyrovnávacej pamäte nie je kam ukladať medzivýsledky výpočtov.

A ešte jedna dôležitá vlastnosť GPU: „mäkká“ vektorizácia. Každý miniprocesor má veľké množstvo výpočtových modulov (8 pre GT200, 16 pre Radeon a 32 pre Fermi), ale môžu vykonávať iba rovnakú inštrukciu s rovnakou adresou programu. Operandy v tomto prípade môžu byť rôzne, rôzne vlákna majú svoje vlastné. Napríklad pokyn pridajte obsah dvoch registrov: je súčasne vykonávaný všetkými výpočtovými zariadeniami, ale berú sa rôzne registre. Predpokladá sa, že všetky vlákna programu GPU, ktoré vykonávajú paralelné spracovanie údajov, sa vo všeobecnosti pohybujú v paralelnom priebehu programovým kódom. Všetky výpočtové moduly sú teda zaťažované rovnomerne. A ak sa vlákna v dôsledku vetiev v programe rozišli na svojej ceste vykonávania kódu, dôjde k takzvanej serializácii. Potom sa nepoužijú všetky výpočtové moduly, keďže vlákna odovzdávajú na vykonanie rôzne inštrukcie a blok výpočtových modulov dokáže, ako sme už povedali, vykonať iba inštrukciu s jednou adresou. A, samozrejme, výkon zároveň klesá v pomere k maximu.

Výhodou je, že vektorizácia je úplne automatická, nejedná sa o programovanie pomocou SSE, MMX a pod. A samotný GPU si poradí s nezrovnalosťami. Teoreticky je možné písať programy pre GPU bez premýšľania o vektorovej povahe vykonávaných modulov, ale rýchlosť takéhoto programu nebude príliš vysoká. Nevýhodou je veľká šírka vektora. Je to viac ako nominálny počet funkčných modulov a je to 32 pre GPU Nvidia a 64 pre Radeon. Vlákna sú spracované v blokoch vhodnej veľkosti. Nvidia nazýva tento blok vlákien termínom warp, AMD - wave front, čo je to isté. Na 16 výpočtových zariadeniach sa teda v štyroch cykloch (za predpokladu zvyčajnej dĺžky inštrukcie) spracuje „čelná vlna“ dlhá 64 vlákien. Autor v tomto prípade uprednostňuje termín osnova, kvôli asociácii s námorným pojmom osnova, označujúci povraz zviazaný zo stočených povrazov. Takže vlákna sa "krútia" a tvoria integrálny zväzok. „Čelo vlny“ však môže byť spojené aj s morom: pokyny prichádzajú k ovládačom rovnakým spôsobom, ako sa vlny valia jedna za druhou na pobrežie.

Ak všetky vlákna pokročili pri vykonávaní programu rovnako (sú na rovnakom mieste) a teda vykonávajú rovnakú inštrukciu, potom je všetko v poriadku, ale ak nie, spomaľuje sa. V tomto prípade sú vlákna z rovnakej osnovy alebo čela vlny v programe na rôznych miestach, sú rozdelené do skupín vlákien, ktoré majú rovnakú hodnotu čísla inštrukcie (inými slovami, ukazovateľ inštrukcie). A ako predtým, iba vlákna jednej skupiny sa vykonávajú naraz - všetky vykonávajú rovnakú inštrukciu, ale s rôznymi operandami. Výsledkom je, že warp sa vykonáva toľkokrát pomalšie, na koľko skupín je rozdelený a na počte vlákien v skupine nezáleží. Aj keď sa skupina skladá len z jedného vlákna, bude trvať rovnako dlho, kým sa spustí celý warp. V hardvéri sa to realizuje maskovaním určitých vlákien, to znamená, že pokyny sa formálne vykonávajú, ale výsledky ich vykonávania sa nikde nezaznamenávajú a v budúcnosti sa nepoužívajú.

Hoci každý miniprocesor (Streaming MultiProcessor alebo SIMD Engine) vykonáva inštrukcie patriace len jednému warpu (množstvu vlákien) v akomkoľvek danom čase, má niekoľko desiatok aktívnych warpov v spustiteľnej oblasti. Po vykonaní inštrukcií jednej osnovy miniprocesor nevykoná ďalšiu inštrukciu v poradí vlákien tejto osnovy, ale inštrukcie niekoho iného vo warpe. Táto osnova môže byť v programe na úplne inom mieste, rýchlosť to neovplyvní, pretože iba vo vnútri osnovy musia byť pokyny všetkých vlákien rovnaké, aby sa vykonali plnou rýchlosťou.

V tomto prípade má každý z 20 motorov SIMD štyri aktívne vlnové fronty, každé so 64 vláknami. Každé vlákno je označené krátkou čiarou. Celkom: 64×4×20=5120 vlákien

Takže vzhľadom na to, že každá osnova alebo čelo vlny pozostáva z 32-64 vlákien, miniprocesor má niekoľko stoviek aktívnych vlákien, ktoré sa vykonávajú takmer súčasne. Nižšie uvidíme, aké architektonické výhody sľubuje taký veľký počet paralelných vlákien, najskôr však zvážime, aké obmedzenia majú miniprocesory, ktoré tvoria GPU.

Hlavná vec je, že GPU nemá zásobník, kde by sa dali ukladať parametre funkcií a lokálne premenné. Kvôli veľkému počtu závitov pre stoh jednoducho nie je miesto na čipe. Pretože GPU súčasne vykonáva približne 10 000 vlákien s veľkosťou zásobníka jedného vlákna 100 KB, celková veľkosť bude 1 GB, čo sa rovná štandardnému množstvu všetkej video pamäte. Navyše neexistuje spôsob, ako umiestniť zásobník akejkoľvek významnej veľkosti do samotného jadra GPU. Napríklad, ak vložíte 1000 bajtov zásobníka na vlákno, potom iba jeden miniprocesor bude vyžadovať 1 MB pamäte, čo je takmer päťnásobok celkového množstva lokálnej pamäte miniprocesora a pamäte pridelenej na ukladanie registrov.

Preto v programe GPU neexistuje žiadna rekurzia a s volaniami funkcií sa skutočne nemôžete otočiť. Všetky funkcie sú priamo nahradené do kódu pri kompilácii programu. To obmedzuje rozsah GPU na výpočtové úlohy. Niekedy je možné použiť obmedzenú emuláciu zásobníka pomocou globálnej pamäte pre rekurzné algoritmy so známou malou hĺbkou iterácie, ale toto nie je typická aplikácia GPU. Na to je potrebné špeciálne vyvinúť algoritmus, preskúmať možnosť jeho implementácie bez záruky úspešného zrýchlenia v porovnaní s CPU.

Fermi najskôr predstavil možnosť využívať virtuálne funkcie, no opäť je ich použitie obmedzené nedostatkom veľkej rýchlej vyrovnávacej pamäte pre každé vlákno. 1536 vlákien predstavuje 48 KB alebo 16 KB L1, to znamená, že virtuálne funkcie v programe je možné používať pomerne zriedka, inak bude zásobník používať aj pomalú globálnu pamäť, čo spomalí vykonávanie a pravdepodobne neprinesie výhody. v porovnaní s verziou CPU.

GPU je teda prezentované ako výpočtový koprocesor, do ktorého sa načítajú dáta, tie sa nejakým algoritmom spracujú a vznikne výsledok.

Výhody architektúry

GPU však považuje za veľmi rýchly. A v tomto mu pomáha jeho vysoký multithreading. Veľký počet aktívnych vlákien umožňuje čiastočne skryť veľkú latenciu samostatne umiestnenej globálnej videopamäte, ktorá je asi 500 cyklov. Vyrovnáva sa obzvlášť dobre pre kód s vysokou hustotou. aritmetické operácie. Nie je teda potrebná drahá tranzistorová hierarchia vyrovnávacej pamäte L1-L2-L3. Namiesto toho je možné na čip umiestniť mnoho výpočtových modulov, ktoré poskytujú vynikajúci aritmetický výkon. Medzitým sa vykonávajú inštrukcie jedného vlákna alebo warpu, ostatné stovky vlákien v tichosti čakajú na svoje dáta.

Fermi predstavil cache druhej úrovne s veľkosťou cca 1 MB, no s cachemi moderných procesorov sa nedá porovnať, je skôr určená na komunikáciu medzi jadrami a rôzne softvérové ​​triky. Ak sa jeho veľkosť rozdelí medzi všetky desiatky tisíc vlákien, každé bude mať veľmi zanedbateľné množstvo.

Okrem latencie globálnej pamäte je však vo výpočtovom zariadení oveľa viac latencií, ktoré je potrebné skryť. Ide o latenciu prenosu dát v rámci čipu z výpočtových zariadení do vyrovnávacej pamäte prvej úrovne, teda lokálnej pamäte GPU, a do registrov, ako aj do vyrovnávacej pamäte inštrukcií. Registračný súbor, ako aj lokálna pamäť sú umiestnené oddelene od funkčných modulov a rýchlosť prístupu k nim je asi tucet cyklov. A opäť, veľké množstvo vlákien, aktívnych osnov, dokáže túto latenciu efektívne skryť. Navyše, celková šírka pásma (šírka pásma) prístupu k lokálnej pamäti celého GPU, berúc do úvahy počet miniprocesorov, ktoré ju tvoria, je oveľa väčšia ako šírka pásma prístupu k vyrovnávacej pamäti prvej úrovne v moderných CPU. GPU dokáže spracovať podstatne viac údajov za jednotku času.

Okamžite môžeme povedať, že ak GPU nebude vybavené veľkým počtom paralelných vlákien, tak bude mať takmer nulový výkon, pretože bude pracovať rovnakým tempom, ako keby bolo plne vyťažené a odvedie oveľa menej práce. Napríklad, nech zostane len jedno vlákno namiesto 10 000: výkon klesne asi tisíckrát, pretože nielenže sa nenačítajú všetky bloky, ale ovplyvnia to aj všetky latencie.

Problém skrývania latencie je akútny aj pri moderných vysokofrekvenčných CPU, na jeho odstránenie sa používajú sofistikované metódy - deep pipelining, vykonávanie inštrukcií mimo poradia (out-of-order). To si vyžaduje zložité plánovače vykonávania inštrukcií, rôzne vyrovnávacie pamäte atď., čo zaberá miesto na čipe. To všetko je potrebné pre najlepší výkon v režime s jedným vláknom.

Ale pre GPU to všetko nie je potrebné, je to architektonicky rýchlejšie pre výpočtové úlohy s veľkým počtom vlákien. Namiesto toho premení multithreading na výkon, ako keď kameň mudrcov premení olovo na zlato.

GPU bol pôvodne navrhnutý tak, aby optimálne spúšťal shader programy pre trojuholníkové pixely, ktoré sú samozrejme nezávislé a môžu byť vykonávané paralelne. A z tohto stavu sa vyvinul pridaním rôznych funkcií (lokálna pamäť a adresovateľný prístup k videopamäti, ako aj skomplikovanie inštrukčnej sady) do veľmi výkonného výpočtového zariadenia, ktoré je stále možné efektívne použiť iba pre algoritmy, ktoré umožňujú vysoko paralelnú implementáciu. pomocou obmedzeného množstva lokálnej pamäte.

Príklad

Jedným z najklasickejších problémov GPU je problém výpočtu interakcie N telies, ktoré vytvárajú gravitačné pole. Ak ale napríklad potrebujeme vypočítať vývoj sústavy Zem-Mesiac-Slnko, tak GPU je pre nás zlý pomocník: objektov je málo. Pre každý objekt je potrebné vypočítať interakcie so všetkými ostatnými objektmi a tie sú len dva. V prípade pohybu slnečnej sústavy so všetkými planétami a ich mesiacmi (asi pár stoviek objektov) je GPU stále málo efektívny. Viacjadrový procesor však kvôli vysokým režijným nákladom na správu vlákien tiež nebude môcť ukázať všetku svoju silu, bude pracovať v režime s jedným vláknom. Ak však potrebujete vypočítať aj trajektórie komét a objektov pásu asteroidov, potom je to už úloha pre GPU, pretože existuje dostatok objektov na vytvorenie požadovaného počtu paralelných výpočtových vlákien.

GPU bude tiež fungovať dobre, ak je potrebné vypočítať kolíziu guľových hviezdokôp stoviek tisíc hviezd.

Ďalšia príležitosť využiť silu GPU v probléme N-tela sa objaví, keď potrebujete vypočítať veľa individuálnych problémov, aj keď s malým počtom tiel. Napríklad, ak chcete vypočítať vývoj jedného systému pre rôzne možnosti počiatočných rýchlostí. Potom bude možné efektívne využívať GPU bez problémov.

Podrobnosti o mikroarchitektúre AMD Radeon

Uvažovali sme o základných princípoch organizácie GPU, sú spoločné pre video akcelerátory všetkých výrobcov, pretože pôvodne mali jednu cieľovú úlohu - shader programy. Výrobcovia však zistili, že je možné sa nezhodnúť na detailoch mikroarchitektonickej implementácie. Aj keď CPU rôznych výrobcov sú niekedy veľmi odlišné, aj keď sú kompatibilné, ako napríklad Pentium 4 a Athlon alebo Core. Architektúra Nvidie je už všeobecne známa, teraz sa pozrieme na Radeon a vyzdvihneme hlavné rozdiely v prístupoch týchto predajcov.

Grafické karty AMD získali plnú podporu pre výpočtovú techniku ​​na všeobecné účely už od rodiny Evergreen, ktorá bola tiež priekopníkom špecifikácie DirectX 11. Karty rodiny 47xx majú množstvo významných obmedzení, o ktorých bude reč nižšie.

Rozdiely vo veľkosti lokálnej pamäte (32 KB pre Radeon oproti 16 KB pre GT200 a 64 KB pre Fermi) nie sú vo všeobecnosti zásadné. Rovnako ako veľkosť čela vlny 64 vlákien pre AMD oproti 32 vláknam na warp pre Nvidiu. Takmer každý program GPU sa dá jednoducho prekonfigurovať a vyladiť na tieto parametre. Výkon sa môže meniť o desiatky percent, ale v prípade GPU to nie je až také dôležité, pretože program GPU zvyčajne beží desaťkrát pomalšie ako jeho kolega pre CPU, alebo desaťkrát rýchlejšie, prípadne nefunguje vôbec.

Dôležitejšie je použitie AMD technológie VLIW (veľmi dlhé inštruktážne slovo). Nvidia používa skalárne jednoduché inštrukcie, ktoré fungujú na skalárnych registroch. Jeho urýchľovače implementujú jednoduchý klasický RISC. Grafické karty AMD majú rovnaký počet registrov ako GT200, no registre sú 128-bitové vektorové. Každá inštrukcia VLIW pracuje na niekoľkých štvorzložkových 32-bitových registroch, čo je podobné ako SSE, ale možnosti VLIW sú oveľa širšie. Toto nie je SIMD (Single Instruction Multiple Data) ako SSE - tu môžu byť inštrukcie pre každý pár operandov rôzne a dokonca závislé! Napríklad komponenty registra A nech sú pomenované a1, a2, a3, a4; pre register B - podobne. Dá sa vypočítať pomocou jedinej inštrukcie, ktorá sa vykoná v jednom cykle, napríklad číslo a1×b1+a2×b2+a3×b3+a4×b4 alebo dvojrozmerný vektor (a1×b1+a2×b2, a3× b3+a4×b4).

Bolo to možné vďaka nižšej frekvencii GPU ako CPU a výraznému zníženiu technických procesov v posledné roky. To nevyžaduje žiadny plánovač, takmer všetko sa vykonáva za hodiny.

S vektorovými inštrukciami je špičkový výkon Radeonu s jednou presnosťou veľmi vysoký, na teraflopoch.

Jeden vektorový register môže uložiť jedno číslo s dvojnásobnou presnosťou namiesto štyroch jednoduchých čísel s presnosťou. A jedna inštrukcia VLIW môže buď pridať dva páry dvojíc, alebo vynásobiť dve čísla, alebo vynásobiť dve čísla a pridať k tretiemu. Špičkový výkon v double je teda asi päťkrát nižší ako v plaváku. Pre staršie modely Radeon zodpovedá Výkon Nvidia Tesla na novej architektúre Fermi a oveľa vyššom výkone ako dvojité karty na architektúre GT200. V spotrebiteľských grafických kartách Geforce založených na Fermi bola maximálna rýchlosť dvojitých výpočtov znížená štyrikrát.

Schematický diagram práce Radeonu. Je zobrazený iba jeden miniprocesor z 20 paralelne bežiacich

Výrobcovia GPU, na rozdiel od výrobcov CPU (v prvom rade tých, ktorí sú kompatibilní s x86), nie sú viazaní problémami s kompatibilitou. Program GPU sa najskôr skompiluje do nejakého prechodného kódu a keď sa program spustí, ovládač skompiluje tento kód do strojových inštrukcií špecifických pre konkrétny model. Ako je popísané vyššie, výrobcovia GPU to využili tým, že pre svoje GPU vymysleli pohodlnú architektúru ISA (Instruction Set Architecture) a menili ich z generácie na generáciu. V každom prípade to pridalo nejaké percento výkonu kvôli nedostatku (akože zbytočného) dekodéra. AMD však zašlo ešte ďalej a vymyslelo vlastný formát na usporiadanie inštrukcií v strojovom kóde. Nie sú usporiadané postupne (podľa výpisu programu), ale v sekciách.

Najprv prichádza sekcia inštrukcií podmieneného skoku, ktoré majú odkazy na sekcie spojitých aritmetických inštrukcií zodpovedajúcich rôznym vetvám. Nazývajú sa zväzky VLIW (zväzky inštrukcií VLIW). Tieto časti obsahujú iba aritmetické inštrukcie s údajmi z registrov alebo lokálnej pamäte. Takáto organizácia zjednodušuje tok pokynov a ich doručovanie vykonávacím jednotkám. To je o to užitočnejšie, že inštrukcie VLIW sú relatívne veľké. Sú tu aj sekcie s pokynmi na prístup do pamäte.

GPU od oboch výrobcov (Nvidia aj AMD) majú tiež zabudované pokyny na rýchly výpočet základných matematických funkcií, druhej odmocniny, exponentu, logaritmov, sínusov a kosínusov pre jednotlivé presné čísla v niekoľkých cykloch. Na to existujú špeciálne výpočtové bloky. „Prišli“ z potreby implementovať rýchlu aproximáciu týchto funkcií do geometrie shaderov.

Aj keby niekto nevedel, že GPU sa používajú na grafiku, a zoznámil sa iba s technickými charakteristikami, potom podľa tohto znaku mohol hádať, že tieto výpočtové koprocesory pochádzajú z video akcelerátorov. Podobne niektoré črty morských cicavcov viedli vedcov k presvedčeniu, že ich predkovia boli suchozemské tvory.

Ale očividnejšou vlastnosťou, ktorá prezrádza grafický pôvod zariadenia, sú bloky na čítanie dvojrozmerných a trojrozmerných textúr s podporou bilineárnej interpolácie. Sú široko používané v programoch GPU, pretože poskytujú rýchlejšie a jednoduchšie čítanie dátových polí len na čítanie. Jeden z štandardné možnosti Správanie GPU aplikácie je čítať polia počiatočných údajov, spracovať ich vo výpočtových jadrách a zapísať výsledok do iného poľa, ktoré sa potom prenesie späť do CPU. Takáto schéma je štandardná a bežná, pretože je vhodná pre architektúru GPU. Úlohy, ktoré si vyžadujú intenzívne čítanie a zápis do jednej veľkej oblasti globálnej pamäte, teda obsahujúcej dátové závislosti, je ťažké paralelizovať a efektívne implementovať na GPU. Ich výkon bude tiež značne závisieť od latencie globálnej pamäte, ktorá je veľmi veľká. Ak je však úloha opísaná vzorom „čítanie údajov – spracovanie – zápis výsledku“, potom môžete takmer určite získať veľkú podporu z jej vykonania na GPU.

Pre dáta textúr v GPU existuje samostatná hierarchia malých vyrovnávacích pamätí prvej a druhej úrovne. Poskytuje tiež zrýchlenie z použitia textúr. Táto hierarchia sa pôvodne objavila v GPU, aby sa využila lokalita prístupu k textúram: je zrejmé, že po spracovaní jedného pixelu bude susedný pixel (s vysokou pravdepodobnosťou) vyžadovať údaje o textúre blízko seba. Ale mnohé algoritmy pre konvenčné výpočty majú podobnú povahu prístupu k údajom. Takže cache textúr z grafiky budú veľmi užitočné.

Aj keď je veľkosť vyrovnávacích pamätí L1-L2 v kartách Nvidia a AMD približne rovnaká, čo je evidentne spôsobené požiadavkami na optimalitu z hľadiska hernej grafiky, latencia prístupu k týmto vyrovnávacím pamäťám sa výrazne líši. Prístupová latencia Nvidie je vyššia a vyrovnávacie pamäte textúr v Geforce v prvom rade pomáhajú znižovať zaťaženie pamäťovej zbernice, než priamo zrýchľovať prístup k dátam. V grafických programoch to nie je viditeľné, ale je to dôležité pre programy na všeobecné použitie. V Radeone je latencia textúrovej cache nižšia, no latencia lokálnej pamäte miniprocesorov je vyššia. Tu je príklad: pre optimálne násobenie matice na kartách Nvidia je lepšie použiť lokálnu pamäť, maticu tam načítať blok po bloku a pre AMD je lepšie spoliehať sa na vyrovnávaciu pamäť textúr s nízkou latenciou, čítať prvky matice ako potrebné. Ale toto je už dosť jemná optimalizácia a pre algoritmus, ktorý už bol zásadne prenesený na GPU.

Tento rozdiel sa prejavuje aj pri použití 3D textúr. Jeden z prvých výpočtových benchmarkov GPU, ktorý ukázal vážnu výhodu pre AMD, práve využíval 3D textúry, keďže pracoval s trojrozmerným dátovým poľom. A latencia prístupu k textúre v Radeone je výrazne rýchlejšia a 3D puzdro je navyše hardvérovo optimalizovanejšie.

Ak chcete získať maximálny výkon z hardvéru rôznych spoločností, je potrebné vyladiť aplikáciu pre konkrétnu kartu, ale je to rádovo menej významné ako v zásade vývoj algoritmu pre architektúru GPU.

Obmedzenia radu Radeon 47xx

V tejto rodine je podpora výpočtovej techniky GPU neúplná. Sú tam tri dôležité momenty. Po prvé, neexistuje žiadna lokálna pamäť, to znamená, že je tam fyzicky, ale nemá univerzálny prístup požadovaný moderným štandardom programov GPU. Je programovo emulovaný v globálnej pamäti, čo znamená, že nebude mať prospech z jeho používania na rozdiel od plnohodnotného GPU. Druhým bodom je obmedzená podpora rôznych inštrukcií operácií s atómovou pamäťou a inštrukcií synchronizácie. A tretí bod je v poriadku malá veľkosť cache inštrukcií: od určitej veľkosti programu sa rýchlosť niekoľkokrát spomalí. Existujú aj ďalšie menšie obmedzenia. Môžeme povedať, že na tejto grafickej karte budú dobre fungovať iba programy, ktoré sú ideálne vhodné pre GPU. Hoci grafická karta môže vykazovať dobré výsledky v gigaflops v jednoduchých testovacích programoch, ktoré pracujú iba s registrami, je problematické efektívne pre ňu naprogramovať niečo zložité.

Výhody a nevýhody Evergreenu

Ak porovnáme produkty AMD a Nvidia, z hľadiska výpočtovej techniky GPU vyzerá séria 5xxx ako veľmi výkonná GT200. Tak silný, že v špičkovom výkone prekoná Fermiho asi dvaapolkrát. Najmä po znížení parametrov nových grafických kariet Nvidia sa počet jadier znížil. Vzhľad vyrovnávacej pamäte L2 vo Fermi však zjednodušuje implementáciu niektorých algoritmov na GPU, čím sa rozširuje rozsah GPU. Zaujímavé je, že pre dobre optimalizované programy GT200 CUDA predchádzajúcej generácie Fermiho architektonické inovácie často neurobili nič. Zrýchľovali sa úmerne s nárastom počtu výpočtových modulov, teda menej ako dvojnásobne (pre jednoduché čísla s presnosťou), alebo ešte menej, pretože sa nezvýšila šírka pásma pamäte (alebo z iných dôvodov).

A v úlohách, ktoré dobre sedia na architektúre GPU a majú výrazný vektorový charakter (napríklad násobenie matíc), Radeon vykazuje výkon relatívne blízko teoretickému vrcholu a predbieha Fermiho. Nehovoriac o viacjadrových CPU. Najmä pri problémoch s jednoduchými číslami s presnosťou.

Radeon má však menšiu plochu matrice, menší rozptyl tepla, spotrebu energie, vyššiu výťažnosť a teda aj nižšie náklady. A priamo v problémoch 3D grafiky je zisk Fermi, ak existuje, oveľa menší ako rozdiel v oblasti kryštálu. Je to do značnej miery spôsobené tým, že výpočtová architektúra Radeonu so 16 výpočtovými jednotkami na miniprocesor, 64-vláknovým wave frontom a vektorovými inštrukciami VLIW je perfektná pre jeho hlavnú úlohu – výpočtové grafické shadery. Pre veľkú väčšinu bežných používateľov Herný výkon a cena sú prioritou.

Z pohľadu profesionálnych, vedeckých programov poskytuje architektúra Radeon najlepší pomer ceny a výkonu, výkon na watt a absolútny výkon v úlohách, ktoré v princípe dobre zapadajú do architektúry GPU, umožňujú paralelizáciu a vektorizáciu.

Napríklad v plne paralelnom, ľahko vektorizovateľnom probléme výberu kľúča je Radeon niekoľkonásobne rýchlejší ako Geforce a niekoľko desiatokkrát rýchlejší ako CPU.

Zodpovedá to všeobecnej koncepcii AMD Fusion, podľa ktorej by GPU mali dopĺňať CPU, a v budúcnosti byť integrované do samotného jadra CPU, tak ako bol predtým matematický koprocesor prenesený zo samostatného čipu do jadra procesora (to sa stalo asi pred dvadsiatimi rokmi, pred objavením sa prvých procesorov Pentium). GPU bude integrované grafické jadro a vektorový koprocesor pre úlohy streamovania.

Radeon používa zložitú techniku ​​miešania inštrukcií z rôznych vlnových frontov, keď sú vykonávané funkčnými modulmi. Je to jednoduché, pretože pokyny sú úplne nezávislé. Princíp je podobný ako zreťazené vykonávanie nezávislých inštrukcií modernými CPU. Zjavne to umožňuje efektívne vykonávať zložité, viacbajtové vektorové inštrukcie VLIW. Na CPU si to vyžaduje sofistikovaný plánovač na identifikáciu nezávislých inštrukcií alebo použitie technológie Hyper-Threading, ktorá tiež dodáva CPU známe nezávislé inštrukcie z rôznych vlákien.

128 inštrukcií dvoch vlnových front, z ktorých každá pozostáva zo 64 operácií, vykonáva 16 modulov VLIW v ôsmich cykloch. Existuje striedanie a každý modul má v skutočnosti dva cykly na vykonanie celej inštrukcie za predpokladu, že v druhom cykle začne paralelne vykonávať novú. Pravdepodobne to pomáha rýchlo vykonať inštrukciu VLIW ako a1×a2+b1×b2+c1×c2+d1×d2, to znamená vykonať osem takýchto inštrukcií v ôsmich cykloch. (Formálne sa ukazuje, jeden na hodiny.)

Nvidia túto technológiu zjavne nemá. A pri absencii VLIW si vysoký výkon pomocou skalárnych inštrukcií vyžaduje vysokú frekvenciu prevádzky, ktorá automaticky zvyšuje odvod tepla a kladie vysoké nároky na proces (na nútenie obvodu bežať na vyššej frekvencii).

Nevýhodou Radeonu z hľadiska GPU computingu je veľká nechuť k vetveniu. GPU vo všeobecnosti neuprednostňujú vetvenie kvôli vyššie uvedenej technológii vykonávania pokynov: okamžite skupinou vlákien s jednou adresou programu. (Mimochodom, táto technika sa nazýva SIMT: Single Instruction - Multiple Threads (jedna inštrukcia - veľa vlákien), analogicky so SIMD, kde jedna inštrukcia vykonáva jednu operáciu s rôznymi dátami.) . Je jasné, že ak program nie je úplne vektorový, potom čím väčšia je veľkosť čela warpu alebo vlny, tým horšie, pretože keď sa cesta programom rozchádza, vytvárajú sa susedné vlákna. viac skupín, ktorý sa musí vykonávať postupne (sériovo). Povedzme, že sa všetky vlákna rozptýlili, potom v prípade veľkosti osnovy 32 vlákien bude program bežať 32-krát pomalšie. A v prípade veľkosti 64 je rovnako ako v Radeone 64-krát pomalší.

Ide o citeľný, no nie jediný prejav „nechuti“. Vo grafických kartách Nvidia má každý funkčný modul, inak nazývaný jadro CUDA, špeciálnu jednotku na spracovanie vetvy. A vo grafických kartách Radeon pre 16 výpočtových modulov sú len dve vetviace riadiace jednotky (sú odvodené z oblasti aritmetických jednotiek). Takže aj jednoduché spracovanie inštrukcie podmieneného vetvenia, aj keď je jej výsledok rovnaký pre všetky vlákna vo vlnovej časti, zaberie viac času. A rýchlosť klesá.

AMD vyrába aj CPU. Veria, že pre programy s množstvom vetiev je CPU stále vhodnejšie a GPU je určené pre čisto vektorové programy.

Radeon teda poskytuje celkovo menej efektívne programovanie, no v mnohých prípadoch lepší pomer ceny a výkonu. Inými slovami, existuje menej programov, ktoré možno efektívne (výhodne) migrovať z CPU na Radeon, ako programov, ktoré možno efektívne spustiť na Fermi. Ale na druhej strane tie, ktoré sa dajú efektívne preniesť, budú na Radeone v mnohých smeroch fungovať efektívnejšie.

API pre GPU Computing

sami Technické špecifikácie Radeon vyzerá atraktívne, aj keď nie je potrebné idealizovať a absolutizovať GPU výpočty. Ale nemenej dôležitý pre výkon je softvér potrebný na vývoj a spustenie programu GPU - kompilátory z jazyka na vysokej úrovni a run-time, teda ovládač, ktorý interaguje medzi časťou programu bežiaceho na CPU a GPU. sám. Je to ešte dôležitejšie ako v prípade CPU: CPU nepotrebuje ovládač na riadenie prenosu dát a z pohľadu kompilátora je GPU šikovnejší. Kompilátor si napríklad musí vystačiť s minimálnym počtom registrov na ukladanie medzivýsledkov výpočtov, ako aj úhľadne inline volania funkcií, opäť s použitím minima registrov. Koniec koncov, čím menej registrov vlákno používa, tým viac vlákien môžete spustiť a tým viac zaťažiť GPU, čím lepšie skryjete čas prístupu do pamäte.

A tak softvérová podpora produktov Radeon stále zaostáva za vývojom hardvéru. (Na rozdiel od situácie s Nvidiou, kde sa vydanie hardvéru oneskorilo a produkt bol vydaný v oklieštenej forme.) Nedávno bol kompilátor OpenCL od AMD v beta stave s mnohými chybami. Príliš často generoval chybný kód alebo odmietal skompilovať kód zo správneho zdrojového kódu, prípadne sám vykázal chybu a zrútil sa. Až koncom jari prišlo vydanie s vysokým výkonom. Ani to nie je bez chýb, ale je ich podstatne menej a spravidla sa objavujú bokom pri pokuse naprogramovať niečo na hranici správnosti. Pracujú napríklad s typom uchar4, ktorý špecifikuje 4-bajtovú štvorzložkovú premennú. Tento typ je v špecifikáciách OpenCL, ale na Radeone sa s ním neoplatí pracovať, pretože registre sú 128-bitové: rovnaké štyri komponenty, ale 32-bitové. A taká premenná uchar4 bude aj tak zaberať celý register, stále budú potrebné len dodatočné operácie balenia a prístupu k jednotlivým bajtovým komponentom. Kompilátor by nemal mať žiadne chyby, ale neexistujú žiadne kompilátory bez chýb. Dokonca aj kompilátor Intel po 11 verziách má chyby pri kompilácii. Identifikované chyby sú opravené v ďalšom vydaní, ktoré bude vydané bližšie k jeseni.

Stále je však veľa vecí, ktoré treba zlepšiť. Napríklad doteraz štandardný ovládač GPU pre Radeon nepodporuje výpočty GPU pomocou OpenCL. Používateľ si musí stiahnuť a nainštalovať ďalší špeciálny balík.

Najdôležitejšia je však absencia akýchkoľvek knižníc funkcií. Pre reálne čísla s dvojnásobnou presnosťou neexistuje ani sínus, kosínus a exponent. No, toto nie je potrebné pre sčítanie/násobenie matíc, ale ak chcete naprogramovať niečo zložitejšie, musíte napísať všetky funkcie od začiatku. Alebo počkajte na nové vydanie súpravy SDK. ACML bude vydaný čoskoro ( jadro AMD Math Library) pre rodinu Evergreen GPU s podporou základných maticových funkcií.

V súčasnosti sa podľa autora článku použitie Direct Compute 5.0 API javí ako reálne na programovanie grafických kariet Radeon, prirodzene s prihliadnutím na obmedzenia: orientáciu na platformu Windows 7 a Windows Vista. Microsoft má s výrobou kompilátorov bohaté skúsenosti a už čoskoro môžeme očakávať plne funkčné vydanie, Microsoft sa o to priamo zaujíma. Ale Direct Compute je zameraný na potreby interaktívnych aplikácií: niečo vypočítať a okamžite vizualizovať výsledok – napríklad prúdenie kvapaliny po povrchu. To neznamená, že sa nedá použiť jednoducho na výpočty, ale to nie je jeho prirodzený účel. Microsoft napríklad neplánuje do Direct Compute pridávať funkcie knižníc – presne tie, ktoré AMD momentálne nemá. Teda to, čo sa dnes dá efektívne vypočítať na Radeone – niektoré nie veľmi sofistikované programy – sa dá implementovať aj na Direct Compute, ktorý je oveľa jednoduchší ako OpenCL a mal by byť stabilnejší. Navyše je úplne prenosný a pobeží na Nvidii aj AMD, takže program budete musieť skompilovať iba raz, zatiaľ čo implementácie OpenCL SDK od Nvidie a AMD nie sú úplne kompatibilné. (V tom zmysle, že ak vyviniete OpenCL program na systéme AMD s použitím AMD OpenCL SDK, na Nvidii nemusí fungovať tak ľahko. Možno budete musieť skompilovať rovnaký text pomocou súpravy Nvidia SDK. A samozrejme, naopak. )

Potom je v OpenCL veľa redundantných funkcií, pretože OpenCL má byť univerzálnym programovacím jazykom a API pre širokú škálu systémov. A GPU, CPU a Cell. Takže v prípade, že chcete napísať program pre typický používateľský systém (procesor plus grafická karta), nezdá sa, že OpenCL je takpovediac „vysoko produktívne“. Každá funkcia má desať parametrov a deväť z nich musí byť nastavených na 0. A aby ste mohli nastaviť každý parameter, musíte zavolať špeciálnu funkciu, ktorá má tiež parametre.

A najdôležitejšou súčasnou výhodou Direct Compute je, že používateľ nemusí inštalovať špeciálny balík: všetko, čo je potrebné, je už v DirectX 11.

Problémy vývoja výpočtovej techniky GPU

Ak si vezmeme oblasť osobných počítačov, potom je situácia nasledovná: nie je veľa úloh, ktoré vyžadujú veľký výpočtový výkon a v bežnom dvojjadrovom procesore výrazne chýbajú. Vyzeralo to, akoby sa z mora na súš vyšplhali veľké obžerské, no nemotorné príšery a na súši nebolo takmer čo jesť. A prvotné sídla zemského povrchu sa zmenšujú, učia sa menej spotrebovávať, ako sa to vždy stáva, keď je nedostatok prírodných zdrojov. Ak by dnes existovala rovnaká potreba výkonu ako pred 10 – 15 rokmi, výpočtová technika GPU by bola prijatá s nadšením. A tak sa do popredia dostávajú problémy s kompatibilitou a relatívnou zložitosťou programovania GPU. Je lepšie napísať program, ktorý beží na všetkých systémoch, ako program, ktorý je rýchly, ale beží len na GPU.

Vyhliadky pre GPU sú o niečo lepšie, pokiaľ ide o použitie v profesionálnych aplikáciách a sektore pracovných staníc, keďže je väčší dopyt po výkone. Objavujú sa pluginy pre 3D editory s podporou GPU: napríklad na vykresľovanie pomocou sledovania lúčov – nezamieňať s bežným vykresľovaním pomocou GPU! Niečo sa ukazuje aj pre 2D a prezentačné editory, s rýchlejšou tvorbou komplexných efektov. Programy na spracovanie videa tiež postupne získavajú podporu pre GPU. Vyššie uvedené úlohy, vzhľadom na ich paralelný charakter, dobre zapadajú do architektúry GPU, ale teraz bola vytvorená veľmi veľká kódová základňa, odladená a optimalizovaná pre všetky možnosti CPU, takže bude chvíľu trvať, kým sa objavia dobré implementácie GPU.

V tomto segmente sa prejavujú aj také slabiny GPU, ako napríklad obmedzené množstvo videopamäte – cca 1 GB pri bežných GPU. Jedným z hlavných faktorov, ktoré znižujú výkon programov GPU, je potreba výmeny dát medzi CPU a GPU cez pomalú zbernicu a kvôli obmedzenému množstvu pamäte je potrebné preniesť viac dát. A tu vyzerá koncepcia AMD kombinovania GPU a CPU v jednom module sľubne: môžete obetovať veľkú šírku pásma grafickej pamäte pre ľahký a jednoduchý prístup k zdieľanej pamäti, navyše s nižšou latenciou. Táto veľká šírka pásma súčasnej videopamäte DDR5 je oveľa viac priamo žiadaná grafické programy než väčšina výpočtových programov GPU. vo všeobecnosti Spoločná pamäť GPU a CPU jednoducho výrazne rozšíria rozsah GPU, umožnia využiť jeho výpočtové schopnosti v malých čiastkových úlohách programov.

A predovšetkým GPU sú žiadané v oblasti vedeckých výpočtov. Už bolo postavených niekoľko superpočítačov na báze GPU, ktoré vykazujú veľmi vysoké výsledky v teste maticových operácií. Vedecké problémy sú také rozmanité a početné, že vždy existuje súbor, ktorý dokonale zapadá do architektúry GPU, pre ktorú použitie GPU uľahčuje dosiahnutie vysokého výkonu.

Ak si spomedzi všetkých úloh moderných počítačov vyberiete jednu, potom to bude počítačová grafika – obraz sveta, v ktorom žijeme. A architektúra optimálna na tento účel nemôže byť zlá. Toto je taká dôležitá a základná úloha, že hardvér špeciálne navrhnutý na to musí byť univerzálny a optimálny pre rôzne úlohy. Okrem toho sa grafické karty úspešne vyvíjajú.

Jeden z najviac skryté vlastnosti, v nedávnej aktualizácii na Windows 10, je možnosť skontrolovať, ktoré aplikácie používajú vašu grafickú procesorovú jednotku (GPU). Ak ste niekedy otvorili Správcu úloh, pravdepodobne ste sa pozreli na využitie procesora, aby ste zistili, ktoré aplikácie sú najnáročnejšie na procesor. AT najnovšie aktualizácie pridal podobnú funkciu, ale pre GPU GPU. Pomáha pochopiť, ako intenzívne je váš softvér a hry na vašom GPU bez sťahovania softvéru tretích strán. Existuje ďalšia zaujímavá funkcia, ktorá pomáha preniesť váš procesor na GPU. Odporúčam prečítať si, ako si vybrať.

Prečo nemám GPU v Správcovi úloh?

Bohužiaľ, nie všetky grafické karty budú schopné poskytnúť Windowsu štatistiky, ktoré potrebuje na čítanie GPU. Pre istotu môžete túto technológiu rýchlo otestovať pomocou diagnostického nástroja DirectX.

1. Kliknite na " Štart“ a do vyhľadávania napíšte dxdiag spustite diagnostický nástroj DirectX.
2. Prejsť na kartu " Obrazovka", priamo v stĺpci vodičov"mal by si mať Model WDDM verzie vyššej ako 2.0 na použitie grafov GPU v správcovi úloh.

Povoľte graf GPU v Správcovi úloh

Ak chcete vidieť využitie GPU pre každú aplikáciu, musíte otvoriť Správcu úloh.

• Stlačte kombináciu tlačidiel Ctrl + Shift + Esc otvorte Správcu úloh.
• Kliknite kliknite pravým tlačidlom myši kliknite v správcovi úloh na prázdne pole " Názov" a skontrolujte z rozbaľovacej ponuky GPU. Môžete tiež poznamenať GPU jadro aby ste videli, ktoré programy ho používajú.
• Teraz v správcovi úloh sú graf GPU a jadro GPU viditeľné vpravo.

Pozrite si celkový výkon GPU

Môžete sledovať celkové využitie GPU na monitorovanie a analýzu pri veľkom zaťažení. V tomto prípade môžete vidieť všetko, čo potrebujete v " Výkon“ výberom grafický procesor.

Každý prvok GPU je rozdelený do jednotlivých grafov, aby ste získali ešte lepší prehľad o tom, ako sa GPU používa. Ak chcete zmeniť zobrazené grafy, môžete kliknúť na malú šípku vedľa názvu každej úlohy. Táto obrazovka tiež zobrazuje verziu a dátum vášho ovládača, čo je dobrá alternatíva k používaniu DXDiag alebo Device Manager.

Jadier nikdy nie je priveľa...

Moderné GPU sú monštruózne rýchle beštie schopné žuť gigabajty dát. Človek je však prefíkaný a bez ohľadu na to, ako rastie výpočtový výkon, prichádza s úlohami čoraz ťažšie, a tak prichádza moment, kedy musíte so smútkom konštatovať, že je potrebná optimalizácia 🙁

Tento článok popisuje základné pojmy, aby sa uľahčila orientácia v teórii optimalizácie gpu a základné pravidlá, aby sa k týmto pojmom nemuselo pristupovať tak často.

Dôvody, prečo sú GPU účinné pri práci s veľkým množstvom údajov, ktoré vyžadujú spracovanie:

• majú veľké možnosti pre paralelné vykonávanie úloh (veľa, veľa procesorov)
• veľká šírka pásma pamäte

Šírka pásma pamäte- toľko informácií - bitov alebo gigabajtov - možno preniesť za jednotku času, sekundu alebo cyklus procesora.

Jednou z úloh optimalizácie je využitie maximálnej priepustnosti – zvýšenie výkonu priepustnosť(v ideálnom prípade by sa mala rovnať šírke pásma pamäte).

Ak chcete zlepšiť využitie šírky pásma:

• zvýšte množstvo informácií – využite šírku pásma naplno (napríklad každý stream pracuje s float4)
• znížiť latenciu – oneskorenie medzi operáciami

Latencia- časový interval medzi okamihmi, keď si kontrolór vyžiadal konkrétnu pamäťovú bunku, a okamihom, keď boli údaje dostupné procesoru na vykonanie pokynov. Samotné oneskorenie nevieme nijako ovplyvniť – tieto obmedzenia sú prítomné na hardvérovej úrovni. Vďaka tomuto oneskoreniu môže procesor súčasne obsluhovať niekoľko vlákien - zatiaľ čo vlákno A požiadalo o pridelenie pamäte, vlákno B môže niečo vypočítať a vlákno C môže počkať, kým neprídu požadované údaje.

Ako znížiť latenciu, ak sa používa synchronizácia:

• znížiť počet vlákien v bloku
• zvýšiť počet skupín blokov

Využitie zdrojov GPU naplno - Obsadenie GPU

V rozhovoroch o optimalizácii často bliká výraz - obsadenosť gpu alebo obsadenosť jadra- odráža efektívnosť využívania zdrojov - kapacít grafickej karty. Samostatne poznamenávam, že aj keď používate všetky zdroje, neznamená to, že ich používate správne.

Výpočtový výkon GPU sú stovky procesorov chamtivých výpočtov, pri vytváraní programu - jadra (kernelu) - bremeno rozloženia záťaže na nich padá na plecia programátora. Chyba môže viesť k tomu, že väčšina týchto vzácnych zdrojov bude nečinná bez dôvodu. Teraz vysvetlím prečo. Musíte začať z diaľky.

Dovoľte mi pripomenúť, že warp ( osnova v terminológii NVidia, vlnoplocha - v terminológii AMD) - sada vlákien, ktoré súčasne vykonávajú rovnakú funkciu jadra na procesore. Vlákna, zjednotené programátorom do blokov, rozdelí plánovač vlákien na warpy (zvlášť pre každý multiprocesor) - zatiaľ čo jeden warp beží, druhý čaká na spracovanie požiadaviek na pamäť atď. Ak niektoré z osnovných vlákien stále vykonávajú výpočty, zatiaľ čo iné už urobili maximum, dochádza k neefektívnemu využívaniu výpočtového zdroja – ľudovo označovanému ako nečinný výkon.

Každý synchronizačný bod, každá vetva logiky môže vytvoriť takúto nečinnú situáciu. Maximálna divergencia (rozvetvenie logiky vykonávania) závisí od veľkosti warpu. Pre GPU NVidia je to 32, pre AMD 64.

Ak chcete znížiť prestoje viacerých procesorov počas vykonávania warpu:

• minimalizovať bariéry čakacej doby
• minimalizovať divergenciu vykonávacej logiky vo funkcii jadra

Na efektívne vyriešenie tohto problému má zmysel pochopiť, ako sa tvoria osnovy (pre prípad s niekoľkými rozmermi). V skutočnosti je poradie jednoduché - najprv v X, potom v Y a naposledy v Z.

jadro je spúšťané blokmi 64×16, vlákna sú rozdelené na osnovy v poradí X, Y, Z - t.j. prvých 64 prvkov je rozdelených do dvoch osnov, potom druhý atď.

Jadro začína s blokmi 16x64. Prvých a druhých 16 prvkov sa pridá k prvej osnove, tretí a štvrtý prvok sa pridá k druhej osnove atď.

Ako znížiť divergenciu (pamätajte - vetvenie nie je vždy príčinou kritickej straty výkonu)

• keď susedné vlákna majú rôzne cesty vykonávania - veľa podmienok a prechodov na nich - hľadajte spôsoby, ako zmeniť štruktúru
• hľadať nevyvážené zaťaženie vlákien a rozhodne ho odstrániť (to je vtedy, keď máme nielen podmienky, ale kvôli týmto podmienkam prvé vlákno vždy niečo vypočíta a piate sa do tejto podmienky nedostane a je nečinné)

Ako vyťažiť maximum zo zdrojov GPU

Zdroje GPU, žiaľ, majú tiež svoje obmedzenia. A presne povedané, pred spustením funkcie jadra má zmysel definovať limity a zohľadniť tieto limity pri rozdeľovaní záťaže. Prečo je to dôležité?

Grafické karty majú obmedzenia na celkový počet vlákien, ktoré môže vykonávať jeden multiprocesor, maximálny počet vlákien v jednom bloku, maximálny počet warpov na jednom procesore, obmedzenia na rôzne typy pamäte atď. Všetky tieto informácie je možné vyžiadať programovo, prostredníctvom príslušného rozhrania API a predtým pomocou nástrojov zo súpravy SDK. (moduly deviceQuery pre zariadenia NVidia, moduly CLInfo pre grafické karty AMD).

Všeobecná prax:

• počet blokov vlákien/pracovných skupín musí byť násobkom počtu stream procesorov
• veľkosť bloku/pracovnej skupiny musí byť násobkom veľkosti osnovy

Zároveň je potrebné mať na pamäti, že absolútne minimum - na každom procesore sa točia súčasne 3-4 warpy / wayfronty, múdri sprievodcovia radia vychádzať z úvahy - aspoň sedem frontov. Zároveň - nezabudnite na obmedzenia týkajúce sa žehličky!

Udržiavať si všetky tieto detaily v hlave rýchlo omrzí, preto na výpočet obsadenosti gpu NVidia ponúkla nečakaný nástroj – excelovú (!) kalkulačku plnú makier. Tu môžete zadať informácie o maximálnom počte vlákien pre SM, počte registrov a veľkosti zdieľanej (zdieľanej) pamäte dostupnej na stream procesor, a použité parametre na spúšťanie funkcií - a udáva to percentá efektivity využívania zdrojov (a trháte si vlasy, keď si uvedomíte, že nemáte dostatok registrov na využitie všetkých jadier).

informácie o použití:
http://docs.nvidia.com/cuda/cuda-c-best-practices-guide/#calculating-occupancy

Operácie GPU a pamäte

Grafické karty sú optimalizované pre 128-bitové operácie s pamäťou. Tie. v ideálnom prípade by každá manipulácia s pamäťou mala v ideálnom prípade zmeniť naraz 4 štvorbajtové hodnoty. Hlavnou nepríjemnosťou pre programátora je, že moderné kompilátory pre GPU nie sú schopné takéto veci optimalizovať. Toto sa musí vykonať priamo vo funkčnom kóde a v priemere to prináša zlomky percenta nárastu výkonu. Oveľa väčší vplyv na výkon má frekvencia požiadaviek na pamäť.

Problém je nasledovný – každá požiadavka vráti ako odpoveď časť údajov, ktorá je násobkom 128 bitov. A každé vlákno z toho využíva len štvrtinu (v prípade bežnej štvorbajtovej premennej). Keď susedné vlákna súčasne pracujú s údajmi umiestnenými postupne v pamäťových bunkách, znižuje to celkový počet prístupov do pamäte. Tento jav sa nazýva kombinované operácie čítania a zápisu ( spojený prístup - dobrý! aj čítať aj písať) - a so správnou organizáciou kódu ( rýchly prístup k súvislej časti pamäte - zlé!) môže výrazne zlepšiť výkon. Pri organizovaní vášho jadra – pamätajte – súvislý prístup – v rámci prvkov jedného riadku pamäte už práca s prvkami stĺpca nie je taká efektívna. Chcete viac podrobností? Páčilo sa mi toto pdf - alebo google pre výraz " techniky spájania pamäte “.

Vedúce miesto v nominácii „úzke miesto“ je obsadené ďalšou pamäťovou operáciou - kopírovať dáta z hostiteľskej pamäte do GPU . Kopírovanie neprebieha tak či tak, ale z pamäťovej oblasti špeciálne pridelenej ovládačom a systémom: pri požiadavke na skopírovanie údajov systém najprv skopíruje tieto údaje tam a až potom ich nahrá do GPU. Rýchlosť prenosu dát je obmedzená šírkou pásma PCI zbernica Express xN (kde N je počet dátových liniek), prostredníctvom ktorých moderné grafické karty komunikujú s hostiteľom.

Dodatočné kopírovanie pomalej pamäte na hostiteľovi však niekedy predstavuje neopodstatnenú réžiu. Východiskom je použitie tzv pripnutá pamäť - špeciálne označená oblasť pamäte, takže operačný systém s ňou nemôže vykonávať žiadne operácie (napríklad uvoľnenie za účelom výmeny / presunu podľa vlastného uváženia atď.). Prenos dát z hostiteľa na grafickú kartu sa vykonáva bez účasti operačného systému - asynchrónne, cez DMA (priamy prístup do pamäte).

A na záver ešte niečo o pamäti. Zdieľaná pamäť na multiprocesore býva organizovaná vo forme pamäťových bánk obsahujúcich 32-bitové slová – dáta. Počet bánk sa tradične líši od jednej generácie GPU k druhej - 16/32 Ak každé vlákno požaduje údaje od samostatnej banky, všetko je v poriadku. V opačnom prípade sa získa niekoľko požiadaviek na čítanie / zápis do jednej banky a dostaneme - konflikt ( konflikt banky zdieľanej pamäte). Takéto konfliktné volania sú serializované, a preto sa vykonávajú postupne, nie paralelne. Ak všetky vlákna pristupujú k rovnakej banke, použije sa odpoveď „vysielať“ ( vysielať) a nedochádza k žiadnemu konfliktu. Existuje niekoľko spôsobov, ako efektívne riešiť konflikty v prístupe, páčilo sa mi to popis hlavných techník, ako sa zbaviť konfliktov prístupu k pamäťovým bankám – .

Ako urobiť matematické operácie ešte rýchlejšie? Zapamätaj si to:

• výpočty s dvojitou presnosťou sú veľké prevádzkové zaťaženie s fp64 >> fp32
• konštanty vo forme 3.13 v kóde sa štandardne interpretujú ako fp64, ak explicitne nešpecifikujete 3.14f
• na optimalizáciu matematiky nebude zbytočné konzultovať v príručkách - a existujú nejaké príznaky pre kompilátor
• dodávatelia do svojich súprav SDK zahŕňajú funkcie, ktoré využívajú funkcie zariadenia na dosiahnutie výkonu (často na úkor prenosnosti)

Pre vývojárov CUDA má zmysel venovať tomuto konceptu veľkú pozornosť potok cuda, ktoré umožňujú spúšťať niekoľko základných funkcií naraz na jednom zariadení alebo kombinovať asynchrónne kopírovanie údajov z hostiteľa do zariadenia počas vykonávania funkcií. OpenCL zatiaľ takúto funkcionalitu neposkytuje 🙁

Profilovanie nevyžiadanej pošty:

NVifia Visual Profiler je zaujímavý nástroj, ktorý analyzuje jadrá CUDA aj OpenCL.

P.S. Ako dlhší sprievodca optimalizáciou môžem odporučiť googliť všetky druhy sprievodca osvedčenými postupmi pre OpenCL a CUDA.

• ,

Keď už hovoríme o paralelných výpočtoch na GPU, musíme si uvedomiť, v akej dobe žijeme, dnes je doba, keď je všetko na svete tak zrýchlené, že strácame pojem o čase a nevšímame si, ako sa ponáhľa. Všetko, čo robíme, je spojené s vysokou presnosťou a rýchlosťou spracovania informácií, v takýchto podmienkach určite potrebujeme nástroje, aby sme všetky informácie, ktoré máme, spracovali a premenili na dáta, okrem toho, keď už hovoríme o takýchto úlohách, musíme si uvedomiť, že tieto úlohy sú potrebné nielen pre veľké organizácie či megakorporácie, takéto problémy teraz musia riešiť aj bežní užívatelia, ktorí svoje životne dôležité úlohy spojené so špičkovými technológiami riešia doma na osobné počítače! Vznik NVIDIA CUDA nebol prekvapivý, ale skôr opodstatnený, pretože akonáhle bude potrebné spracovávať na PC oveľa náročnejšie úlohy ako doteraz. Práca, ktorá predtým trvala veľmi dlho, bude teraz trvať niekoľko minút, respektíve to ovplyvní celkový obraz celého sveta!

Čo je to GPU Computing

GPU computing je použitie GPU na výpočet technických, vedeckých a každodenných úloh. Výpočet na GPU zahŕňa použitie CPU a GPU s heterogénnym výberom medzi nimi, konkrétne: sekvenčnú časť programov preberá CPU, zatiaľ čo časovo náročné výpočtové úlohy zostávajú na GPU. Vďaka tomu sa úlohy paralelizujú, čo vedie k rýchlejšiemu spracovaniu informácií a skracuje čas potrebný na dokončenie práce, systém sa stáva produktívnejší a dokáže súčasne spracovať viac úloh ako doteraz. Na dosiahnutie takéhoto úspechu však samotná hardvérová podpora nestačí, v tomto prípade je potrebná aj softvérová podpora, aby aplikácia mohla preniesť časovo najnáročnejšie výpočty na GPU.

Čo je CUDA

CUDA je technológia na programovanie algoritmov v zjednodušenom jazyku C, ktorá beží na grafických procesoroch ôsmej generácie a starších akcelerátoroch GeForce, ako aj na zodpovedajúcich kartách Quadro a Tesla od NVIDIA. CUDA vám umožňuje zahrnúť špeciálne funkcie do textu programu C. Tieto funkcie sú napísané v zjednodušenom programovacom jazyku C a bežia na GPU. Počiatočná verzia CUDA SDK bola vydaná 15. februára 2007. Pre úspešný preklad kódu v tomto jazyku obsahuje CUDA SDK svoj vlastný C kompilátor príkazový riadok nvcc od spoločnosti NVIDIA. Kompilátor nvcc je založený na otvorený kompilátor Open64 a je navrhnutý tak, aby preložil kód hostiteľa (hlavný, riadiaci kód) a kód zariadenia (hardvérový kód) (súbory s príponou .cu) do objektových súborov vhodných na zostavenie finálneho programu alebo knižnice v akomkoľvek programovacom prostredí, napr. Microsoft Visual Studio.

Technologické schopnosti

1. Štandardný jazyk C pre paralelný vývoj aplikácií GPU.
2. Hotové knižnice numerickej analýzy pre rýchlu Fourierovu transformáciu a základný balík programov lineárnej algebry.
3. Vyhradený ovládač CUDA pre výpočty s rýchlym prenosom dát medzi GPU a CPU.
4. Možnosť interakcie ovládača CUDA s grafickými ovládačmi OpenGL a DirectX.
5. Podpora operačnej sály Linuxové systémy 32/64-bit, Windows XP 32/64-bit a MacOS.

Výhody technológie

1. Rozhranie CUDA Application Programming Interface (CUDA API) je založené na štandardnom programovacom jazyku C s určitými obmedzeniami. To zjednodušuje a vyhladzuje proces učenia sa architektúry CUDA.
2. 16 KB zdieľaná pamäť medzi vláknami môže byť použitá pre užívateľsky organizovanú vyrovnávaciu pamäť so širšou šírkou pásma ako pri načítavaní z bežných textúr.
3. Efektívnejšie transakcie medzi pamäťou CPU a video pamäťou.
4. Plná hardvérová podpora pre celočíselné a bitové operácie.

Príklad aplikácie technológie

cRark

Najťažšia časť tohto programu je tinktúra. Program má konzolové rozhranie, ale vďaka inštrukciám, ktoré sú súčasťou samotného programu, ho možno použiť. Nasledujúce je krátky návod pre nastavenie programu. Program otestujeme na výkon a porovnáme s iným podobným programom, ktorý nepoužíva NVIDIA CUDA, v tomto prípade so známym programom „Advanced Archive Password Recovery“.

Zo stiahnutého archívu cRark potrebujeme iba tri súbory: crark.exe , crark-hp.exe a password.def . Сrark.exe je nástroj na prelomenie hesiel RAR 3.0 bez zašifrovaných súborov v archíve (t. j. pri otvorení archívu vidíme mená, ale archív nemôžeme rozbaliť bez hesla).

Сrark-hp.exe je nástroj na prelomenie hesla RAR 3.0 príkazového riadku, ktorý zašifruje celý archív (t. j. pri otvorení archívu nevidíme ani názov, ani samotné archívy a nemôžeme archív rozbaliť bez hesla).

Password.def je akýkoľvek premenovaný textový súbor s veľmi malým obsahom (napríklad: 1. riadok: ## 2. riadok: ?* , v takom prípade bude heslo prelomené pomocou všetkých znakov). Password.def je hlavou programu cRark. Súbor obsahuje pravidlá na otvorenie hesla (alebo oblasti znakov, ktorú crark.exe použije pri svojej práci). Viac podrobností o možnostiach výberu týchto znakov je napísaných v textovom súbore získanom otvorením stiahnutého zo stránky od autora programu cRark: russian.def .

Školenie

Hneď musím povedať, že program funguje iba vtedy, ak je vaša grafická karta založená na GPU s podporou úrovne zrýchlenia CUDA 1.1. Séria grafických kariet založených na čipe G80, ako napríklad GeForce 8800 GTX, teda neprichádza do úvahy, pretože majú hardvérovú podporu pre akceleráciu CUDA 1.0. Pomocou CUDA program vyberá iba heslá pre RAR archívy verzie 3.0+. Je potrebné nainštalovať všetok softvér súvisiaci s CUDA, a to:

• Ovládače NVIDIA podporujúce CUDA od verzie 169.21
• NVIDIA CUDA SDK, počnúc verziou 1.1
• Súprava nástrojov NVIDIA CUDA, počnúc verziou 1.1

Vytvárame ľubovoľný priečinok kdekoľvek (napríklad na jednotke C:) a nazývame ho ľubovoľným názvom, napríklad "3.2". Vložili sme tam súbory: crark.exe , crark-hp.exe a password.def a heslom chránený / šifrovaný archív RAR.

Ďalej by ste mali spustiť konzolu príkazového riadka systému Windows a prejsť do vytvoreného priečinka v nej. Vo Windows Vista a 7 by ste mali vyvolať ponuku „Štart“ a do vyhľadávacieho poľa zadať „cmd.exe“, v systéme Windows XP z ponuky „Štart“ najskôr vyvolajte dialógové okno „Spustiť“ a zadajte „cmd.exe“ "v ňom. Po otvorení konzoly zadajte príkaz ako: cd C:\folder\ , v tomto prípade cd C:\3.2.

Nábor v textový editor dva riadky (text môžete uložiť aj ako súbor .bat do priečinka s cRark) na uhádnutie hesla archívu RAR chráneného heslom s nezašifrovanými súbormi:

ozvena vypnutá;
cmd /K crark (názov archívu).rar

uhádnuť heslo heslom chráneného a šifrovaného archívu RAR:

ozvena vypnutá;
cmd /K crark-hp (názov archívu).rar

Skopírujte 2 riadky textový súbor do konzoly a stlačte Enter (alebo spustite súbor .bat).

výsledky

Proces dešifrovania je znázornený na obrázku:

Rýchlosť výberu na cRarku pomocou CUDA bola 1625 hesiel za sekundu. Za jednu minútu, tridsaťšesť sekúnd bolo uhádnuté heslo s 3 znakmi: „q)$“. Pre porovnanie, hrubá sila v Advanced Archive Password Recovery na mojom dvojjadrovom procesore Athlon 3000+ je maximálne 50 hesiel za sekundu a hrubá sila by trvala 5 hodín. To znamená, že výber archívu RAR pomocou bruteforce v cRarku pomocou grafickej karty GeForce 9800 GTX+ je 30-krát rýchlejší ako na CPU.

Pre tých, ktorí majú procesor Intel, dobrú základnú dosku s vysokou frekvenciou systémovej zbernice (FSB 1600 MHz), bude rýchlosť procesora a hrubá sila vyššia. A ak máte štvorjadrový procesor a dvojicu grafických kariet na úrovni GeForce 280 GTX, výkon hesla hrubej sily sa občas zrýchli. Ak zhrnieme príklad, treba povedať, že tento problém bol pomocou technológie CUDA vyriešený len za 2 minúty namiesto 5 hodín, čo naznačuje vysoký potenciál tejto technológie!

závery

Keď sme dnes zvážili technológiu pre paralelné výpočty CUDA, jasne sme videli všetku silu a obrovský potenciál pre rozvoj tejto technológie na príklade programu na obnovu hesla pre RAR archívy. Musím povedať o vyhliadkach tejto technológie, túto technológiu si určite nájde miesto v živote každého človeka, ktorý sa ho rozhodne využiť, či už ide o vedecké úlohy, úlohy súvisiace so spracovaním videa, alebo aj ekonomické úlohy, ktoré si vyžadujú rýchly presný výpočet, to všetko povedie k nevyhnutnému zvýšeniu prácnosti produktivitu, ktorú nemožno ignorovať. K dnešnému dňu sa slovné spojenie „domáci superpočítač“ už začína dostávať do slovníka; je úplne zrejmé, že na to, aby sa takýto objekt premenil na realitu, má už každý dom nástroj s názvom CUDA. Od vydania kariet založených na čipe G80 (2006), veľké množstvo Akcelerátory na báze NVIDIA, ktoré podporujú technológiu CUDA, vďaka ktorým sa sen o superpočítači v každej domácnosti stane skutočnosťou. Propagáciou technológie CUDA NVIDIA zvyšuje svoju dôveryhodnosť v očiach zákazníkov v podobe poskytovania doplnkových funkcií k ich zariadeniam, ktoré si už mnohí zakúpili. Zostáva len veriť, že čoskoro sa CUDA rozvinie veľmi rýchlo a umožní používateľom naplno využívať všetky možnosti paralelného výpočtov na GPU.