OpenCL

5.9.2009 11:44 | Přečteno: 2763× | | poslední úprava: 5.9.2009 16:52

OpenCL (Open Computing Language) je frameworkem pro psaní výpočetních jader aplikací určených pro běh v heterogenním prostředí (CPU, GPU, akcelerační karty např. s Cell procesory, nVidia Tesla, …). Už z toho je patrné, že se ve skutečnosti rozhodně NEjedná o CUDA v bledě modrém s fialovými puntíky, ačkoliv by se to mohlo na základě informací, které prezentuje o této technologii Apple, zdát. Šíře záběru je podstatně větší a díky otevřenosti přináší naději na sjednocení kódu pro různá zařízení poskytující výpočetní výkon. OpenCL má ambice stát se v tomto odvětvítím, čím je OpenGL pro 3D grafiku.

Motivace

Teoretický výkon současných nejlepších x86 procesorů se čtyřmi jádry (virtuálně osmi s HyperThreadingem) a frekvenci přes 3 Ghz je přibližně 50 GFLOPS a propustnost paměti je přibližně 10 GiB/s. Cell procesor disponuje teoetickým výkonem 100 GFLOPS a propustnost všech subjáder k lokální paměti je cca 300 GiB/s. Teoretický výkon nejlepších grafických procesorů od AMD/ATI a nVidie se pohybuje kolem 1 TFLOP (započítaný je pouze výkon programovatelných unifikovaných shaderových jednotek, dalším výkonem disponují rasterizační jednotky) a propustnost paměti přesahuje 100 GiB/s. Jak je z těchto čísel vidět běžné procesory jsou v teoretických hodnotách hodně pozadu. Navíc rozšířit počet CPU v počítači je mnohem náročnější než do něho namontovat další kartu s GPU nebo akcelerátor s Cell procesorem. Jak ale využít tento obří potenciál? CUDA je řešením pro využití výkonu grafického čipu k něčemu užitečnějšímu než jen mordování emzáků. Oproti tomu OpenCL je řešením pro ty, kteří chtěji napsat aplikaci, která poběží na jednoprocesorovém počítači bez grafického akcelerátoru, nVidia Tesla počítači s čtyřmi G91 čipy, běžném několikajádrovém počítači s gr. akcelerátorem, počítači s budoucím Larrabee procesorem,... a na všech využije co nejvíce z jejich výpočetního potenciálu.

Jak to funguje

Programátor napíše výpočetní jádro, které se velmi podobá běžné funkci v C. Funkce může mít lokální proměnné, přístup ke globálním datům a datům společným pro všechny instance jádra, k dispozici jsou běžné matematické operace, goniometrické funkce, operace nad vektory... Jsou tam samozřejmě ale určitá omezení ohledně rekurze, větvení a cyklů. Výpočetní jádro se převede překladačem do mezijazyka, něco jako bytecode pro Javu. Takto vytvořené výpočetní jádro se následně poštve nad vektor, matici nebo trojrozměrnou matici. OpenCL ovladač zařízení se postará o celý zbytek- převede si výpočetní jádro do podoby, které bude rozumět dané zařízení (převede za běhu OpenCL „bytecode“ což je vzhledem k jednoduchosti jazyka a tomu, že výpočetní jádro je typicky velmi malé, velmi rychlé), nakrmí ho daty a provede výpočet.

OpenCL bohužel nezařídí rozložení práce mezi všechny zařízení v počítači. Umožňuje jen získat seznam všech zařízení, pro který je v systému OpenCL ovladač a získat jejich kontext. O rozložení práce se musí programátor postarat sám.

Bude z toho něco?

Je to otevřený standard, který řídí nezisková organizace Khronos. Firmy jako AMD, nVidia a Intel už se zapojily. První velká implementace je v Snow Leopardu a už existují demo prográmky, které demonstrují možnosti a také benchmarky.

The example run shown on the download page for OpenCL Benchmark shows the benchmark runs 12 times slower on a 3.2GHz Core 2 Duo compared to an NVIDIA GeForce 9600M GT.

