Bevezető

Az NVIDIA NV3x sorozatba tartozó grafikus processzorait számos kritika érte. A gyártó szemére vetették többek közt a viszonylag gyenge shaderteljesítményt, a feles, 16 bites precizitás erőltetését és az elavult antialiasing megoldásokat. Nem tett jót a GeForce FX sorozat hírnevének a 3DMark kapcsán fellángolt driveroptimalizációs vita sem, amely a videokártyák tesztelési módszereinek újragondolására kényszerítette a szaklapokat és bizalmatlanságot szült a felhasználók körében.

Az NVIDIA mégsem jött zavarba, és váltig állította, az újabb generáció majd orvosolja az FX-széria hibáit, sőt, jelentősen gyorsabb lesz annál. Ma végre elérkezett az ítélet napja, a GPU-gyártó hivatalosan is bejelentette korábban NV40 kódnéven futtatott chipjét, ami a keresztségben a GeForce 6800 (Ultra) nevet kapta. A chip nem kevesebb, mint 222 millió tranzisztort számlál, ezzel alighanem világrekorder a grafikus processzorok között.

Legfontosabb tulajdonságait az alábbi összehasonlító táblázatban foglaljuk össze:

A következő oldalakon a chip legfontosabb újdonságait vesézzük ki, és az NVIDIA által közölt teljesítményadatok alapján sejtetjük, hogy mire is lesz képes.

A harmadik shadergeneráció

6 vertex egység, 16 futószalag – kemény

Vertex Shader

Teljes DirectX 9.0c-, vagyis Vertex Shader 3.0-kompatibilitás a korábbi 256 vertex programutasítás helyett 65 535 (a hardver végtelen shaderkódot is tud), több általános célú és konstans regiszter, de ami még érdekesebb: dinamikus folyamatvezérlés (flow control), Displacement Mapping és Geometry Instancing.

Dinamikus folyamatvezérlés és csoportosítás

Az NVIDIA dokumentumai a GeForce 6800 – és a Shader Model 3.0 – egyik jelentős újításaként emelik ki a dinamikus folyamatvezérlés támogatását. Ugyanakkor tudni kell, hogy ez a – ciklusok és elágazások rugalmas kezelését lehetővé tévő – funkció már a korábbi (2.x-es) shader modellben is megtalálható volt, és részben már a korábbi GPU-k (NV3x és ATI R3x0) is képesek voltak a megvalósítására. Immáron azonban a GeForce 6800 pixel shadere is képes dinamikus folyamatvezérlésre.

Ennek során a programozó a megfelelő feltételekkel úgy tudja beállítani a shader programot, hogy csak az éppen szükséges programrészek fussanak le. A korábban szokásos statikus irányításnál csak kívülről, a programciklus elején lehetett beállítani, hogy hányszor fusson le a ciklus, míg az új módszerrel az bármikor megszakítható. Lehet olyan vertex shader programot írni, amely végigfut a vertexek egy csoportján (például egy 3D objektum összes csomópontján), megállapítja, hogy az aktuális jelenet fényeiből melyek hatnak rájuk, és a pixel shader már csak ezeknek a fényeknek a beiktatásával számol, így fölösleges munkától szabadul meg. Korábban a GPU – jelentős többletmunkával – az összes fény hatását kiszámolta volna (még akkor is ha ezek közül több nem is lett volna látható). Tipikusan ilyen takarékossági esetek az objektumok fénytől elforduló oldalai, vagy egy karakter csontváza, amelyre további felületek feszülnek.

Felmerül a kérdés, hogy a ciklusokat irányító folyamatok milyen hatással vannak a sebességre. Kell egy folyamat, ami vizsgálja a számolás tárgyait (vertexeket, pixeleket vagy ezek csoportjait ), eldönti, mikor melyik ágon kell továbbhaladni. A vizsgált feltételekhez valamilyen tárolóban (regiszterben) el kell rakni egy határértéket (az elágazás feltételét), ezzel erőforrásokat rabolva a tényleges számolástól. Vertex-szinten egyszerűbb a dolog, mert ezekből kevesebb van, mint a pixelből, de gondoljunk csak bele, mennyi plusz utasítás és regiszter (még ha csak ideiglenesen is) kell a képenként milliós nagyságrendben található pixelekhez! A korábbi NV3x-es sorozatnál is sokat hallottunk arról, hogy feláldozták a sebességet a rugalmasság oltárán; még mindig nincs shadert dinamikusan vezérlő játék a piacon. Tovább bonyolítja a helyzetet, hogy legújabb hírek szerint az ATI új hardverei nem is fogják támogatni a dinamikus vezérlést, vagy ha támogatni fogják, akkor csak korlátozottan.

