Direct Compute - thread / thread group

[perry]

Čau,

jak je to s direct compute a vlákny.

a) vytvořím 1 thread group a v něm 512 vláken
[numthreads(512, 1, 1)] a Dispatch(1, 1, 1)

b) vytvořím 512 thread groupů s 1 vláknem
[numthreads(1, 1, 1)] a Dispatch(512, 1, 1)

=> ve výsledku poběží paralelně stejně vláken (za předpokladu, že GPU zvládne 512 vláken najednou) nebo v možnosti a/b více ?

Co jsem to měřil, tak mi to vychází časově stejné.... ale stejný čas dostanu i pro 128 (místo 512)... mám tam zápis a čtení z globální paměti a to je silná brzda.

Pro zájemce plný kód (dekomprese LZSS):
http://pastebin.com/HZbNfqTL
_________________
Perry.cz

[pcmaster]

Vseobecne to nepobezi rovnako -- HW totiz spusta tie vlakna vzdy v nejakych minimalnych skupinach (snad 16/32 vlaken?). A to ti numthreads(1,1,1) nesplna - plytvas vlaknami, pretoze z celej HW skupiny vlaken bude bezat len jedno jedine a ostatnych 15 (?) sa bude flakat. Vtedy prides o strasnu cast vykonu a myslim si, ze to bude az take zle, ako keby sa vsetok dynamicky branching v tej skupine vydal totalne inym smerom pre kazde vlakno.

Pri 512x1x1 (alebo i 31x16x1 a podobne) si nemozes byt uplne isty, ze ti to kompilator ukompiluje - nemusi mat dostatok registrov a tiez tlak na groupshared pamat je velikansky (zavisi od algoritmu).

Rule of thumb: mat co najvacsie skupiny, a to idealne este tak, aby pre kazde vlakno dopadli vsetky podmienky zhodne a co najlepsie vyuzivat kurevsky rychlu zdielanu pamat (ak ju nepotrebujes na komunikaciu, kludne ju rucne pouzi ako "cache" a usetri kompilatoru nejake registre).

Predpokladam, ze mas nejaky jednoduchy priklad typu "vector add". 512 (0.5 x 10^2) vlaken dohromady je fakt hovno, musime sa bavit v radoch 10^6-10^8, potom uvidis rozdiel. S Dispatch(1,1,1) ani s Dispatch(512,1,1) nemozes fakt nic namerat, overheady zozeru vacsinu casu

EDIT: Ja sa musim priznat, ze som si nevsimol link na ten kod, preto som ho ani neskumal a odpovedal vseobecne...
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[perry]

Blbý je že ta dekomprese je seriovy kod A když udělam moc vláken, tak zase budu mít datově hrozně malý bloky, takže se to nevyplatí. Nicméně pořád je to rychlejší nahrát na GPU komprimované a pak si to tam rozbalit (klidně pomalu), než to rozbalit na CPU a pak to nahrávat na GPU...

Kompilace to ukompiluje... Registry nedojdou, to si pohlídá kompilér (už jsem viděl hlášku (Warning), když dojdou a začne se používat global memory). Podobně to má i CUDA kompiler.

Používám to v tom přiloženém algoritmu, na LZSS dekompresi. Problém toho, vydat se pro každé vlákno ve skupině jiným směrem jen ten, že potřebuju ty dva slovníky. Teď je mám ve sdílené paměti, takže OK.. každý group má svůj. Když hodím do jedné skupiny více vláken, tak jsem v háji se slovníkem. Můžu udělat jediné 4 vlákna na skupinu... 4 slovníky jsem schopný zapakovat do jednoho pomocí bitových operací pro přístup do virtuálního pole uint8 uloženého jako uint32 (nic jiného to neumí)

Pak nahradím ty POSITION_GET/SET makra tímhle:

[Crypton]

Dumb Question: Wow, LZSS dekomprese na GPU... to ti jedno vyhrazené jádro CPU nestačí? A ten kompresní poměr... proč raději nepoužít deflate (zlib)?
_________________

[perry]

Protože mi vyjde rychlejší nahrát to na GPU zabalené a tam to rozbalit, než to rozbalit na CPU a pak to hrnout na GPU. Navíc LZSS není tak špatný v porovnání s časem dekomprese (záleží samozřejmě na povaze dat)

Např: soubor 8.4 MB
LZ77 - 7.5 MB
LZSS - 6,2 MB (slovník 256 byte, look ahead buffer 64 byte)
Zip - 4,1 MB
Huffman - 7,2 MB
JPEG2000 (bezztrátový) - 6,5 MB

soubor2 16,7MB
LZ77 - 6.4 MB
LZSS - 4,9 MB (slovník 256 byte, look ahead buffer 64 byte)
LZSS - 4,8MB (slovník 2048 byte, look ahead buffer 256 byte)
Zip - 3,2 MB

Soubor2 - čas dekomprese LZSS na GPU
1 thread group / 1 vlákno - 5400 ms
128 - 512 thread group / 1 vlákno - 88 - 85 ms

Čas měřím:
http://pastebin.com/kTbPz1Lk - (pokud tam někdo vidí něco blbě, můžete se ozvat )

Navíc zip na GPU nerozbalim nijak efektivně, LZSS relativně jo (viz přiložený kód)
Jako není to žádný super zázrak

Možná kdybych to psal v CUDě, že to pojede rychleji... ta je na tohle více stavěná, než shadery. Ale zase co jsem měřil, tak pokud v direct compute renderuju do textury, tak je CUDA horší.

Jinak jsem zkoušel udělat více vláken v rámci skupiny a snížit počet skupin... bohužel, výsledek byl horší, než možnost b) v prvním příspěvku. Z toho jak se to chová, mi přijde, že mu je jedno, jestli udělám a) nebo b). Naopak, pokud udělám kombinaci, tak to zabije to makro pro zápis do pole (resp. zabije to podobným způsobem, jako když pustím b) s tímhle makrem místo toho, co je v ukázce kódu... jestli je to k pochopení )
_________________
Perry.cz

[Crypton]

Aha, já myslel že to máš v úmyslu použít ve smyslu "generic purpose", myšleno pro jakékoliv data, ale pokud to je jen na textůry, meshe, apod, tak to chápu.

Tak dík za objasnění.
_________________

[perry]

Na obecná data by to bylo dost k ničemu.. přenos na GPU a zpátky.. za tu dobu to rozbalim na CPU
_________________
Perry.cz