9600M je mobilní grafický chip s 32 shadery. 285 GTX disponuje 240 shadery...

V případě Grand Central Dispatch jsem skepticky ale před OpenCL je myslím velká budoucnost v segmentu domácích počítačů, výpočetních stanic i mobilních zařízení (existuje i mobilní varianta OpenCL).

Doplněn benchmark OpenCL na mém počítači:

Number of OpenCL devices found: 2
OpenCL Device # 0 = GeForce 8800 GT
Device 0 is an: GPU with max. 1500 MHz and 112 units/cores
Now computing - please be patient....
time used:  0.751 seconds

OpenCL Device # 1 = Intel(R) Xeon(R) CPU           X5482  @ 3.20GHz
Device 1 is an: CPU with max. 3200 MHz and 8 units/cores
Now computing - please be patient....
time used:  2.895 seconds

       

Komentáře

[hikikomori82]

>> OpenCL má ambice stát se v tomto odvětvítím, čím je OpenGL pro 3D grafiku

To by som radsej do reklamneho plagatu na OpenCL nedaval ;)

[Vskutečnosti Saýc]

To zni, docela zajimave.

Jak je to s podporou v operacnich systemech? Kdybych chtel udelat aplikaci ktera tohle podporuje, kde mam zacit a jaka je sancce ze bude davat rozmny vykon na nejcastejsich platformach?

Jak moc velka jsou ta omezeni ohledne vetveni? Jak je to s paralelizaci? Je mozne pouzivat hardware kombinovane, tedy mit treba AI pocitacove hry na tomhle a pouzivat to na graficke karte zaroven s renderovanim grafiky?

Co dalsi dil s ukazkou kodu? :)

Diky za zajimavy zapisek!

[kubbing]

Funkcni imlementace OpenCL 1.0 je na 10.6 Snow Leopardu, ktery vysel pred tydnem. Ostatni systemy nevim, ale jelikoz jsem nezaznamenal nejake chlubeni od NVIDIE a nebo ATI ohledne novych driveru, tak asi ne... 

[kubbing]

Paralelizace je podle poctu vypocetnich jader, vypocetni fce se spousteji paralelne na GPU shaderech (na novych atinach jich je 800).

...........................................................
.................. OpenCL Bench V 0.25 by mitch ...........
...... C2D 3GHz = 12 sec vs Nvidia 9600GT = 0,93 sec ......
... time results are not comparable to older version! .....
...........................................................

Number of OpenCL devices found: 2
OpenCL Device # 0 = GeForce 9400
Device 0 is an: GPU with max. 1100 MHz and 16 units/cores
Now computing - please be patient....
time used:  3.673 seconds

OpenCL Device # 1 = Intel(R) Core(TM)2 Duo CPU     P7350  @ 2.00GHz
Device 1 is an: CPU with max. 2000 MHz and 2 units/cores
Now computing - please be patient....
time used: 18.818 seconds

Now checking if results are valid - please be patient....
:) Validate test passed - GPU results=CPU results :)

[alkoholik]

Nezaznamenal?
Ja zaznamenal.
..we would suspect around the August or September time-frame..

[kubbing]

 no mate pravdu ;)

[miho]

Všechny potřebné materiály jsou k dispozici na http://www.khronos.org/opencl/

 

[Mandarinka]

Dležitý je reálný výpočetní výkon... Zatím gpúčka uspěla jen v pár úlohách, které se mě na potvoru vůbec netýkají... tkaže na ty řeči o nebetyčných flopsech které nvidia/cell/xxx nabízí už beru tak nějak jako tlachy.

Zatím je situace tak nějak na způsob "když to cheš, napiš si to".

[M. Lox]

Přesně tak, uváděný výkon je vždy ideální a nelze ho považovat za směrodatný, pokud aplikace nepotřebuje počítat milion single-precision floatů. Cell je na tom trochu líp než grafiky, přeci jenom je jeho architektura podobnější normálnímu procesoru.