A dinamikus csoportosítással a kisebb, minden lehetséges esetre kitérő, Pixel Shader 2.0-hosszba beférő programok összesíthetőek egy nagy, összes esetet összefoglaló egészbe, nem kell időt és memóriát pazarolni a sok kis program betöltésére.

Displacement Mapping

Korábban a vertex egységek nem férhettek hozzá textúrákhoz, csak a 3D-s környezet csomópontjaihoz – most ez megváltozott. A sima felületeket eddig pixel shader-trükkökkel tették rücskössé, jellemzően bump mapek használatával. Ez a lépés mostantól a vertex egységbe került, így kisebb számolásigénnyel lehet fényhatásokat számolni a domború felszínen, szebb víz, bőrfelület vagy ruházat generálható – gyorsabban.

Jobbra a dinó színe, balra a mintázat rácsa, felül a kész jószág

Geometry Instancing

A programozónak lehetősége van egy kiszámolt hatást (például egy Displacement Mappinggel kezelt felületet) többféle variációban – mondjuk eltolva – továbbadni. Ezzel a módszerrel létrehozható például egy halom rohamozó katona, akik ugyanazt a 3D-modellt használják, csak éppen más-más animációs fázisban vannak (más mozdulatot végeznek). Ennek a fázisnak megfelelően eltolva kapnak az egyszer kiszámolt felületből, ezáltal különbözőek lesznek, és egy halom számolást spóroltunk.

A pixel shader

A GeForce 6800 teljes mértékben támogatja a Pixel Shader 3.0-t. A korábbi legfeljebb 96 utasítás helyett a specifikáció 65 535 kezelését írja elő, ám az NV40 elméletileg végtelen hosszú kódot is képes megemészteni. Az egység – amint arról már szóltunk – képes dinamikus folyamatvezérlésre, több renderelési célpont kezelésére, de ami talán a legfontosabb: a GeForce 6 család alapvetően 32 bites pontossággal dolgozik, noha támogatja a feles (16 bites) módot is. Az NVIDIA szerint a hardver egyforma sebességet hoz a két módban, csak teljes pontosságnál értelemszerűen kétszer annyi memóriát (ezáltal memória-sávszélességet is) igényel.

Multiple Render Targets

A pixel shader számolások eredménye több köztes tárolóba (pufferbe) is elmenthető, majd ezek tartalma kombinálható ismételt kiszámolásuk nélkül. Tipikusan ilyen adatok a pozíció, a szín, az anyag vagy a normálisok (a képponthoz tartozó síkok tengelye, melyet fényvisszavetődés számolásakor használnak). Ilyen módon a fényhatások a teljes geometria renderelése után újabb pixel shader-lépés (pass) megtétele nélkül alkalmazhatóak, hiszen "ott figyelnek" a pufferekben. Ezt az eljárást szokás deferred shadingnek nevezni.

HPDR

Az NVIDIA nem győzi hangoztatni, hogy ez a termékcsalád 32 bites lebegőpontos precizitásra lett kihegyezve, ezáltal ma a lehetséges legjobb képminőséget tudja biztosítani textúrázásban és árnyalásban, eddig nem látott HDR-hatásokkal. De mi is ez a HDR? High Dinamic Range, vagyis nagy dinamikatartomány – az NVIDIA szóhasználatában még egy P-vel (precision) kiegészülve HPDR. A nagy dinamikatartomány segítségével még finomabb árnyalati különbségeket lehet létrehozni a vakítóan világostól a nagyon finom árnyékokig, mindezt akár egy képen.

