Bevezetés a fermis GeForce rejtelmeibe

Geometrikus innováció

A GF100 egyik sarkalatos pontja a felújított setup motor. Manapság a grafikus processzorok egy ilyen egységgel rendelkeznek, azonban az NVIDIA megszakította ezt a hagyományt és új elgondolással állt elő, aminek a hatására a hagyományos értelemben vett setup motort egy raszteres és egy úgynevezett PolyMorph részre vágta. Az előbbi egységből négy található a lapkában, így egy raszter motor négy-négy streaming multiprocesszorról gondoskodik. Ezt a felállást a vállalat Graphics Processing Clusternek (GPC) keresztelte el. Egy raszter motor egyébként órajelenként 8 pixelt képes feldolgozni, ami a teljes lapkára nézve 32 pixelt jelent. Összehasonlításképpen a Cypress is 32 pixelt kezel órajelenként, ám a Fermi esetében ez a szám limitálóan hat a blending egységek teljesítményére, hiszen 48 lenne az ideális érték. Természetesen a felbontás növelésekor ez is kedvezőtlen hatást fejt majd ki a teljesítményre.


[+]

A streaming multiprocesszorokban található PolyMorph motor a geometriával kapcsolatos munkálatokat végzi. Érdemes észrevenni, hogy a DirectX 11 szempontjából fontos tesszellátor is ebben az egységben található, ami azt jelenti, hogy az NVIDIA összesen 16 darab fixfunkciós feldolgozót alkalmaz, szemben a Cypress egy tesszellátorával. De mitől is függ a tesszellálás sebessége? A Microsoft új API-jában bemutatkozó eljárás működéséről már korábban írtunk, ám nem tértünk ki részletesen a gyakorlati tényezőkre. Itt az idő bepótolni ezt a hiányosságot!

Hirdetés

A tesszellálás három fázison keresztül zajlik. Ezek közül az első és az utolsó lépcső, azaz a hull és a domain shader programozható, míg maga a tesszellálás fixfunkciós egységen keresztül zajlik. A hull shader csak a kontrollpontok kijelöléséért, illetve a tesszellálás mértékéért felel. Az igazi munka az utolsó fázisban kezdődik. A végleges felület kialakítása a displacement map segítségével történik, és maguk a shader processzorok végzik el a feladatot. A rendszerek ezen a ponton komoly terhelést kapnak, hiszen rengeteg háromszög keletkezik a felületek felbontása után, ami brutálisan igénybe veszi számítási kapacitást. Ezen a ponton az AMD shader fordítóján is sok múlik, hiszen a szuperskalár processzorokat egymástól nem függő utasításokkal kell etetni, és ha ez nem sikerül, akkor az egységek kihasználatlanok lesznek. A Fermi architektúrája komponens folyamokat dolgoz fel, ami alapból kizárja a függőség lehetőségét. Gyakorlatilag a Radeon teljesítményére a domain shader jelenti a legnagyobb veszélyt. Ha nem megfelelő a párhuzamos feldolgozás, akkor kihasználatlan lesz a chipben rejlő erő. A shader fordító ezen alkalmazástól függően képes javítani.

Elhagyva a tesszellálással kapcsolatos fázisokat létrejött a virtuális világ végleges geometriája. Innentől kezdve a keletkezett háromszögek tömkelege az összes hátralévő fázist terheli. A következő problémás terület a raszterizálás, itt összességében hasonlóan teljesít a Cypress és a GF100, ám a Hemlock mindkét lapkát lehagyja. A kis háromszögek tipikusan az interpolációnál jelentenek gondot. A Fermit a fixfunkciós egységek korlátozott teljesítménye akadályozza, míg az AMD architektúrájának a helyzetét az interpoláció emulálása nehezíti meg, ami a 32 kB-os helyi adatmegosztásra létrehozott Local Data Share tárterületét használja az ideiglenes adatok megőrzésére. Szerencsére a termékek itt nem kapnak komoly büntetést a teljesítményre nézve, ám a pixel shader lépcsőjében esedékes textúrázástól újra kikészülhetnek a rendszerek. Ezen a ponton viszont az NVIDIA van hátrányban, hiszen a GF100 textúrázó kapacitása nemhogy nőtt, hanem egyenesen csökkent az előző generációhoz képpest.



Távolságfüggő tesszellálás [+]