[kralyk z abclinuxu]

Nemůžete chtít po GPU aby počítal to, co CPU. GPU počítá věci, který lze paralelizovat a kde není potřeba moc programability. Pokud něco paralelizovat nelze, nemá smysl to na GPU zkoušet. Prostě GPU není od toho, aby nahradilo CPU. Takovým příkladem jsou např. hashe typu md5 nebo kompilace zdrojáků. Velmi dobře jde naopak paralelizovat decoding/encoding videa a jiné, v této oblasti je výkon (hlavně některých) GPU prdelnakopávající a strčí do kapsy veškerý Celly apod.

Mimochodem Cell není "podobnější" normálnímu procesoru, Cell je v podstatě normální procesor architektury Power, ale má navíc dalších 8 jader (tzv. SPE), které fungují jako takové lepší SIMD koprocesory a jsou určeny pro vecorized floating point počty, kterými se akcelerují média a grafika.

[M. Lox]

Nemůžete chtít po GPU aby počítal to, co CPU. GPU počítá věci, který lze paralelizovat a kde není potřeba moc programability. Pokud něco paralelizovat nelze, nemá smysl to na GPU zkoušet. Prostě GPU není od toho, aby nahradilo CPU. Takovým příkladem jsou např. hashe typu md5 nebo kompilace zdrojáků. Velmi dobře jde naopak paralelizovat decoding/encoding videa a jiné, v této oblasti je výkon (hlavně některých) GPU prdelnakopávající a strčí do kapsy veškerý Celly apod.

Já to vím, jenom poukazuji na to, že se stále častěji objevují hlasy – dokonce i na tomto serveru – že CPU jsou překonány a GPU / Stream jednotky ovládnou svět, což je blbost.

Mimochodem Cell není "podobnější" normálnímu procesoru, Cell je v podstatě normální procesor architektury Power, ale má navíc dalších 8 jader (tzv. SPE), které fungují jako takové lepší SIMD koprocesory a jsou určeny pro vecorized floating point počty, kterými se akcelerují média a grafika.

Ehm, já to mám doma. Cell prostě je podobnější normálnímu procesoru než grafiky, to nepopřeš, koneckonců, ačkoliv v první větě tvrdíš opak, hned v té další potvrzuješ můj pohled na věc.

[kralyk z abclinuxu]

Já to vím, jenom poukazuji na to, že se stále častěji objevují hlasy – dokonce i na tomto serveru – že CPU jsou překonány a GPU / Stream jednotky ovládnou svět, což je blbost.

Není to blbost. Ve chvíli, kdy bude GPU tak programmable jako CPU, bude CPU překonáno. Trend bude takový, že CPU a GPU se budou navzájem více a více prolínat - viz např. Larrabee a koneckonců i ten Cell.

Ehm, já to mám doma. Cell prostě je podobnější normálnímu procesoru než grafiky, to nepopřeš, koneckonců, ačkoliv v první větě tvrdíš opak, hned v té další potvrzuješ můj pohled na věc.

Já říkám, že Cell je normální procesor, tzn. víc než jen "podobný" normálnímu procesoru. A to architekturou, což se o GPU říct nedá.

[Daniel Kvasnička ml.]

Není to blbost. Ve chvíli, kdy bude GPU tak programmable jako CPU, bude CPU překonáno.

Jenze pak uz to v podstate bude zase CPU. Sila GPU je v tom, ze jsou delane pro urcity uzky okruh uloh a delaji se silou buldozeru.... kdyz to prolnes, mas v principu zase CPU...

Prolnuti je podle me spatny smer. Je dobre, ze jsou takove veci HW oddeleny.

[kralyk z abclinuxu]

Ale ty věci zůstanou odděleny. Akorát CPU bude stále vícejaderné. Dřív bylo jednojádrové, dnes už jsou více jádrové a počet jader bude narůstat.
U grafáren se zase bude stále zvyšovat programovatelnost stream unitů, takže se svojí charakteristikou budou ově věci přibližovat, což ale nez neznamená, že nebudou odděleny.

