.[ ČeskéHry.cz ].
Optimalizace částicových systémů
Jdi na stránku 1, 2  Další
 
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Magazín
Zobrazit předchozí téma :: Zobrazit následující téma  
Autor Zpráva
Vilem Otte



Založen: 18. 09. 2007
Příspěvky: 462
Bydliště: Znojmo - Sedlesovice, Kravi Hora

PříspěvekZaslal: 2. květen 2011, 22:27:39    Předmět: Optimalizace částicových systémů Odpovědět s citátem

Optimalizace částicových systémů

Jelikož jsem se v poslední době setkal s pár problémy s integrací částicových systémů do více rendererů, tak bych zde napsal pár poznatků a řešení se kterými jsem se setkal (považujte to za takový uncontrolled brain dump pro částice, vzniklo to na základě nějakých rozhovorů s dalšími vývojáři a jedná se o více-méně ucelený kousek nějakých našich zamyšlení nad optimalizacemi particle systémů, mimochodem všechny tyto optimalizace uvádíme v praxi, takže víceméně fungují - záleží samozřejmě na situaci).

Integrace částicových systémů je stejná co se týče jak projekčních rendererů (rasterizačních), tak fyzikálně založených (ray tracerů). Na rasterizačních rendererech však neuvidíme takový vliv na výkon jako u ray tracerů, jelikož jsou pro částicové systémy lépe navrženy.

Problémy jsou, jak jsem zmínil takřka stejné ? a pokusím se na pár z nich poukázat a také na to, jak je vyřešit.

Problém fillrate

Největším problémem částic je jejich samotné vykreslení, zde může částicový systém velmi mnoho získat, a taky velmi mnoho ztratit. Nejvíce záleží na jediné věci, kolikrát budeme muset každý pixel překreslovat, než budeme znát výslednou barvu daného pixelu.
Nejhorší jsou v tomto případě částice additivní, které nám docela zatopí, podívejme se na jednoduchý oheň jako tento:


Oheň vypočtený pomocí realtime raytracingu a aditivního blendingu

Pokud bychom vykreslili tyto částice natvrdo v módu additivního blendingu (samozřejmě back-to-front aby bylo vše zobrazeno správně), či prováděli additivní ray tracing (po nárazu na částici vytvoříme v bodu nárazu novou polopřímku kterou dále sledujeme a přičítáme k původní hodnotě) budeme mít velmi vysoký fillrate (což je spousta překreslování a to není dobře - výsledek může být velmi pomalý), ukázka fillrate překreslování:


Fillrate ? čím světlejší tím vyšší

Zadefinováním maximální hodnoty (počet sčítání např. 16) lze fillrate trochu snížit, to lze účinně aplikovat u rasterizérů (přes texkill/alpha test ? kde je zisk relativně vysoký, to však nelze použít u additivního blendingu, ale pouze u alfa blendingu), u raytracerů se zisk zdá o něco vyšší (tam se dá terminovat výsledek i u aditivního blendingu, čímž získáme více).


Fillrate ? definování maximální hodnoty součtů

Co však nám s fillrate nejvíce pomůže je technika tzv. Particle trimmingu. Místo čtverce vybereme mnohem vhodnější tvar pro částici, můžeme zůstat také u čtyřúhelníků, často je však mnohem vhodnější co se výkonu týče použít i více vertexů (třeba 7-úhelník). Vertex processing je totiž mnohem méně náročný než násobné překreslování jednoho pixelu.


Particle trimming ? zelená reprezentuje geometrii částice

Particle trimmingem získáme snad nejvíce výkonu, dále můžeme výkon fillrate zvýšit zakomponováním více částic do jedné.

Problém bandwidth pro tok dat

Tok dat je hned druhým problémem, který často může přesáhnout i problém fillrate. Představte si, že vygeneruje velký částicový systém na CPU, který má dejme tomu 1 milion částic, každá částice obsahuje svou pozici, rychlost, zrychlení, život, barvu, geometrii, etc. - dejme tomu 64 byte na částici, celkově 64 MB, které musíme každý snímek updatovat a poslat na GPU (při 30fps to bude 1.92 GB/s), kde vše zpracujeme a vykreslíme.

