Optimalizace částicových systémů

[Vilem Otte]

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.

[Deluxe]

Vilem Otte > Diky za dobry clanek.

Implementace castic mne asi brzo ceka, takze to prislo akorad vhod.

[Marek]

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

[Vilem Otte]

[Mantharis]

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.

[Ladis]

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

[Mantharis]

->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.

[quas4]

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)

[Marek]

[Marek]

[frca]

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

[VladR]

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 ?

[pcmaster]

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 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
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[frca]

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

[Tringi]