Hirdetés

Furcsa generációváltás AMD-módra

Mostantól akkor lehet tesszellálni?

A tesszellálást sok felhasználó a DirectX 11 és a számítógépes grafika Szent Gráljának tartja. Maga az elgondolás kiváló ötlet, ám egyelőre csalódás, amit a Microsoft új generációs API-ja ebből a szempontból a játékokban mutatott. Egy korábbi cikkünkben már leírtuk, hogy a probléma alapvetően az API felépítésével van, így a tesszellálás az aktuális futószalag alatt számos problémát eredményez a környezet és a modellek interakciója szempontjából. Ez a fő oka annak, hogy a fejlesztők az eljárást főleg effektekre, karakterekre, és nagyon ritkán az objektumokkal közvetlen kapcsolatba nem lépő felületekre használják a DirectX 11-es játékokban. A probléma mértéke a StoneGiant tesztprogramban tökéletesen látszik. A fejlesztők megpróbálták úgy elhelyezni a bogarakat, hogy tesszellálás mellett ne tűnjön el a lábuk, de láthatóan ez nem mindenhol sikerült. Továbbá az alapfelülethez képest az egyik láb semmihez sem ér hozzá, sőt a nem tesszellált felületen sokkal a terep fölé emelkedik. Tekintve, hogy statikusan vannak elhelyezve az objektumok könnyen elképzelhető, hogy mi lenne egy járkáló bogárnál, ahol sokszor a láb fele is eltűnne a tesszellált felület alatt.


A tesszellálás egyik kellemetlen mellékhatása [+]

Ehhez hasonló problémák a karakterek tesszellálásánál is előkerülnek. Tipikusan nehézkesek megoldást találni a túl éles felületekre. Itt a programozók és az artisták összedolgoznak, hogy megoldják a gondokat egy speciális modell elkészítésével, mely jól mutat tesszellálással és többnyire anélkül is. A karakterek esetében a probléma tehát kezelhető, de nem kevés időbe telik. Szerencsére a jelenlegi DirectX 11-es játékokban jól vették a fejlesztők a tesszellálással kapcsolatos akadályokat, ugyanakkor sajnos akad ellenpélda is. A Lost Planet 2 esetében nem sokat gondolkodtak ezen a jelenségen, így kifejezetten irritáló lett, amikor a méretes szörnyek tesszellált lába, vagy egyéb más testrésze a belefolyik a talajba. Természetesen nem kétséges, hogy egy tesszellálásra alkalmas modell elkészítése jelentősen több időt vesz igénybe, de a valós idejű grafikában egyszerűen illúzióromboló jelenség a felületek elnagyolt interakciója.


A Metro 2033-ban alkalmazott Phong tesszellálás kellemetlen mellékhatása a cípőtalpnál [+]


A cípőtalp végső állapota a modell korrigálása után. [+]

A tesszellálásnál tehát az elsődleges probléma, hogy a DirectX 11-es API mellett a régebbi kártyákhoz tartozó grafikának is jól kell kinézni, és ez a felületek esetében összeegyeztethetetlen. Erre megoldás lehet a régebbi rendszerek kizárása a program futtatásából, amit a relatíve kevés eladott DirectX 11 GPU-t látva, az elkövetkező egy-két évben minden fejlesztő el fog vetni. Másik lehetőség az új API lehet, ahol valamilyen módon korrigálva van az interakció. Persze hatalmas áttörést ez sem jelentene, mert a mai hardvereket egyszerűen nem készítették fel az úgynevezett mikropoligon rendereléshez, ami sok fejlesztő álma jelenleg.


[+]

Elméleti alapon megfelelő a futószalag ahhoz, hogy olyan részletes modellezést alkalmazzunk a világra, ahol egy háromszög egy pixelnél is kisebb. Gyakorlatban sajnos a hardverek erre képtelenek, továbbá a jövőben esedékes DirectX 12-ben egyéb kiegészítéseket is lehet alkalmazni, ami segít a gyorsabb feldolgozásban. A tesszellálás legnagyobb rákfenéje a raszterizálás hatékonysága, ami eddig nem jelentett problémát, de az új futószalaggal erősen meg lehet közelíteni egy olyan határt, ami egyszerűen túlterheli a kártyákat ebből a szempontból. A mai GPU-kra egységesen jellemző, hogy a raszterizálást négyes pixelblokkokon hajtják végre, ami annak köszönhető, hogy ez a feldolgozási elv a párhuzamos munkavégzés mellett nagyon hatékony. Az elsődleges gond akkor merül fel, ha egy háromszög kisebb, mint négy pixel. Ilyen esetben a négyes blokk nem azonos háromszögön dolgozik, vagyis a másik háromszögre is ki kell számolni a teljes blokkot, ami lényegében az erőforrás nagymértékű pazarlása. Ennél sokkal rosszabb, ha egy háromszög egy pixel nagyságú, mivel számítás az egyik háromszöggel kezdődik az egyik pixelen, ami mellé további három képpont tartozik, a blokkosított feldolgozás miatt. Ez már önmagában azt jelenti, hogy egyetlen apró háromszögért négy pixelt kell ellenőrizni, ám a poligon kicsi, így jó eséllyel mellette lesz a társa, ami további ellenőrzéseket jelent. A gyakorlatban ez a jelenség még rosszabb, ugyanis háromszögek nem fedik tökéletesen a pixelt, vagyis legrosszabb esetben 12 pixel ellenőrzését is végre kell hajtani, ahhoz hogy egyetlen képpont raszterizálva legyen.