Korábban minden színt egy 256-ös skálán lehetett leírni, és mivel egy színt 3 olyan alapszín (R-G-B) alkot, amelyek egyenként 256-féle erősséggel szerepelhetnek, az általuk kikevert színnek is ennyiféle erőssége lehet, és ez kevésnek bizonyul, ha erős fényt és finom árnyékolást akarunk egyszerre megjeleníteni. Másik probléma, hogy az emberi szem logaritmikus skálában érzékeny, sötét árnyalatokra érzékenyebb mint a világosakra. Ezen problémák kiküszöbölésére három részre bontható a HDR renderelés:

1. Megvilágítás

A rendelkezésre álló geometria, textúrák és fényforrások felhasználásával (itt jól jön a Multiple Render Target) pixelenként kiszámolásra kerül a visszavert fény (visszavert, mert csak a fényforrások bocsátanak ki fényt, a többi objektum ezeket visszaveri, ettől lesz színe). Ezeket a fényadatokat egy kellően nagy tartományú és jó felbontású bufferben kell tárolni, hiszen lehet az akár egy intenzív robbanás vagy egy sötét zug a szörny barlangjában. Az NVIDIA az Industrial Light & Magic OpenEXR szabványának megfelelő 16 bites (1 előjel, 10 mantissza, 5 exponens) lebegőpontos tárolási formát használ, amely megfelelő finomságot ad nagy logaritmikus intenzitástartomány tárolására. 12 dB-es tartományt ölel fel (12 nagyságrend van a legkisebb és legnagyobb ábrázolható szám között), legnagyobb érték 65 535 és a legkisebb 2^-24.

2. Tone Mapping

A kiszámított hatalmas fénytartományt (intenzitásokat) összeolvasztják a kép színeivel, világosodások vagy sötétedések keletkeznek.

3. Color and Gamma Correction

Az előző fázisban kiszámolt képet bele kell szorítani a monitor által megjeleníthető színtartományba és a logaritmikusságot is a kijelző érzékenységi karakterisztikájához kell igazítani. Ezt függvénymegfeleltetéssel lehet elérni, nem tartozik szorosan a 3D-képmegjelenítéshez, inkább színmetrikai kérdés, bár egyre érdekesebb, mert az LCD és CRT monitoroknak (és a digitális fényképezőgépeknek és a nyomtatóknak is) más és más a karakterisztikájuk, másképp jelenik meg rajtuk a kiszámolt kép.

A folyamatban végig fenn kell tartani a lehető legnagyobb precizitást. Az NV40-nél 32 biten történik az árnyalás, és lebegőpontos a színek és fények keverése – ebből például a motion blur (mozgás irányába történő dinamikus elmosás) profitál. Hasonlóan precíz szűrőket lehet alkalmazni élesítéshez, anizotropikus szűréshez, DHR Tone Mappinghez. Lebegőpontos textúrázás teszi még finomabbá a shadow map (árnyékok számolásához használt textúrák) vagy DoF (depth of filed – mélységkezelő) technikákat.

Nézzünk két példát:

Az első képen a két fényforrás (két nap a tájképen) intenzitása 100:1 arányú HDR nélkül. A másikon az intenzitások aránya HDR használatával 9000:1.

Nézzünk egy teljes pixel shader képalkotási folyamatot Multiple Render Targets és HDR használatával:

Első körben (rendering pass) háromféle adat tárolódik bufferekben:

1. color map – színkép, miden pixel alapszíne a saját textúrájából elővarázsolva mindenféle fényhatás nélkül
2. normal map – normálisok, minden képpont síkjának állása van tárolva a sík tengelyével, fényvisszaverődések számolásához és bumpokhoz elengedhetetlen.
3. depth map – mélységi térkép, a színátmenetek az egyes felületek monitor síkjához képest mért befelé dőlés mértékét adják meg, ezzel térérzetet keltve.

Színtérkép

Mélysági térkép

Bump map

Második körben a fényintenzitások kerülnek kiszámolásra normal és depth map felhasználásával, majd az eredmény a színképre kerül.

Bump + mélység + fény

Bump + mélység + fény a színhez vegyítve

Végezetül a nagyon intenzív fények kerülnek a képre bloom szűrővel (elmosás jellegű hatás, az erős fény visszaverődését imitálja a levegőben lévő részecskékről), ezzel izzó (glow) hatást keltve.