Pokud však budeme generovat geometrii za běhu v geometry shaderu, můžeme náročnost o něco snížit circa na 1/3. Můžeme však počítat celý částicový systém na GPU (což je výhodné, pokud se nám vejde do VRAM spolu se zbytkem scény ? ušetříme tok mezi CPU a GPU, a také výpočetní výkon CPU pro další možnosti).

Pro ray tracing má generování geometrie za běhu také svůj význam, svým způsobem tím ale neušetříme ani zdaleka tolik co v případě systémů na GPU. Je totiž potřeba updatovat hierarchii scény ? a update nezvládneme v cache, pokud tam budeme držet data geometrie částic (je třeba často číst z paměti, a bohužel v tomto případě nás velmi pravděpodobně bude limitovat northbridge a rychlost paměti).

Limitace northbridgem také platí pro updatování částicových systémů na CPU, budou zpravidla pomalejší, než je celé odložit na GPU. Výpočet sice můžeme paralelizovat na více jader, případně i použít SoA místo AoS (pomocí SIMD ? ať už SSE či AVX) ? nicméně průtok northbridgem a rychlost paměti nám stačit nebude a bude vše pomalejší než když použijeme GPU.

Problém state-changes

State changes jsou jak problém pro rasterizéry, tak pro raytracery. Jedná se o toto, pokud použijeme 200 různých shaderů a 1000 různých textur a na každou skupinku pixelů jiný shader a jinou texturu, bude nás to velice zpomalovat, pro ray tracery (a především path tracery) to platí dvojnásob.
Jak na toto vyzrát? Velmi jednoduše, snížit počet shaderů ? případně použít jeden ubershader. Je důležité dodat, že pro každý projekt se hodí jiný model shaderů (někde více malých, jinde skutečně jediný ubershader) ? záleží na náročnosti shaderů, počtu použitých shaderů ?ve výhledu?, apod. Nemůžeme zde jednoznačně říct, že existuje pouze jediná cesta.

Pro textury je dobré použít texturové atlasy, místo 16 různých 256x256 textur použijeme 1 texturu 1024x1024. Výsledek bude prakticky téměř stejný (až tedy na nejvyšší Mip/Rip levely ? ty však v praxi nevidíme, či vidíme pouze na velmi malé skupince pixelů, takže výsledek bude takřka totožný), ale pokud objekty vykreslíme v dobrém pořadí (ty ve stejném texturovém atlase nejednou), ušetříme spoustu state-changes.

Problém okamžiku kreslení částic

Problém nastává, kdy tedy kreslit částice? U raytracerů je odpověď jasná, vložit je do scény před updatováním hierarchie a renderer si s tím poradí (snad dostatečně rychle). U rasterizérů je však problém s velmi komplikovanou renderovací pipeline.

Pro forward rendering by bylo nejlepší je renderovat front-to-back (spolu s ostatními modely), to však možné není, je třeba je renderovat až po všech modelech (aby se správně provedl blending) a v pořadí back-to-front, což je nejnáročnější možný způsob (přepisuje Z-buffer, nedovoluje early-Z-out).

Pro deferred rendering je dobré používat separovaný pass pro částice a renderovat je až po vygenerování G-bufferu, a po výpočtu osvětlení je do bufferu zamíchat, tím si však vyloučíme efekty spojené s deferred renderingem (spousty světel, apod.). Druhá možnost je při renderování MSAA G-Bufferu je zamíchat do něj stipplingem, kvalita nebude tak vysoká, ale je zde možnost využívat deferred shading na nich. Jiná možnost je použít násobný depth-peeling G-bufferů, což je spíše vhodné pro offline renderery.

Nejrozšířenější metodou pro deferred shading je použít separovaný pass pro částice, často také počítáme pouze poloviční buffer, případně s 2x2 sub-pixely (4xMSAA), výkonově je to lépe zvládnuté na konzolích. Na PC můžeme použít buffer velikostí se shodující s výstupním, jelikož fillrate a bandwidth grafických karet na PC je mnohem větší.

Závěrem