A gyors raszterizáláshoz tehát elsődleges szempont megtartani a hatékonyságot, vagyis minél kevesebb felesleges munkát végez a hardver annál jobb. A manapság terjedő Full HD-s felbontás mellett már jónak mondható, ha egy háromszög minimum 16 pixel, vagyis a fejlesztőknek arra kell törekedni, hogy a feldolgozás során ennél kisebb háromszög ne keletkezzen. Ilyen esetben a raszterizálás hatékonysága szinte biztos, hogy 90% fölött tartható, ami általánosan elfogadott érték. Nem sokkal kisebb háromszögek mellett a hatékonyság drasztikusan romlik, vagyis a fenti határt túllépve könnyen 50% alatt találhatja magát a fejlesztő, ami komoly mértékben meglátszik a teljesítményen is.


[+]

Az Unigine Heaven tesztprogram extrém tesszellálás mellett jó példa az előbbi bekezdésben taglalt problémára, és a legmegterhelőbb résznél egyetlen GPU sem képes folyamatos sebességet biztosítani, pontosan a raszterizálás lerontott hatékonysága miatt. A tesszellációs faktort tehát érdemes nagyon körültekintően megválasztani. Az is kérdés, hogy érdemes-e a háromszögek minimum méretét 16 pixel alá vinni, vagyis a magasabb tesszellálási faktornak lesz-e gyakorlatban látható eredménye. Ez nagymértékben függ az alkalmazott magasságtérképtől. Az említett Unigine Heaven tesztprogram alatt például nem nincs gyakorlati különbség a 10 pixeles és a 16 pixeles háromszögek között, miközben a sebesség érezhetően javul.


Unigine Heaven 16 és 10 pixeles háromszögek mellett [+]

Ha még nem lenne elég a problémákból, akkor az élsimítás is rá tesz erre egy lapáttal. A kedvelt multisampling megvalósítás pont a háromszögek élein dolgozik, vagyis a tesszellálás egyáltalán nincs jó hatással a teljesítményére. Persze kétségtelen, hogy számos kompatibilitási nehézség szól a multisampling ellen, így ez a gond csak egy újabb szög az elterjedt élsimító algoritmus koporsójában, de intő jel a fejlesztőknek és a gyártóknak, hogy el kell kezdeni egy olyan megoldást keresni az élsimításra, ami nem szenved gyermekbetegségekben. Úgy néz ki, hogy erre a szerepre a morfológiai szűrés a legesélyesebb nevező, hiszen a teljesítménye nem függ az élek számától, továbbá nincs olyan eljárás, amivel ne lenne kompatibilis. Az AMD is úgy látja, hogy ez a jövő, így egy DirectCompute alapú post-process effekt formájában el is készítették a saját megvalósításukat, amit a HD 6000 szériás kártyákhoz már aktiváltak a driverben, de a HD 5000-es kártyák tulajdonosai is megkapják a támogatást a szokásos tesztelés befejezése után. A jól párhuzamosítható algoritmus egyébként csak a GPU nyers számítási teljesítményre érzékeny.

A tesszellálás tehát felemás képet fest le magáról. Mivel ez a DirectX 11 leglátványosabb része, sok felhasználó csalódottságot érez a jelenlegi játékokban alkalmazott szint láttán. Egyelőre nem várható, hogy belátható időn belül javul a helyzet, amíg a fentebb tárgyalt problémákat magunk mögött nem hagyjuk. Ehhez mindenképpen szükség van új hardverekre, valamint egy új DirectX API-ra is, ami kijavítja és kiegészíti a jelenlegi futószalag hiányosságait.

A Cayman és a GPGPU

Az AMD az általános számítási képességek tekintetében is előre lépett. A Cayman egyik legnagyobb újítása az aszinkron feladatirányítást használata, azaz a GPU több, teljesen független utasításfolyam párhuzamos futtatására is alkalmas. Ebből következik, hogy ez az első olyan rendszer, ami egyetlen grafikus processzoron képes több GPGPU-s alkalmazás párhuzamos futtatására. További újítás a két darab bidirekcionális, vagyis kétirányú DMA motor használata, ami gyorsítja a memória írását és olvasását.

A memóriavezérlő nem érte sok változás, így az AMD továbbra is az RV770-ben megismert Control Hub mellett tette le a voksát, ami négy darab 64 bites csatornát üzemeltet. Ezekhez a csatornákhoz kapcsolódik egy-egy 128 kB kapacitású, csak olvasható másodlagos gyorsítótár és két-két ROP blokk. Utóbbiból összesen nyolc darab van, ami 32 blending és 128 Z mintavételező egységet eredményez. Itt fontos újítás, hogy a blokkok jelentős fejlődésen mentek keresztül, így az előző generációhoz képest kétszer gyorsabban végzik a 16 bites unorm és snorm operációkat, valamint a 32 bites lebegőpontos utasítások feldolgozása akár négyszer gyorsabb is lehet. Ezenkívül a Barts-ban megismert UVD 3.0-s motor természetesen megtalálható a Caymanban is.

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

  • Kapcsolódó cégek:
  • AMD

Azóta történt

Előzmények

Hirdetés