TBDR, avagy egy igazán speciális irány
A TBR speciális elgondolása a TBDR (tile-based deferred rendering). Ez lényegében gyakorlatilag minden felesleges számítástól megkíméli a rendszert. A TBR alapvetően a nem látható háromszögekre helyezi a hangsúlyt, de attól, hogy ezeket eliminálja a futószalag, még lehetnek felesleges számítások. A TBDR ezeket is kiszűri a speciális felületkivágással, ami pixelszinten történik, vagyis nem juthat tovább olyan fragment, ami a végső eredményben nem látszik. A fragment kifejezés nem biztos, hogy ismerős az olvasóknak, így leírjuk, hogy ezek olyan adatok, melyek szükségesek az adott pixel generálásához. Maga az adat tartalmazhat raszterpozíciót, mélységinformációt, interpolált attribútumokat, valamint stencil és átlátszóságra vonatkozó paramétert. A címkézés az a lépcső, amelyik csoportokba rendezi a látható fragmenteket, amelyek további feldolgozásra kerülnek.
A TBDR logikai futószalagja [+]
Ha az előbbi feldolgozást valamihez hasonlítani szeretnénk, akkor kézenfekvő felhozni a deferred render leképzési mód alapjait, melyre manapság a játékok többsége épít. Tulajdonképpen ez egy olyan szoftveres megoldás, mely a mélységpufferrel rendelkező grafikus vezérlőkön próbál hatékonyabb feldolgozást kreálni. Lényege, hogy a leképzés több fázisban történik. Először csak a geometria kerül kiszámításra, amiből egy mélységpuffert nyer a rendszer. A második fázis újra leképzi a geometriát, de most már a shaderekkel és a textúrákkal együtt, ugyanakkor csak azok a pixelek kerülnek kiírásra, amelyeknél a Z érték megegyezik azzal a paraméterrel, amit az előzőleg létrehozott mélységpuffer tárol.
Ha nagyon le akarjuk az egészet egyszerűsíteni, akkor egy TBDR elgondolással dolgozó rendszer nagyjából azt csinálja, amit egy deferred render, csak éppen hardveres megközelítés mellett. Ezzel lényegében mélységpufferre sincs szükség, mivel a mozaikos feldolgozáshoz kialakított gyorsítótárak tökéletesek a tempós feldolgozáshoz.
A TBR és a TBDR első hallásra jól optimalizált futószalagoknak tűnnek, hiszen hatékonyabban bánnak a rendelkezésre álló erőforrással, mint az IMR megoldások, de vannak buktatók is. Például számottevő problémát jelentenek az átlátszó textúrák. Ez az első oldalon említett sziklás példánkkal élve nem szemléltethető, de gondolhatunk itt a virtuális ablakokra. Amikor az ablak geometriai váza kirajzolódik, akkor a rendszer még nem tudja, hogy azon a felületen egy átlátszó textúra lesz, ami igen kellemetlen, hiszen mire ez kiderül, addigra a futószalag kivágta a felület mögötti geometriát. Itt jön képbe az átlátszóságteszt, mely logikailag össze van kötve a kivágásért felelős lépcsővel, így ha mégis szükség van extra adatokra, akkor azok utólag kirajzolhatók. Ezen a ponton a legfontosabb, hogy az adott mozaikra vonatkozó transzformált vertex adatok, illetve a háromszöglista ott legyen a memóriában mindaddig, amíg a mozaik kiírásra nem kerül a frame bufferbe.
Ugyanez a probléma felmerül a deferred renderre építő motoroknál. Erre a gondra a fejlesztőknek kell egyéni megoldást találni, amit be kell építeni a használt futószalagba.
Az elméleti áttekintés mellett fontos kiemelni, hogy az IMR és a TBR, illetve a vizsgált speciális esetek csak irányadóak, egyfajta általános összefoglalója az eltérő csoportoknak. A GPU-fejlesztéssel foglalkozó cégek ezeket nem követik szigorúan. Bár az alapokat tekintve mindegyik rendszer működése visszavezethető a vizsgált futószalagok valamelyikére, de ezeket jellemzően kiegészítik. Példának okáért az új generációs GeForce és Radeon termékek alkalmaznak a képkocka számítása során egyfajta mozaikos felosztást a feldolgozás optimalizálása érdekében. Szintén megjegyzendő, hogy a mai legújabb hardverek már annyira komplexek, hogy gyakorlatilag működhetnek IMR és TBR futószalaggal is, de az adott logikai dizájnt hozzá kell tervezni a futószalaghoz, így jellemzően egy IMR-hez igazított GPU nem lesz hatékony TBR futószalaggal, és fordítva.
A cikk még nem ért véget, kérlek, lapozz!