Abych to nějak shrnul, pokud máte chuť a čas optimalizovat svůj částicový systém, zde je pár hlavních bodů:
    - proveďte particle trimming, tím získáte velmi mnoho

    - využijte geometry shadery na nových kartách (případně to jde také přes R2VB na starších) ke generování geometrie částic na nich

    - pokud je to možné přesuňte výpočet particle systémů na GPU (nejmoderněji asi přes compute shader, jsou však také další cesty)

    - zkuste transformovat shadery pro všechny vaše částice do ubershaderu, možná to hodně pomůže (a možná také ne); pro vzdálené částice určitě použijte jednoduchý shader (LOD v shaderech)

    - textury pro částice umístěte do jediného (nebo mála) texturových atlasů, při započetí fáze renderování částic jej jednou připojte, nemusíte měnit texturu pro každý částicový systém, zrychlí to

    - použijte méně větších částic, raději než více menších (pokud jste limitování na výpočtu pohybu částic samotných), jinak ne ? razantně to může zvýšit fillrate

    - nepočítejte částicové systémy které nevidíte (variace frustum či occlusion cullingu na částice, včetně vypínání jejich vypočítávání, pokud je nevidíte), udržujte jim třeba jen časovou proměnnou (nebudou znovu naskakaovat při pohledu na ně, ale nebude třeba počítat geometrii ani pozice jednotlivých částic pokud je nevidíte)

Toto by bylo pár hlavních bodů pro výpočty a rendering částicových systémů, pokud některé z nich provedete, může váš program či hra běhat o něco rychleji, a každý výkon navíc se počítá ? můžete jej poté investovat do dalších efektů, jako jsou reflekce, GI, SSAO, pokročilejší fyzika a další.

EDIT: Nějakou dobu mi to již leželo na disku, tak jsem se rozhodl to alespoň nahodit sem, snad to někomu trochu pomůže. Jinak jedná se o část (upravenou) z takového interního how-to (mám tady toho více).
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovi WWW stránky
Deluxe



Založen: 31. 07. 2007
Příspěvky: 235
Bydliště: Oslavany

PříspěvekZaslal: 2. květen 2011, 22:46:45    Předmět: Odpovědět s citátem

Vilem Otte > Diky za dobry clanek.

Implementace castic mne asi brzo ceka, takze to prislo akorad vhod. Smile
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 2. květen 2011, 23:54:28    Předmět: Re: Optimalizace částicových systémů Odpovědět s citátem

Super článek. Pár malých detailů níže.

Vilem Otte napsal:
Pokud bychom vykreslili tyto částice natvrdo v módu additivního blendingu (samozřejmě back-to-front aby bylo vše zobrazeno správně)

U aditivního módu samozřejmě na pořadí nezáleží, mohlo by se to kreslit i front-to-back, pokud tam nebudou žádné jiné vnořené objekty (sčítání je komutativní).

