Zobrazit předchozí téma :: Zobrazit následující téma |
Autor |
Zpráva |
Marek

Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 24. září 2008, 05:51:01 Předmět: Interaktivní raytracing s CUDA + Realtime Ambient Occlusion |
|
|
Na stránkách nVidia jsou zajímavé slajdy o raytracingu pomocí CUDA:
NVISION08: Interactive Ray Tracing with CUDA
Nejprve vyvrací některé mýty o raytracingu a poté nastíní použité techniky a implementaci. (a co na to Vilem? )
Ambient Occlusion, jedna z populárních technik obvykle řešená pomocí raytracingu, se nyní dá řešit pomocí rasterizace a dokonce v realtime jako post-processing efekt:
Siggraph 2008: Image-Space Horizon-Based Ambient Occlusion + video
Zdroj: developer.nvidia.com _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
 |
VladR
Založen: 30. 07. 2007 Příspěvky: 1322 Bydliště: Greater New York City Area
|
Zaslal: 24. září 2008, 15:11:48 Předmět: |
|
|
Doteraz som bral koniec rasterizacie iba ako klasicke hlasky typu armageddon, ale asi na tom nieco bude. Fakt by ma zaujimalo, aka bude situacia o 5-10 rokov  |
|
Návrat nahoru |
|
 |
Marek

Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 25. září 2008, 02:12:27 Předmět: |
|
|
Asi stejná:
- 3D API budou furt nabízet rasterizaci a 10 druhů shaderů (to se dožene, DX11 má zatím 6 - vertex, hull, domain, geometry, pixel, compute).
- API pro obecné výpočty (CUDA/CL/CTM) dají možnost implementaci raytracingu nebo voxel-based renderingu, případně speciálně optimalizovanýho renderingu na míru enginu.
- EDIT: Hodně lidí si stejně licencuje cizí engine, takže těm je to jedno.
Toť můj názor. _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
 |
Vilem Otte

Založen: 18. 09. 2007 Příspěvky: 462 Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
Zaslal: 9. říjen 2008, 01:11:55 Předmět: |
|
|
Tak já se konečně zase ozývám - nějak jsem sem tady na fórum chvilku nezavítal. Ale k věci...
Jde vidět že NVidia se čím dál tím více soustředí na rasterizaci scény a následného ray tracingu na dosažení pokročilých efektů (podobně jako jsem prováděl já v Genesis demu s reflekcí u vody). Ovšem já jsem v té chvíli tahal data z GPU zpět do paměti a prováděl ray tracing na CPU (to samozřejmě zdržovalo), NVidia to udělala pomocí GPU - není to špatný nápad, ale také má své mouchy.
Největší problém v řešení hybridní metodou vykreslení jsem objevil právě u "primárního renderingu" = rasterizace. Při ray tracingu není problém vyřešit korektně subsurface scattering, pokročilý stínovací model, či jiné podobné efekty. Ano, můžu znova vytvořit další polopřímky po primárním renderingu na zpracování tohoto, ovšem toto si vyžádá více výkonu (a to docela dost, protože budu znova tvořit polopřímky z kamery) než kdybych provedl ray tracing na celé scéně.
Další věc, kterou NVidia zmínila a co mě docela překvapilo je to, že nepřímé osvětlení se nerovná ray tracingu - ovšem jediný způsob jak ho relativně přesně (úplně přesně ho dosáhnout nejde) dosáhnout je použít ray tracing (přece jenom SSAO, SSGI, deferred rendered radiosity ani light probes nejsou vůbec přesné, jenom přidají trochu nesprávného nepřímého světla do scény - ta ovšem poté vypadá mnohem lépe než i bez tohoto).
Bohužel (nebo bohudík ... záleží jak se to vezme) co se týká výkonu - tak má NVidia pravdu, že z GPU se dá vymáčknout momentálně mnohem více než z dvoujáder/čtyřjáder od intelu nebo amd. Jedinou možností jak se alespoň přiblížit výkonu GPU je použít SIMD jednotky (asi největší výhoda CPU oproti GPU s MIMD architekturou (která se ani zdaleka tolik nehodí na ray tracing) - tedy co se týká ray tracingu) a dát dohromady více procesorů - pak dokonce lze i výkon GPU lehce překonat.
Mno, každopádně celou situaci kolem NVidie a jejím náhlém zájmu o ray tracing hodlám sledovat v co se to bude vyvíjet. _________________ Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
Návrat nahoru |
|
 |
Marek

Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 13. říjen 2008, 22:22:32 Předmět: |
|
|
Vilem Otte napsal: |
oproti GPU s MIMD architekturou |
MIMD? Spíš SIMT ne? Aspoň podle CUDA programming guide. (single instruction multiple threads - z toho jde vidět, proč dynamic branching byl vždycky problém) Jako nikdo neříká, že se musí celý raytracing provádět na GPU, klidně si část výpočtů udělej jinde. Důležitý je využít GPU tam, kde to něco přidá.
Teď něco trochu mimo, možná jste to už někde četli, protože to teď dost koluje po netu - GPU se zkoušelo využít pro nabourávání do WiFi sítí brutální silou a oproti CPU je asi 10000x rychlejší. Někdo se vyjádřil, že se na stávající zabezpečení WiFi už nedá spoléhat. (zdroj1, zdroj2) _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
 |
Fila
Založen: 31. 07. 2007 Příspěvky: 853
|
Zaslal: 14. říjen 2008, 09:32:13 Předmět: |
|
|
Eosie napsal: |
MIMD? Spíš SIMT ne? |
Pravdu mate v podstate oba. GPU je programovatelna jako MIMD (kazdy thread opravdu muze delat neco jineho), ale fyzicky provadi instrukce SIMT -- tedy pokud diverguje beh v jednom warpu, tak se beh serializuje.
Znamena to, ze pro psani vykonnych aplikaci musime uvazovat SIMT architekturu, ale muzeme psat MIMD programy, ktere se chovaji "co mozna nejvic SIMT" .
Eosie napsal: |
GPU se zkoušelo využít pro nabourávání do WiFi sítí brutální silou a oproti CPU je asi 10000x rychlejší |
Uff, ted jsi na chvili naboural me predstavy o fungovani vesmiru . GPU je zde o 10 000 % rychlejsi, tedy 100x. |
|
Návrat nahoru |
|
 |
Marek

Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 14. říjen 2008, 12:53:04 Předmět: |
|
|
Ah, jsem to opsal bez přemýšlení, to číslo nebylo z mojí hlavy, jsem si říkal, že to nějak nesedí. Jinak je to z linku "zdroj1", kde se v diskuzi řeší stejná chyba (bylo tam předtím "by factor of 10000"). _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
 |
|