LMA II, nFiniteFX II, DirectX 8.1
NV25, azaz a GeForce4 Ti felépítése
NV17, azaz a GeForce4 MX felépítése
Shaderek
A GeForce4 Ti-ben már két Vertex végrehajtó egység (pipeline) kapott helyet, szemben a GeForce3 egyetlen pipeline-jával. Ennyiben az NV25 és az XBoxban található XGPU, kódnevén NV2A chip rokonok (sőt, az NV25 alapvetően az NV2A asztali PC-s "implementációja"). A pipeline-okat is finomították, így az egyes utasítások késleltetése csökkent. Összességében ez annyit jelent, hogy a dupla pipeline, a magasabb órajel és a finomhangolás durván háromszoros Vertex-számítási kapacitást tesz lehetővé a GeForce3-hoz képest. Hogy mire lehet mindezt kihasználni? Az nVidia szerint FarkasEmberek tökéletes animálásához... mi azért reméljük, hogy ennél kevésbé öncélúbb, kreatívabb felhasználási területek is felbukkannak majd... :)).
Drótváz, 100.000 poligon - Skeleton
A végeredmény
A GeForce4 Pixel shaderei is fejlődtek, és immáron a ps1.1 (Pixel Shaders 1.1) specifikáció mellett a ps1.2 és ps1.3 specifikációknak is megfelelnek. Az ATi itt egyébként még mindig egy lépéssel előrébb tart, hiszen a Radeon 8500-as ps1.4 kompatibilis. Akit a konkrét új utasítások érdekelnek, a Tom's Hardware-en megtalálják listát, bár feltesszük, hogy ők amúgy sem a prohardverről értesülnek a programozási részletekről...
Már a diagramokból is láthattuk, hogy a GeForce4 Ti és MX itt igencsak különbözik. Nemes egyszerűséggel úgy is mondhatjuk, hogy míg a GeForce4 Ti előrelépés a GeForce3-hoz képest a programozható T&L (Pixel és Vertex shaderek) tekintetében, addig a GeForce4 MX egyértelműen hátralépés, ugyanis nem rendelkezik teljeskörű DirectX 8.0-ás (még csak nem is DirectX 8.1-es!!) funkciókkal! Beigazolódott tehát a jóslat, miszerint a GeForce3 Ti200-as kártyák sok szempontból "jobbak" lesznek az őket potenciálisan leváltó GeForce4 MX-eknél.
Lightspeed Memory Architecture II
A Lightspeed Memory Architecture II (LMA II) a GeForce3-ban is megismert LMA továbbfejlesztett változata (Mostanra már biztos unalmas, de tény, hogy a GeForce4 Ti alapvetően nem más, mint a GeForce3 továbbfejlesztett változata, így kézenfekvő, hogy az architektúrát képező alegységek is külön-külön javultak, és ezek összessége az, ami megkülönbözteti a GeForce4-et a GeForce3-tól). A négyszegmensű crossbar vezérlő maradt, ami annyit jelent, hogy a 256 bit széles adatbusszal illesztett memóriát 64, 128 és 256 bites blokkokban tudja elérni a chip, attól függően, hogy az adat, amit írni/olvasni akar, milyen nagy (a teljességhez hozzátartozik, hogy a videokártyák 256 bitje igazából 2 x 128 bitként áll elő, és így a crossbar vezérlő is igazából a 2 x 32, 2 x 64 és a 2 x 128 méretű blokkokra vonatkozik). A crossbar megoldás egyben persze azt is jelenti, hogy ha például csak 64 bit blokknagyságú adatokkal dolgozik a chip, akkor a 256 bit széles memóriabusz maradék 192 bitjét még fel tudja használni további műveletekre, így még egy 64 bites és egy 128 bites "adatfolyam" is befér az előbbi mellé. Ez kimondottan intelligens megoldás egy grafikus vezérlőnél, mégpedig azért, mert az adatok nagysága változó, és a sávszélességet így lehet a legjobban kihasználni.
A GeForce4 Ti és a GeForce4 MX crossbar memóriavezérlője
A GeForce4 MX esetében az LMA II sajnos nem pont ugyanazt jelenti, mint a Ti-nél, ugyanis a négyszegmenses vezérlőt az MX-nél kétszegmensesre redukálták, tehát az adatokat 256, vagy 128 bites blokkokban tudja "csak" elérni. A GeForce2 MX-hez képest ez még így is jelentős előrelépés, ott ugyanis semmiféle LMA és crossbar vezérlés nem szerepelt.
Az LMA II vezérlő ugyanazokat az elemeket tartalmazza, amiket már a GeForce3-nál megszokhattunk, de az egyes elemek több/gyorsabb/nagyobb cache-sel vannak ellátva, jobban vannak szervezve, mint elődjük és persze összességében ez magasabb teljesítményt eredményez. Az egyes LMA (II) építőelemek, a teljesség igénye nélkül:
- Z-Occlusion Culling (népszerűbb, ám nem teljesen helyes nevén HSR, azaz Hidden Surface Removal)
- Lossless Z-Buffer Compression
- Vertex Cache
- Primitive Cache
- Dual Texture Caches
- Pixel Cache
- Auto Pre-charge
- Fast Z-Clear
Z-Correct Bump Mapping
A Z-Correct Bump Mapping egy olyan eljárás, aminek segítségével a különböző felületekre alkalmazott "bump map"-ek találkozásánál megszűnik a korábban megszokott textúrahiba.
A cikk még nem ért véget, kérlek, lapozz!