Vilem Otte napsal:
Zadefinováním maximální hodnoty (počet sčítání např. 16) lze fillrate trochu snížit, to lze účinně aplikovat u rasterizérů (přes texkill/alpha test ? kde je zisk relativně vysoký

Jak chceš pomocí texkill omezit počet sčítání na 16 nebo omezit maximální hodnotu součtů? V shaderu nemáš žádnou informaci o colorbufferu přece. To by šlo akorát:
- buď pomocí stencil bufferu počítat počet sečtení a spoléhat se, že early-stencil test (tj. přes pixel shaderem) bude zapnutý namísto late-stencil (po pixel shaderu)
- nebo pomocí GL_NV_texture_barrier bezpečně získat hodnotu pixelu v colorbufferu a dle toho udělat texkill, ale každé volání glTextureBarrierNV() vyprázdní framebuffer cache, což není úplně ok na výkon. Pak ale je lepší dělat blending rovnou v shaderu.

BTW Emil Persson (Humus) napsal knihovnu na particle trimming, ale to asi víš.

Vilem Otte napsal:
Jak na toto vyzrát? Velmi jednoduše, snížit počet shaderů ? případně použít jeden ubershader.

Co vím, tak uber shader != jeden shader. Uber shader je něco jako meta shader, kterej se kompiluje do více menších specializovaných shaderů. To nesníží počet state changes. Aspoň teda to je definice, kterou znám. Použít jeden shader s dynamic branchingem může pomoct, ale je třeba si dát pozor na divergentní kód.

Vilem Otte napsal:
Pro textury je dobré použít texturové atlasy, místo 16 různých 256x256 textur použijeme 1 texturu 1024x1024.

Slušelo by se zmínit i texture arrays (GL_TEXTURE_2D_ARRAY), které právě na tohle jsou určeny.

Vilem Otte napsal:
je třeba je renderovat až po všech modelech (aby se správně provedl blending) a v pořadí back-to-front, což je nejnáročnější možný způsob (přepisuje Z-buffer, nedovoluje early-Z-out).

Není mi jasný, proč potřebuješ zapisovat do Z bufferu průhledné objekty. Když ten zápis vypneš, tak máš early-Z test zaručený (pokud nezapisuješ hloubku v shaderu).

Toť vše k článku.

--

Celkem by mě zajímalo, jak bys nasvětloval průhledný částicový systém v deferred rendereru (a samozřejmě by měl vrhat i nějaký stín). Pokud ovšem samostný systém nesvítí...
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Vilem Otte



Založen: 18. 09. 2007
Příspěvky: 462
Bydliště: Znojmo - Sedlesovice, Kravi Hora

PříspěvekZaslal: 3. květen 2011, 00:33:54    Předmět: Odpovědět s citátem

citace:
U aditivního módu samozřejmě na pořadí nezáleží, mohlo by se to kreslit i front-to-back, pokud tam nebudou žádné jiné vnořené objekty (sčítání je komutativní).

Samozřejmě, já uvažoval obecně i s vnořenými objekty. V opačném případě by na pořadí, jak píšeš, nezáleželo, samozřejmě pouze pokud by se jednalo o aditivní blending.

citace:
Jak chceš pomocí texkill omezit počet sčítání na 16 nebo omezit maximální hodnotu součtů? V shaderu nemáš žádnou informaci o colorbufferu přece. To by šlo akorát:
- buď pomocí stencil bufferu počítat počet sečtení a spoléhat se, že early-stencil test (tj. přes pixel shaderem) bude zapnutý namísto late-stencil (po pixel shaderu)
- nebo pomocí GL_NV_texture_barrier bezpečně získat hodnotu pixelu v colorbufferu a dle toho udělat texkill, ale každé volání glTextureBarrierNV() vyprázdní framebuffer cache, což není úplně ok na výkon. Pak ale je lepší dělat blending rovnou v shaderu.

Ten počet sčítání na 16 byl spíše pro ray-tracer (než pro GL či D3D), tam to jde snáze (e.g. máš informaci o color-bufferu, když to dobře napíšeš. Samozřejmě šlo by to teoreticky jak jsi psal - např. stencil bufferem - ale zřejmě bys tolik nezískal (rozhodně ne tolik co u raytraceru - tam to zrychluje docela dost).

citace:
BTW Emil Persson (Humus) napsal knihovnu na particle trimming, ale to asi víš.

J, pěkný prográmek, dokonce i popisoval někde jak na napsání vlastního...

citace:
Co vím, tak uber shader != jeden shader. Uber shader je něco jako meta shader, kterej se kompiluje do více menších specializovaných shaderů. To nesníží počet state changes. Aspoň teda to je definice, kterou znám. Použít jeden shader s dynamic branchingem může pomoct, ale je třeba si dát pozor na divergentní kód.

Máš pravdu, jedná se o meta-shader. Jde tady ale o princip toho, že často se více věcí píše 2-krát, nebo vícekrát. Samozřejmě normal-mapované částice a oheň nelze udělat stejným jednoduchým shaderem (tedy ne bez velmi náročného shaderu), ale když někdo používá rozdílný shader na modrý a červený oheň, tak potom to je zbytečné (a našel bys takové i mezi komerčními produkty, a docela hojně).
Proto jsem zmiňoval ubershader - není jeden, ale pokud se napíše "chytrý" prográmek na složení jednotlivých shaderů z něj, aby jich udělal co nejméně (a místo nějakých 30 shaderů pro 3 efekty můžeš mít ideálně 3 shadery pro 3 efekty vygenerované z ubershaderu - samozřejmě chtělo by to nějaký teoretický čítač operací, jaké bude shader potřebovat, atd.) - samozřejmě to není tak snadné napsat.
Ono napsání jednoho obřího shaderu by nebyla úplná výhra (proto jsem právě psal ubershader), ale pokud by nebyl jeden obří shader zase tak obří (tedy byl by únosný pro GPU), tak by to mohla být výhra - použít pouze jeden.

citace:
Není mi jasný, proč potřebuješ zapisovat do Z bufferu průhledné objekty. Když ten zápis vypneš, tak máš early-Z test zaručený (pokud nezapisuješ hloubku v shaderu).

Zápis můžeš teoreticky vypnout, prakticky ale hodně lidí dneska používá logarithmic Z-buffer, kvůli přesnostem (a protože u G-Buffer generation to není takový performance impact navíc) - a ten se musí dneska zapisovat v shaderu (kde to bude mít vliv).

citace:
Celkem by mě zajímalo, jak bys nasvětloval průhledný částicový systém v deferred rendereru (a samozřejmě by měl vrhat i nějaký stín). Pokud ovšem samostný systém nesvítí...

V raytraceru by to bylo jasné (tam lze udělat celkem velmi náročný traversal na toto - založený na fyzice), ale v deferred rendereru to je o něco horší. Celkem úspěšně se to povedlo s voxely a řezy skrz ně - ale to není particle systém.
Co vím, tak že někteří lidé měly úspěchy s vrstevnými stínovými mapami na jeho nasvětlení a stíny (což je docela overkill a imho to je dnes nepoužitelné v rozumném rozsahu).
Nasvětlení by teoreticky šlo přes normal mapy, ale abych zjistil v jaké hloubce v particle systému je (e.g. kolik světla se k němu dostalo skrz částice "nad ním") - tak bych asi provedl nějaký raycast, rychlostně by to zřejmě bylo rychlejší než vrstevné stínové mapy.

EDIT: Možná se zítra dokopu a doplním tam nějaké detaily, ať to je více srozumitelné v těch částech (např. jak je míněn ubershader, kdy ho použít a kdy naopak použít jen jediný shader, apod.).
Jop a texture arrays tam dopíši (jak to budu upravovat asi k odpoledni někdy), nechtěl jsem to sice nijak točit přímo na GL, nebo D3D - ale stávají se dneska pomalu standardem v určitých věcech, tak by se slušelo je zmínit.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovi WWW stránky
Mantharis



Založen: 28. 07. 2007
Příspěvky: 39

PříspěvekZaslal: 3. květen 2011, 08:54:51    Předmět: Odpovědět s citátem

Hezky clanecek!

PS: Akorat pozor na ten GL_TEXTURE_2D_ARRAY, pred cca pul rokem mi zpusobil nekolik bezesnych noci, kdyz odmital fungovat na novych GeForce kartach ( na GeForce 8800 to fungovalo, na GeForce 470 a 480 proste ne )
_________________
If the God gave us the source code we could bug the world.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Ladis



Založen: 18. 09. 2007
Příspěvky: 1484
Bydliště: u Prahy

PříspěvekZaslal: 3. květen 2011, 11:47:47    Předmět: Odpovědět s citátem

A už zas spíš dobře? Jako jestlis to vyřešil. Je rozdíl "nepoužívat - na nových GeForce kartách to nefunguje" a "musíte to udělat takhle, aby to na nových GeForce fungovalo".
_________________
Award-winning game developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Mantharis



Založen: 28. 07. 2007
Příspěvky: 39

PříspěvekZaslal: 3. květen 2011, 13:03:16    Předmět: Odpovědět s citátem

->Ladis
Ten problem jsem nevyresil...tipoval bych to na bug v ovladacich, tehdy ty karty byli jeste celkem novy. Nakonec jsem to obesel 3D texturou a od ty doby jsem to nezkousel.
_________________
If the God gave us the source code we could bug the world.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
quas4



Založen: 18. 10. 2007
Příspěvky: 199

PříspěvekZaslal: 5. květen 2011, 16:20:38    Předmět: Odpovědět s citátem

me se osvedcilo:

- omezit globalni maximum castic + specificky algoritmus na pridelovani maxima castic jednotlivym emitorum (napr. priority)

- za pomoci premultiplied-alpha style se lze vyhnout prepinani blendingu -- obzvlast vhodne prolinaji-li se castice vice emitoru na malem prostoru (samozrejme jsou vsechny razeny bez ohledu na prislusnost k emitoru)

- vsechny castice lze vykreslovat do mensiho bufferu (1/4) a vysledek zakomponovat do vysledneho bufferu (nutne vyresit vytvoreni "maleho" z-bufferu)
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 5. květen 2011, 17:32:32    Předmět: Odpovědět s citátem

quas4 napsal:
- za pomoci premultiplied-alpha style se lze vyhnout prepinani blendingu -- obzvlast vhodne prolinaji-li se castice vice emitoru na malem prostoru (samozrejme jsou vsechny razeny bez ohledu na prislusnost k emitoru)


Dík za přípomínku, zrovna mě totiž napadlo, že se to tady dá využít ještě líp...

Premultiplied alpha se může hodit na kombinaci scény renderované jako deferred s částicema renderované samostatně jako forward.

Premultiplied alpha totiž zajištuje asociativitu blendovací funkce. Částice se normálně blendují takto: ((((s*p1)*p2)*p3)*..., kde s je scéna/pozadí, pn je částice a * je blendovací operátor. S premultiplied alpha si můžeme kvůli asociativitě dovolit vyrenderovat částice do samostatnýho RGBA bufferu P=p1*p2*p3*..., a při deferred shadingu pak udělat jednoduše: s*P.

Takže máme kromě normal/depth a color/specular bufferů ještě particle buffer, který se snadno zakomponuje do finální scény.
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 5. květen 2011, 17:41:34    Předmět: Odpovědět s citátem

Mantharis napsal:
PS: Akorat pozor na ten GL_TEXTURE_2D_ARRAY, pred cca pul rokem mi zpusobil nekolik bezesnych noci, kdyz odmital fungovat na novych GeForce kartach ( na GeForce 8800 to fungovalo, na GeForce 470 a 480 proste ne )

To bys měl v první řadě reportovat jako bug. NVIDIA drivery totiž vůbec nedodržují specifikaci a dělají si, co chtějí + tam mají nějaký bugy (nedávno jsem napsal i unit test v OpenGL, co ten driver crashne). Pokud chceš vědět, jestli tvůj kód pro "NVIDIA-GL" funguje i na normálním OpenGL, zkus to na Radeonech. Wink
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
frca



Založen: 28. 07. 2007
Příspěvky: 1403

PříspěvekZaslal: 21. červenec 2013, 13:44:08    Předmět: Odpovědět s citátem

Má smysl discardovat fragmenty částic, které nebudou reálně vidět? Tzn. jsou u aditivního blendingu blízké černé, u alfa blendingu mají alfa kanál blízký nule? Nebo se to tím spíš zpomalí?
_________________
www.FRANTICWARE.com
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
VladR



Založen: 30. 07. 2007
Příspěvky: 1322
Bydliště: Greater New York City Area

PříspěvekZaslal: 22. červenec 2013, 17:36:28    Předmět: Odpovědět s citátem

Mne sa killovanie fragmentov v Pixel shaderi vzdy oplatilo, ale netrufol by som si povedat jednoznacny verdikt, lebo vsetky situacie som tuna nepresiel.

Ono to dost zavisi, ako je prave busy cela pipeline, co je teda fest zavisle na tej ktorej hre/HW. Cize, nemusis si vsimnut zrychlenie u seba, ale inde bude.

Mozno sa teraz mylim, ale rozhodne by som ich v shaderi killoval. Mate niekto skusenost, ze killovanie spomaluje ?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
pcmaster



Založen: 28. 07. 2007
Příspěvky: 1768

PříspěvekZaslal: 22. červenec 2013, 21:48:43    Předmět: Odpovědět s citátem

Uz len pritomnost clip instrukcie za podmienkou v shaderi to spomali. Nespominam si uplne presne, niekto ma opravte, ale pritomnost "kill" vypina niektore optimalizacie. Aj napriek tomu si vsak myslim, ze sa killovat oplati.

Vyhodny je ten trimming -- uz len blba kruhova castica vam usetri cca 1 - (pi*r*r) / (4*r*r) = 21% fillrate, pri vseliakych hviezdiciach este ovela viac.

Na tiene sme mali v offline rasterizacnom DX11 rendereri naimplementovane deep shadow-maps i fourier shadow-maps, oboje dava prekrasne vysledky a imho uz je pouzitelne i v praxi, hlavne na ohne, dymy a tak. A hlavne je to pouzitelne i s raymarchovanymi fluidmi (znovu ohen a dym, napr.).

Co sa tyka nasvetlenia viacerymi svetlami, tak to sa da vyriesit tiez vyborne v shaderi, najlahsie v compute, ale ide to samozrejme aj v cistom vertex shaderi so stream out (DX10) bez GS a bez PS.

1. Do bufferu si ulozis sto svetiel, uploadnes na kartu. Vykreslis bodove castice (pripadne quady, pripadne teselovane na CPU, v GS alebo pomocou teselatora -- osobne som za moznost s GS) a pre kazdy vertex prebehnes cyklus cez svetla a ak je to vhodne a mozne, tak aj cez prislusne shadow-mapy (napriklad v texture array). Pripadne viac passov. Takto ziskas osvetlene a otienovane vertexy (a fill? NULA vykreslenych pixelov!!!). Vacsinu ALU i samplovania presunies do VS.

2. Pripadny sort bud na CPU alebo na GPU (podla poctu)

3. No a tieto particle potom uz len finalne vykreslis s PS s tym, ze v pixel shaderi sa uz nebude vobec samplovat shadowmapa a ani svetlo, len male textury z atlasu/pola.

Dufam, ze je to pochopitelne Smile Dodam, ze "fillrate" nula je usetrenie proti stavu, ze by bolo nutne kazdu casticu z nejakeho dovodu vykreslovat niekolkokrat, co sme my mali (tazke vysvetlit). V konecnej rasterizacii sa musia vyrasterizovat tak-ci-tak a ak bude overdraw, tak proste bude.

Vsetky vymenovane moznosti su dobre a nemal by byt problem pouzit co najviac z nich. Vyborne zamyslenie, i to poukazanie na ray-tracing, radost citat Smile
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
frca



Založen: 28. 07. 2007
Příspěvky: 1403

PříspěvekZaslal: 22. červenec 2013, 22:37:46    Předmět: Odpovědět s citátem

Tak jsem to zkoušel a s discardem to je skoro to samé (na nVidii, OpenGL). Takže na to kašlat.
_________________
www.FRANTICWARE.com
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Tringi



Založen: 28. 07. 2007
Příspěvky: 283

PříspěvekZaslal: 23. červenec 2013, 05:59:49    Předmět: Odpovědět s citátem

pcmaster napsal:
Vyhodny je ten trimming -- uz len blba kruhova castica vam usetri cca 1 - (pi*r*r) / (4*r*r) = 21% fillrate, pri vseliakych hviezdiciach este ovela viac.

Myslíš že by se mi vyplatilo mít ne-čtvercové částice v něčem tak triviálním jako je průlet hvězdokupou?
_________________
systems programmer
CV | WWW | FB | TW
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Zobrazit příspěvky z předchozích:   
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Magazín Časy uváděny v GMT + 1 hodina
Jdi na stránku 1, 2  Další
Strana 1 z 2

 
Přejdi na:  
Nemůžete odesílat nové téma do tohoto fóra
Nemůžete odpovídat na témata v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete hlasovat v tomto fóru


Powered by phpBB © 2001, 2005 phpBB Group


Vzhled udelal powermac
Styl "vykraden" z phpBB stylu MonkiDream - upraveno by rezna