[M. Lox]

Já říkám, že Cell je normální procesor, tzn. víc než jen "podobný" normálnímu procesoru. A to architekturou, což se o GPU říct nedá.

PPE je normální procesorové jádro, SPE ne. Celek PPE + SPE tedy, logicky, normální procesor taky není.

[kralyk z abclinuxu]

Jasně že celek není normální procesor, ale celek obsahuje normální procesor, takže je logicky blbost říct, že je blíž normálnímu procesoru, když normální procesor obsahuje. Normálně na tom rozjedeš PPC linuxové distro...

[M. Lox]

… je logicky blbost říct, že je blíž normálnímu procesoru, když normální procesor obsahuje …

Neobsahuje normální procesor, obsahuje normální procesorové jádro. Jako když se zeptáš: Co má blíž k železnému plechu, LEGO nebo Merkur? Logicky Merkur, když je LEGO z plastu.

[M. Lox]

Ale přestaneme se hádat o slovíčka, když se v zásadě shodujeme.

[kralyk z abclinuxu]

Jj správně. Je škoda, že neexistuje něco jako Cell, ale pro x86, nebo existuje?

[M. Lox]

Můžeš si koupit akcelerátor do PCIe (s Cellem), ale jinak asi nic. Intel (prý) připravuje Larrabee, ale to zase bude spíš bližší grafické kartě.

[Mandarinka]

 

Velmi dobře jde naopak paralelizovat decoding/encoding videa a jiné, v této oblasti je výkon (hlavně některých) GPU prdelnakopávající a strčí do kapsy veškerý Celly apod.

Tak tady mi dovolte se ohradit. 1. Ukažte mi dekodér videa, který běží na shader procesorech gpu! Existovaly pokusy v rámci gsoc. Někomu se myslím podařil mpeg2, k nasazení nedošlo, h.264 skončilo nezdarem. VDPAU a spol. vždy používají specializovaný hardware. Slýchalo se, že r600 má vadné UVD a místo toho dekóduje softwarově přes shadery (neviděl jsem to nikde potvrzené).

 

A co se týče enkodérů, tak pro ty se gpu vůbec nehodí. Sice má spoustu jednotek, ale jsou příliš jednoduché, omezené a nebo blbě programovatelné. Důkazem budiž, že neexistuje jediný kvalitní gpu enkodér. Co víc, ty existující pokusy stejně používají ke svému běhu i spoustu cpu cyklů (ale dovolují si tvrdit že jsou proti SW typům úsporné!), takže v podstatě nenabízejí vůbec žádný benefit proti rychlým softwarovým enkodérům, jejichž kvalitě se navíc ani nedokážou přiblížit! Jo, zkrátka tragédie přikášlená spoustou keců a iluzí lidí, co někam dali oči.

[Mandarinka]

Ještě jsem opomněl dodat, že video formáty používají celá čísla, takže floating point výkon je jim k ničemu.

[trekker.dk]

VDPAU a spol. vždy používají specializovaný hardware.

GeForce 8800 a vyšší jsou specializovaný HW, nebo si VDPAU pletu s něčím jiným?

[miho]

AFAIK VDPAU je postavený nad CUDA a využívá normálně shadery, myslím, že mandarinka kecá

 

[Mandarinka]

Ne, CUDA poskytuje rozhrani k programovani toho specializovanyho HW. Tak funguje coreavc. VDPAU afaik neni primo psany pres CUDA, stejne jako dxva (naprikald implementace v mpc).

Kdyby to bezelo pres shadery, zralo by to stejne elektriky jako 3d hra. Nemluve o tom, ze treba cabac by se asi programoval dost blbe.

[Grunt]

To tedy asi moc daleko nevíš.

[Mandarinka]