Voila! HDR!

Videotömörítés és AA

A dinamikus vezérléssel és az elméletileg végtelen programhosszal, valamint az erőteljes vektorossággal (1-2-3-4 elem számolható egyszerre) és párhuzamossággal (16 futószalag) az NV40 tökéletes mátrixműveletek gyors és hatékony végrehajtásához, azaz tipikusan képfeldolgozási műveletekhez. Ilyen művelet például a videotömörítés.

Már az előző generációs videokártyák is képesek voltak a dekódolt filmfolyamot (stream) átirányítani a pixel futószalagokon mindenféle képminőségjavító szűrők alkalmazása érdekében (pl. zajmentesítése, élesítés, elmosás, de-interlace). Az NVIDIA a GeForce 6 esetében megfordította a folyamatot, és a kódolatlan forrást az erőteljes és videokódoláskor általában szunyókáló pixel shaderekre zúdította, hogy azok kisegítsék a CPU-t transzformációkkal és mátrixműveletekkel. MPEG 2-kódolás esetén az egész folyamat 60 százalékát a GPU végzi, amely természetesen képes MPEG-4-, WMV9- és DiVX-tömörítésre is.

Az MPEG-2-tömörítés több mint 60 %-át a GPU végzi

Antialiasing

Nagyon vártuk már az NVIDIA új antialiasing technikáját, hiszen az eddigi megoldások nem tudták felvenni a versenyt az ATI módszereivel. Az NV40 végre tud négyszeres Rotated Grid MultiSamplinget. A négyszeres azt jelenti, hogy négy mintapont (szubpixel) felhasználásával számolja ki egy képpont értékét (4 tap sampling). A Rotated Grid (elforgatott rács) az emberi látás hatékonyabb kicselezése miatt kell, ugyanis sokkal érzékenyebbek vagyunk a közel vízszintes és függőleges vonalak finomságára. A korábbi rendezett rácsos módoknál (Ordered Grid) ezek az irányok a rendezettség miatt kevesebb finomításban részesültek, most, az elforgatott ráccsal ezekbe az irányokba bekerült egy kis rendezetlenség, amely "megzavarja" szemünket.

A régi és új módszer

Centroid Sampling

Ez a fícsör az őszi Half Life 2-bemutató kapcsán bukkant fel, amikor a Valve programozói azt állították: nem lesz tökéletes antialiasing az NVIDIA-kártyákon. Később ez a probléma megoldódott, a Centroid Sampling elfelejtődött. De mi is ez egyáltalán? Az Multi Sampling AntiAliasing technikáknál minden képpont színéhez több szomszédos átlagát használják fel, melyek kicsivel ugyan, de eltolva helyezkednek el. Alakzatok szélén azonban megtörténhet, hogy olyan szomszédos pontokat is felhasználunk, melyek nem tartoznak hozzá az alakzathoz. Fénytérképek (Light map) használatánál ez zavaró világos vagy sötét peremet hozhat létre. A Centroid Sampling kiszűri ezt a hibát, mert csak olyan mintavételezési pontokat engedélyez, melyek az alakzathoz tartoznak. Az ATI R3xx sorozata már támogatja ezt a módszert.

Centroid Sampling: az alakzatból kilógó középső pont helyett az egyik szélsőt választja

További részletek

Vertex shader

A zöld elemek a régiek, van egy 32 bites lebegőpontos vektor egység (Vector Unit) a három térbeli koordinátához, egy hasonló egység skalárokhoz (Scalar Unit) és egy ciklusvezérlő (Branch Unit) visszacsatolással a számolóegységekhez. Újdonság a korábban tárgyalt vertex textúrázó egység (Vertex Texture Fetch).

Pixel Shader

Látható, hogy futószalagonként két shader egység (Shader Unit) van beépítve – ezt nevezi az NVIDIA szuperskalár felépítésnek –, de csak az első képes textúrát olvasni, tehát egy textúrázó van futószalagonként. Ez a megoldás hasznos, mert általában több számolási műveletre van szükség mint textúrázóra. Komolyabb fényhatások számolásánál több kört futnak az adatok a pixel shaderben, ezt a ciklusvezérlő (Branch Processor) irányítja. Első körben az első shader egység nem számol, hanem textúrából olvas, a második egység már számol. A következő körben újra lehetőség van egy textúra olvasásra az első shaderben, de igény szerint akár újabb számolásokat is végezhet. További rugalmasságot és gyorsulást biztosít a kettős kibocsátás (Dual Issue).