Megoldást jelenthet a terhelés csökkentésére a távolság- és a nézőpontfüggő skálázás. A DirectX 11-ben bemutatkozó tesszelláció programozható, így befolyásolni lehet a rendszer működését. A legfontosabb szempont, hogy a modellek és a felület minősége csak a kamerához közel legyen maximális, hiszen a távoli objektumok úgy is csak kis részét foglalják el a képernyőnek. Egyszerűen a különbség nem vagy csak alig látható, ám sebesség szempontjából rengeteget lehet nyerni. A tesszellálás LOD-ját, vagyis távolságtól mért minőségét a hull shaderben lehet beállítani. A másik lehetőség a tesszellált felületek nézőponttól függő skálázása. Ezzel a módszerrel azok a részek nem kerülnek tesszellálásra, amelyek amúgy sem vagy csak minimálisan befolyásolnák a végleges képkockán az eredményt. A hull shaderben alkalmazható eljáráshoz csak az irányvektor, illetve az élhez tartozó átlagos normál skaláris szorzatára van szükség. A számítások elvégzése után a nem fontos háromszögeket nem is kell felbontani. Ezekkel az optimalizálásokkal rengeteg teljesítményt lehet nyerni, és az alábbi képek mutatják, hogy a feltextúrázott eredmény gyakorlatilag azonos lesz.



Nézőpontfüggő tesszellálás kikapcsolva és bekapcsolva [+]

Összességében a komoly mértékű tesszellálás gyakorlatilag minden kártyán kifog. Ebből a szempontból a legjobb egy GeForce GTX 470 vagy 480 SLI-t építeni, ám jelenleg csak az Unigine Heaven tesztprogram használ olyan terhelést, ami a manapság elvárható Full HD-s felbontásban az elérhető összes kártyát elintézi, bár a GeForce GTX 480 és a Radeon HD 5970 teljesítménye elfogadható. A játékok szempontjából sokkal jobb a helyzet. Jelenleg a Dirt 2, a Stalker: Call of Pripyat, az Aliens vs. Predator és a Metro 2033 használ tesszellálást, ám ennek a mértéke rendkívül alacsony, és többnyire csak a modellekre, illetve pár effektre korlátozódik. A mai kártyákat ez a szint alig terheli, így a fenti problémák közül szinte egyik sem áll fent. Persze felmerülhet a kérdés, hogy a fejlesztők miért nem használják a tesszellációt úgy, ahogy az Unigine Heaven. Erre a várható alacsony sebességen kívül konkrétabb válasz is van.


HD verzió! - Forrás: Unigine

A tesszellálás számos problémát eredményez a környezet és a modellek interakciója szempontjából. Az előbbi videó a Heaven tesztprogram különbségeit mutatja bekapcsolt és kikapcsolt tesszellálás mellett. Látható, hogy a felület nagymértékben megváltozik, egyszerűbben fogalmazva a kövek a displacement map hatására nagyon is kiemelkednek az eredeti felszínből. Ez egyelőre megoldhatatlan nehézségeket teremt egy játékprogramban, mivel a jelenetben interakcióba lépő felület nem egyezik meg a monitoron megjelenített felszínnel. A könnyebb érthetőség érdekében érdemes beleképzelni a videóban egy virtuális karaktert, aki egyszerűen csak áll a köves, nem tesszellált úton. A modell cipője szépen illeszkedik a síknak látszó terephez, ám ebbe az illúzióba rögtön belerondít a tesszelláció, ami annyira kiemeli a felületet, hogy a karakternek a bokája elsüllyed benne. Ez a jelenség azért születik meg, mert a tesszelláció csak a geometry shader fázistól létezik, azaz jelenetszámításánál a később kiemelkedő felszínt nem veszi számításba a program. Természetesen olyan példát is fel lehet hozni, ami befolyásolja a játékmenetet is. Ha egy lövöldözős programban a fedezékként szolgáló oszlopot teljesen tesszellálással generáljuk, akkor az nem jelent fedezéket, mivel a jelenetnél kalkulált virtuális golyók, az interakciók hiányában áthaladnak a látható, de valójában nem létező felületen, hovatovább maguk a karakterek is átsétálhatnak rajta. Erre a problémára nem létezik globálisnak mondható megoldás, így a fejlesztőknek kell kis trükköket bevetni, ami elfedi a jelenség létezését.

Az órajelek tekintetében is változott a GF100, hiszen a rendszer nagy része az úgynevezett GPC vagy shader frekvencián üzemel. A CUDA magok és a speciális végrehajtó egységek minden órajelnél, míg a textúrázók, a raszter, valamint a PolyMorph motorok minden második órajel mellett végeznek egy feladatot. A magórajel mostantól csak a ROP-blokkokért és a másodlagos gyorsítótárért felel. Fontos megjegyezni, hogy a Fermi minden shadertípust azonos szinten kezel, így nem rendelkezik az előző generációs architektúra geometry shader programok futtatása esetén fellépő gyermekbetegségével, azaz megfelelő sebesség érhető el a Stream Out használata mellett is. Ennek köszönhetően a fejlesztők elkezdhetnek ebbe az irányba lépdelni, mivel számos kihasználatlan eljárás készült, ami jelentősen javíthatja a jövőben megjelenő programok képminőségét.

A cikk még nem ért véget, kérlek, lapozz!

Hirdetés

Azóta történt

Előzmények

Hirdetés