Vysvětlete mi tedy například, proč schopnosti odpovídají schopnostem toho hardwarového dekodéru (doufám že nepopíráte, že ho Radeony a Geforcky mají), proč mají některé geforce hardwarovou chybu, která znemožňuje dekódovat h.264 s určitou šířkou (jedná se napřílad o videa s šířkou 1024 pixelů download.nvidia.com/XFree86/Linux-x86_64/185.18.14/README/appendix-h.html#id333549), a nakonec samozřejmě, proč se podpora omezuje na modely s tímto HW dekodérem. Příklad: G80 ne, G92 ano.

[Grunt]

Vysvětlete mi tedy…

Já?

[Mandarinka]

No jo, už to vidím... sorry.

[Mandarinka]

GF8800 (a dalsi gpu) ma v sobe blok zvany tusim neco jako purevideo decoder. IIRC to ma jednoduch arm nebo mips jadro kterymu asistuje dsp nebo neco tak.

[Grunt]

GeForce 8800 a vyšší jsou specializovaný HW, nebo si VDPAU pletu s něčím jiným?

IMHO to spíš mělo být specializovaný obvod nebo specializovaný HW blok. Jinak tento obvod mají už i karty řady GeForce6 (akorát první generace), jen se k tomu nechce nikomu programovat rozhraní.

[kralyk z abclinuxu]

Hm taková implementace zatím není právě kvůli exitenci různých UVD a Nvidia ekvivalentu (nevim jak se menuje)...
Ale když to někdo napíše, neměl by být problém. Stačí si přečíst specifikace assembleru třeba u AmdStream nebo u CUDA, umí spoustu věcí i s integerama.

[Grunt]

1. Ukažte mi dekodér videa, který běží na shader procesorech gpu!

Dirac. A to jak skrze CUDU, tak skrze libglew. A je to tak na prd, že to skončilo v propadlišti dějin.

[Zdenek]

Prostě GPU není od toho, aby nahradilo CPU. Takovým příkladem jsou např. hashe typu md5 nebo kompilace zdrojáků.

To neni pravda, zrovna v pocitani MD5 hashi nemaji GPU konkurenci

[Zdenek]

Teda v oblasti bezneho HW, nepocitam FPGA

[kralyk z abclinuxu]

To není tak jednoduché. Na GPU můžeš paralelizovat jednotlivé hashe, tedy počítáš mnoho hashů. Na GPU ale není možno spočítat jednotlivé kroky hashe, protože ty jsou prostě z definice sériové.
Chceš-li spočítat hash od 4GB souboru, bude CPU o dost rychlejší jak GPU. Chceš-li spočítat mnoho hashů z krátkých dat (jeden max dva cykly hash řetězce - tedy ne víc jak nějakých 56+64 bajtů) bude GPU rychlejší.

[Grunt]

Takovým příkladem jsou např. hashe typu md5 nebo kompilace zdrojáků. Velmi dobře jde naopak paralelizovat decoding/encoding videa a jiné, v této oblasti je výkon (hlavně některých) GPU prdelnakopávající a strčí do kapsy veškerý Celly apod.

No vzhledem k tomu, že to psal mr. Mandarinka, tak to IMHO bude přesně naopak.

[Mandarinka]

Cože cože? O hashování vím kulový, nedovolil bych si do toho kecat.

[Grunt]

Vždyť já také nemyslel zrovna to hashování.

[Mandarinka]

No když popátráte, tak ta část o enkodérech a dekodérech určitě obstojí :D

[Ivan]

Klasicky MD5 by na GPU slo tezko implementovat - je to z principu sekvencni zpracovani dat. GPU architektura je dost specificka. Nemate k dispozici podminky a pred kazdym krokem vypoctu musite specifikovat ktere casti pameti budou POUZE pro cteni a co bude POUZE pro zapis. Jednotlive shadery se nemouhou nijak ovlivnovat. Na nasobeni matic je to idealni ale jakakoliv rozhodovaci logika se na GPU implemetuje dost tezko.

[kralyk z abclinuxu]

Ale prosimtě nepovídej. Já jsem sám na GPU md5 implementoval přes AmdStream SDK a fungovalo to krásně. Jestli chceš vidět zdroják, můžu napsat.
Nebo si hoď do googlu 'Barswf', ten to implementuje jak pro CUDA tak pro AmdStream, rozumbrado

[Ivan]

Pockej az nekdo implementuje "quadratic sieve" na GPU. Mozna zmenis nazor.

 

[miho]

Doplnil jsem benchmark mého počítače. 8 jáder Core2 na 3,2 GHz je v tomto benchmarku ±4x pomalejší než stařičká 8800GT.

[miho]

Ještě bych k tomu doplnil údaje pro odhad poměru cena výkon: procesory v mém počítači stojí ±80 000,- s DPH a grafika výkonově ekvivalentní s 8800GT se dá pořídit za ±2500,-.

 

[Non_E]

Zkompiluju si s tím rychleji openoffice?

[Vskutečnosti Saýc]

Ted asi ne. Na druhou stranu, naportovani prekladacu na neco takoveho je zajimavy napad.

[miho]

Nejsem si jist zda zrovna překladač je vhoudnou úlohou pro OpenCL

[Limoto]

Ale já jsem si jistej, že teprve potom by to OpenCL nabralo smysl

[xsubway]

mně by pro začátek stačilo, kdyby OpenCl bylo možné využít k práci s video soubory ... zrychlení o jeden řád při stříhání/renderování například AVCHD záznamů by bylo, no úžasné :D

[miho]

Dekódovat se dá pomocí VDPAU, nějaké testy jsem dělal. OpenCL je myslím právě tím pravým ořechovým stimulem, který by mohl někoho přinutit hnout líným zadkem a napsat i kodér případně renderovátko nějakých těch efektů pro interaktivní práci při střihu. Někde jsem viděl sliby, že udělají update pro nový Final Cut, který OpenCL využije tak uvidíme...

 

 

[Grunt]

Grafické karty disponují obrovským výkonem, který zbytečně zahálí pokud není spuštěná nějaká náročná 3D aplikace (čti: hra). Proč ten výkon nějak nevyužít?

Je zde patrný drastický pokles potřebného výkonu procesoru jak pro dekódování, tak pro zobrazování. Grafická karta se během přehrávání evidentně stále nudí, protože její teplota nestoupla po hodině ani o stupeň.

Toto byl samozřejmě extrémní případ, 16 GiB BlueRay H.264 ripy se vyskytují málokdy. Při přehrávání běžného H.264 720p videa klesne vytížení z 20/7/2 (mplayer, compiz, X) na 3/1/3, H.264 1080p s 9Mbit/s bitratem 35/20/8 -> 8/1/2. Kvalitní DVD MPEG-4 ripy 7/1/1 -> 2/1/1.

Kdyby se to dalo využit pro KOMPRESI videa- to by byla teprve užitečná věc

To je myšleno nějak vážně?

[Grunt]

mně by pro začátek stačilo, kdyby OpenCl bylo možné využít k práci s video soubory

No tak zrovna pro práci s videem je GPU pěkně na h*vn*. Teda alespoň se současnou architekturou.

zrychlení o jeden řád při stříhání/renderování například AVCHD záznamů by bylo, no úžasné :D

To jsou bohužel jen sliby.

[kralyk z abclinuxu]

No tak zrovna pro práci s videem je GPU pěkně na h*vn*. Teda alespoň se současnou architekturou.

A to proč?

[Mandarinka]

Fitlrování se dá. Věci jako odšumění, zvětšování/zmenšování, odstranění prokládání. TO jsou takové poměrně jednoduché operace pořád dokola na velkém množství dat.

Enkodér potřebuje hodně rozhodovat, pro dobrou kvalitu je třbe provádět tzv. RDO, rate-distortion optimizations. To znamená, že zkrátka zkoumáte, kolik které rozhodnutí stojí bitů a jak velký má dopad, a sanžíte se maximalizovat zisk kvality na jeden bit. Motion search na druhous tranu by se na gpu dělat dal, byl to projekt gsoc pro x264, leč nikdo neměl zájem. Obecně lze říct, že na slušný enkodér, jako je x264 je celkově gpu příliš stupidní, a zároveň stále ještě hůře programovatelné. Když se podíváte na výkon x264 na nejlevnějším core i7, tak myslím je vidět, že x86 je pro tyto úlohy velice schopné.

[kralyk z abclinuxu]

Hm, ok díky za info. No celkově by to asi chtělo vhodně rozložit úkoly mezi CPU a GPU. Což chce fikanou, promakanou implementaci s nějakým chytrým schedulerem atd. no a je otázka, jestli by se to celý výkonově vyplatilo.

[Grunt]

Pomiňme vhodnost či nevhodnost GPU k operacím které se u video-processingu používají. Stejně o nich vím prd. Vezněme si třeba jen prosté dekódovaní HD videa skrze GPU. Zatím s tím moc zkušeností nemám, ale pokaždé když jsem to použil, tak jsem byl dost znechucen. Video sotva jelo, jedno jádro procesoru na 100%(v kernel-spacu) a GPU se mohlo teplotou roztavit. A proč zrovna sotva jelo? Řekněme že dekódujeme video o datovém toku 40Mbps. Takže to máme 40Mbps směrem do grafiky. Pak je potřeba z grafické paměti odebírat dekódované video. 1920*1080*12*60=1423Mbps. Takže to máme zatím 1463Mbps. No a pak je zase potřeba cpát to video zpět přes Xv do grafického škálovače, který už snad provádí konečné vykreslení. To máme téměř 3Gbps jen na sběrnici a obrovské množství dat pořád lítá sem a tam. A jak by asi vypadalo takové SuperHD. Netuším zda-li jde už v grafice přesměrovat dekódované video přímo do HW škálovače nebo aspoň do paměti přímo na grafice, ale vím, že to určitě nejde bez toho aniž by se překopala současná architektura zobrazování videa(což se třeba děje u VDPAU). A IMHO to trávilo 100% času v jádře z toho důvodu, že se na něco čekalo. Což je důkazem toho, že takovýto návrh není 100% odolný proti idiotskému implementování. A znáte to. Pokud něco pokazit jde, …

[kralyk z abclinuxu]

No pokud vím, tak PCI-E 16x podporuje 5 GiB/s tam i zpátky (tedy 5*8 Gbps tam i zpátky) takže v tom problém nebude. Problémy budou spíš jednak se špatnou implementací (GPU a CPU moc komunikují) a zadruhý s problémy, který popsal Mandarinka. To se týká encodingu.

Co se týče decodingu, tam by problém vůbec být neměl stačí to správně implementovat. A obraz by měl jít posílat přímo, ne oklikou přes RAM, páč software okolo UVD to tak imho dělá. Jenže tohle imho nikdo implementovat nebude, protože je lepší použít UVD.

[Grunt]

No pokud vím, tak PCI-E 16x podporuje 5 GiB/s tam i zpátky (tedy 5*8 Gbps tam i zpátky) takže v tom problém nebude.

Ale to se asi netýká té mojí plečky.

GPU a CPU moc komunikují

Je otázka zda to jde vždy bez nich. A zda-li to může efektivně využívat DMA, protože takové toky procesorem nebo čímkoliv jiným jsou docela spolehlivý zabiják.(Ale to se týká i jejich kopírování obecně) Ještě si pamatuju, že 100% v jádře se týkalo i některých příkladů z CUDy. Schválně přebootuju a zkusím to.

tam by problém vůbec být neměl stačí to správně implementovat.

Tam už opravdu k tomu abych se smíchy potrhal stačí slovíčko jen.

[Grunt]

Příloha:

• CUDA.png (0 bytů)

Schválně přebootuju a zkusím to.

A přitom obraz stojí a asi jen jede nějaká smyčka na GPU. A vzhledem k tomu, že jsou to oficiální příklady z SDK, předpokládám, že to nebude jen nějaká chyba implementace(u jiných tomu totiž není jinak).

[kralyk z abclinuxu]

Čoveče to ti asi neporadim, páč mám ATInu, takže CUDA fakt nerozjedu...
Bůhví čím to je, v každým případě ta technologie je ještě více/méně v plenkách takže to asi nějaký ty mouchy mít bude. Že to jsou officiální samples z SDK ještě nic neznamená, i v SDK může být chyba

[Grunt]

Jo a ještě jsem zapomněl. Když se rozvalí naplno všechny ty shadery, tak IMHO si to určitě nebude brát(a také vyzařovat) pár watíků, jako je tomu u specializovaného HW.

[kralyk z abclinuxu]

No to nebude ale dekódování videa ti nerozvalí naplno všecky šejdry. Teda nevím co máš za grafárnu, ale u mojí hd4870 teda určitě ani náhodou.
Ale určitě se shodnem na tom, že nemá smysl inplementovat dekódování videa přes gpgpu simd cores, když každá novější karta má na to specializovaný čip - něco jako UVD nebo PureVideo (či jak se menuje ta vecička u nvidie), který navíc zvládne úkol lépe/úsporněji.

Nejsem si úplně jistej, jak ten UVD funguje, ale když spustím decoding HD videa přes DXVA (mpc-hc), karta se zaktivuje (tzn. jádro se hodí z klidových 500MHz na pracovních 750MHz) a vykazuje zátěž 1%~2% (naměřeno oficiální utilitou i GPU-Z), tak nevím, co z toho usuzovat. Ale asi jen šibuje datama semo tamo.

[Mandarinka]

Taky jsem slyšel že to zvedne frekvenci i když je 3d část v klidu. Problém asi bude, že UVD si nemůže zvednout frekvenci jen pro sebe samostné a musí probudit celé gpu. IIRC shadery se na Radeonech použijí pro volitelný post-processing (což je imho lepší povypínat), ale jestli se to tak v praxi fakt děje, o tom nemám šajna.

Jinak SW dekodéry mám radši (a prakticky jakékoliv dvoujádro by mělo stačit) , protože u těch se vám nestane že vám odmítnout prcovat když má třeba video jeden referenční snímek navíc, nebo hierarchické bframes. Zkrátka vám hrozí že gpu jednou něco nepřehraje... no, moc velký problém to není, komerční videa by měla fungovat vždy.

[kralyk z abclinuxu]

Imho kompilace moc paralelizovat nejde, ne?

[M. Lox]

make -j 5000

[kralyk z abclinuxu]

No kompilace bude zachviličku, ale pak se stejně budou ještě buhvíjak dlouho dohledávat dependence...
Ledaže by existoval nějakej pool nebo něco v paměti, kde by byly unresolved dependence a 5000 threadů-dělníků by na tom makalo, asi jako když 5000 dělníků skládá velkou mozaiku
No ale nevim nevim pomohli-li bychom si tím...

[kralyk z abclinuxu]

Dík za pěkný zápisek. Je fajn vidět, že se to v OpenCL aspoň trochu hejbe. Dělal jsem nějaký ty pokusy v AmdStream, ale není to úplně ono... to OpenCL by bylo mnohem lepší...

Btw. jestli to dobře chápu, ten test je jen pro MacOS že? Nebyl by nějaký pro linux nebo windoze?

[Dusan]

Člen menom Zack Rusin to začal implementovať do Gallia ?

viď http://cgit.freedesktop.org/mesa/clover/log/

Tiež by sa my páčila podpora v ffmpeg (dekodovanie, enkodovanie) namiesto vdpau.

[Daniel Kvasnička ml.]

No Apple prisel o AltiVec, tak to musel necim nahradit. A nutno rici, ze tohle je flexibilnejsi reseni...

[Tomas]

Vedel by som si predstavit OpenCLWpaCracker alebo OpenCLJohn ci OpenCLNmap. Uvidime.

[loketnik]

To je slovo do pranice Konecne poradne v praxi vyuzitelne napady

[Grunt]

A někdo v tom brání?