A régi módszer és az új

Egy pixel shader egység szintén négyelemű adatokkal (jellemzően három színadat és egy alfa-, átlátszóság érték) dolgozik. Az első hármat kezeli vektorként, az utolsót külön, szóval egyszerre két művelet (egy maximum 3 komponenses vektor és egy skalár) hajtható végre. Az első három komponensből nem kötelező mindet használni, de ilyenkor kihasználatlan marad a többi. Fények kiszámolásánál nagyon sok kételemű műveletre (korábban említett mélységi vagy színtérképek generálása) van szükség, ilyenkor a harmadik komponens lustálkodik. Ezt az üresjáratot próbálja eliminálni az új NV-hardver. Noha az NVIDIA tetszőleges csoportosíthatóságról beszél, a dokumentumokból az tűnik ki, hogy a második pixel shader egység nem 3:1 arányban van "felbontva", hanem 2:2-ben, így egyszerre két darab kéttényezős műveletet tud végrehajtani. Ezzel a módszerrel a korábbi 4 művelet (komponensenként egy) helyett akár 8 is végrehajtható pixelenként minden ciklusban. Ha egyáltalán nincs textúra-mintavételezés (pl. árnyékok számolásánál), akkor 16/2-esnek is nevezhető az NV40 architektúrája.

A pixel shader végén még van egy újdonság, mégpedig egy programozható köd egység a korábbi fix helyett, amivel rugalmasabb és élethűebb hatás érhető el.

Raszterizáló

Ez az egység végzi a shaderek utáni munkát, az antialiasingot, Z-tesztelést (csak akkor írja be a memóriába az új pixelértéket, ha az nem takarja el egy korábbi képpont), a színtesztelést és -keverést (részben átlátszó felületek összevonása), és innen kerül a kép a Frame Bufferbe. Egy crossbar kapcsolattal (Fragment Crossbar) van összekötve a shaderekkel. Ez annyit jelent, hogy ha egy árnyaló végzett a feladatával, azt jelzi a crossbar-kezelőnek és az szabad raszterművelet (ROP – Raster Operation) egységhez küldi az adatot, ha pedig nincs szabad egység, akkor várakoztat, esetleg eldönti, hogy a több várakozó adat közül melyik juthasson tovább. Az új chip durván háromszorosát kínálja az NV35 sebességének.

Az árnyékvilág: UltraShadow II

Az árnyékok helyes kiszámítása talán még összetettebb feladat, mint a fények megjelenítése. Minden objektumhoz fényforrásonként ki kell számolni az árnyékokat majd ezeket összeadni és ráfeszíteni a képre. UltraShadow II használatával négyszeres sebességet ígér az NVIDIA anélkül, hogy a programozó komolyabb optimalizálást végezne.

Az árnyékolási módszer nem igényel textúrákat, ezért árnyék számoláskor a futószalagok mindkét pixel shader egysége számolást végezhet, a chip mondhatni 16/2 üzemmódban működik, innen a négyszeres sebesség – ingyen. A technika hatásfoka még jobban növelhető, ha a programozó fényforrásonként úgynevezett mélységi korlátok (depth bounds) megadásával kizárja a fölösleges geometriai elemeket a számolásból.

A két szaggatott vonal a programozó által beállítható mélységi korlát, csak ezek között van számolás

A következő képeken látható, hogyan csökken a jelenet geometriai összetettsége UltraShadow II használatával. Természetesen a képek a technika úttörőjéből, a Doom III-ból származnak.

Komplexitás UltraShadow II nélkül...

... és UltraShadow II használatával

A kártya és teljesítménye

A képeken látható, hogy a kártyákon két molex-csatlakozó van, míg másik oldalán két DVI-kimenet, plusz egy S-Video. A kártya legalább olyan hosszú, mint elődei, de szerencsére csak egy foglalatot tölt ki a hűtőrendszere, ami állítólag nem is túl hangos (e két állításnak részben ellentmondanak a képek és információk az első konkrét kártyákról). A nyák hátoldalán nincsenek memóriamodulok. Ami viszont elgondolkodtató:

Részlet a "hogyan teszteljünk GeForce 6800-at" tanácsadóból

Ez már ütős, és a két molex-csatlakozót kéretik külön kábelre dugni, nem ám Y-elosztóra vagy egy kábelen lógó két csatlakozóra! Ekkora energiafelvétellel és ilyen nagy tranzisztorszámmal biztosan komoly hőt produkál a kártya, kíváncsian várjuk, mennyire lesz hatékony (és hangos) a hűtése.

Várható teljesítmény

Minthogy tesztkártyát egyelőre nem sikerült beszereznünk, az NVIDIA által közölt teljesítményadatokat közöljük – ezek, mondani sem kell, óvatosan kezelendőek. A gyártó szerint a lebegőpontos feldolgozás teljesítménye 4-8-szorosa, az árnyékok megjelenítésének sebessége 4-szerese, a vertexfeldolgozás teljesítménye 2-szerese, míg a frame buffer sávszélessége durván 2-szerese az NV38 megfelelő értékeinek.

Íme az NVIDIA saját mérései a következő tesztkonfiggal:

Véleményezés

Meg kell hagyni, az NVIDIA nagyon odatette magát, minden kritizált oldalon javítani tudtak: impozáns – teljesen 32 bites lebegőpontos – architektúrát hoztak létre, javítottak az antialiasing mintavételezési pontjain, vékonyodott a kártya és felvértezték megannyi új tulajdonsággal mint a Shader 3.0-támogatás vagy az UltraShadow II. Egyetlen árnyoldala a mérhetetlen fogyasztás lehet. Most már csak két kérdés maradt:

1. Milyen gyorsan fognak ezek az új tulajdonságok divatba jönni?
2. Mennyire lesz hatékony az új megoldás a régi programokban?

Az első kérdéssel kapcsolatban optimista választ lehet adni, mert az új 3.0-s modell mondhatni az előző 2.0-s egy szabadabb változata, hosszabb programkóddal és rugalmasabb programozási lehetőségekkel. Ha a programozók magas szintű shader programozási nyelvben (HLSL, OGSL vagy Cg) hozták létre programjaikat, elég újrafordítani azokat egy shader 3.0-t támogató fordítóval, és máris belekerült az új technika a programba. Az UltraShadow II működik programozói beavatkozás nélkül is, de jó kezekben még hatékonyabb lehet. A Doom III motorja már erőteljesen épít erre a technikára, és feltehetőleg elődjéhez hasonlóan sikeres lesz, szóval a jövőben több UltraShadow II-t kihasználó játékra számíthatunk.

A játékoktól elvonatkoztatva a dinamikus folyamatvezérléssel és kvázi végtelen programhosszal az új GPU még egy lépéssel közelebb került az általános CPU-khoz. Kaptunk egy izmos vektorfeldolgozó egységet és most már csak a programozókon áll, milyen feladatokra fogják kihasználni. A 2D-és 3D-képfeldolgozó alkalmazások már most építenek a shaderekre, és a videotömörítést is megoldották. Következő lépés akár a SETI-számolás is lehetne...

A második kérdésre az NVIDIA a következő táblázattal válaszol:

A táblázattal kapcsolatban felmerül egy újabb kérdés: ha a kártya 16 futószalagos, akkor miért "csak" kétszer gyorsabb a hagyományos játékokban? Hagyományos alatt a mai, főként DirectX 7-es funkciókat használó játékokat értjük, melyek csak kiegészítőként használnak DirectX 8-9-es hatásokat. Feltehetőleg, az ATI R3xx-es sorozathoz hasonlóan az NV40 is szakított a hagyományos, fixen bedrótozott DirectX 7 utasításkészlettel, és ezeket is shaderek segítségével hajtja végre – emulálja. Ez az első saját szintetikus és játéktesztjeinkből kiderül, hamarosan...

rudi

A további tájékozodáshoz néhány teszt angol nyelven:

• Beyond3D
• ExtremeTech
• FiringSquad
• Guru3D
• [H]ard|OCP
• Tech Report
• Tom's Hardware