:

Szerző: Tessier

2001. október 29. 20:14

Negyedik robbanás

Ugyan egy kevés víz lefolyt már a Dunán, mióta az NVIDIA kiadta Detonator meghajtóinak négyes változatát, azért vizsgálódni sosem késő (na meg jó munkához idő kell). A Magyarországon elérhető két leggyorsabb kártya társaságában indultunk neki tehát, hogy kiderítsük, mit is ér az új verzió.

Jelen cikkünk egy picit talán rendhagyó lesz, ugyanis nem törekszem a GeForce3 teljes bemutatására -- hiszen nagyon sok mindenről már szó esett korábban:

Most a főszerep a Detonator4 meghajtóé, a vizsgálódásban még szerepet kap az MSI GeForce3 chipes kártyája és egy Leadtek GeForce2 Ultra. Mielőtt azonban szemügyre vennénk, hogy mennyivel nyújt többet az új sorozatú driver, engedjétek meg, hogy egy pár szót szóljak a kártyákról, és a kissé elhanyagolt "anisotropic filtering"-ről.

MSI GeForce3

A kártya még a csúcsmodellek között is a felső kategóriát testesíti meg: a monitorcsatlakozón kívül tv-kimenetet és videobemenetet is találunk a rajta. Utóbbi megfelelő használhatóságáról is gondoskodtak az MSI-nél, a kártya dobozában ugyanis ott lapul az Ulead VideoStudio szoftverének Basic SE változata. Ami ezen kívül talán meglepő lehet, hogy a tesztkártyán (szemben a kiskereskedelmi forgalomban kapható változattal) az Elite memóriamodulokra nem került hűtés -- ennek ellenére semmiféle stabilitási problémával nem találkoztam.

Leadtek GeForce2 Ultra

Nem lenne fair az új driverek által nyújtott plusz teljesítményt csak a legújabb termékkel vizsgálni, arra is kíváncsi voltam, hogy az NVIDIA szoftverfejlesztői ki tudtak-e préselni némi többletteljesítményt a már igencsak jól ismert GF2 architektúrából.

A tv-kimenetről csak annyit, hogy szemre megfelelő minőséget produkáltak, bár az is igaz, hogy ebből a szempontból túl nagy különbséget eddig nem láttam a videokártyák között.

[oldal:Tesztkörnyezet]

A teszt során használt konfiguráció:

Alaplap Abit KT7A-Raid
Processzor AMD Athlon @1320MHz (110x12)
Videokártya

MSI StarForce 822 GeForce3 (driver 12.60 és 21.81)

Leadtek WinFast GeForce2 Ultra (driver 12.60 és 21.81)

Memória 256 mbyte CAS2 @110 MHz
Hangkártya SB Live! Value
Operációs rendszer Windows ME

A mérések a következő szoftverekkel és beállításokkal készültek (a VSync minden esetben ki volt kapcsolva):

3DMark2000 v1.1 Alapértelmezett
3DMark2001 32 bit esetén textúratömörítés, 32 bites Z buffer
VillageMark 1.19 Trilinear filtering, T&L
Z: Steel Soldiers 1.01 Anti Aliasing kivételvel minden bekapcsolva, 16 biten 16 bites textúrák, 32 biten 32 bitesek
Mercedes Benz Truck Racing 1.09 a 24 bites textúrák kivételével minden opció bekapcsolva
F1 Racing Championship 1.00.004 Anisotropic Filtering kikapcsolva, 16 biten 16 bites textúrák tömörítés nélkül, 32 biten 32 bites tömörített textúrák
Evolva Build944 Alapértelmezett
No One Lives Forever 1.003 Minden lehetséges opció bekapcsolva
MDK2 Maximális textúraminőség, T&L, Bilinear Filtering
Quake3 1.17 Minden maximumon, 16 bit esetén 16 bites textúrák, 32 bit esetén 32 bitesek, textúratömörítés bekapcsolva
Serious Sam 10000.2 Alapértelmezett "Quality" beállítások
DroneZMark GeForce3 Max, illetve GeForce2 Max beállítások

Most pedig végre rátérhetünk a már emlegetett textúraszűrésre.

[oldal:Textúraszűrési eljárások -- a háttér]

A modelleket alkotó háromszögek minden egyes csúcspontjához tartozik két-két textúra-koordináta, így egyértelműen meghatározott, hogy a háromszögre hogyan "feszül rá" a textúrát alkotó kép. A renderelés folyamán a háromszögek több transzformáción mennek keresztül, míg végül a képtérbe jutnak (ez az a tér, amit a képernyőn látunk), ahol is a tényleges textúrázás történik.

Amennyiben engedélyezett a mip-mapping, akkor az első lépés annak eldöntése, hogy az adott kimeneti pixelhez mely mip-map szintből olvassuk be a texeleket (a texel a textúra egy pixelét jelenti). A mip-map szintek a legrészletesebb textúra egyre csökkenő felbontású változatai (tehát például egy 1024x1024 pixeles textúrához tartozik 512x512-es, 256x256-os, stb mip-map). Ideális esetben minden képpixelhez egy texel tartozik, a mip-map szint választása is ennek megfelelően történik. Szemléletesen: ha a textúrakoordináták u és v, a képkoordináták pedig x és y (és az egyszerűség kedvéért a textúra nincs elforgatva), akkor az u/x és a v/y hányadosok megmutatják, hogy a képernyőn egy pixelnyi elmozdulás x vagy y irányban a textúrán hány texelnyi elmozduláshoz vezet. Értelemszerűen ha ez az érték egy (vagy annál kisebb), akkor a legrészletesebb (0-ik) szintről olvassuk be a texeleket, ha kettő körül van, akkor az első szintről, ha három, akkor a másodikról, és így tovább. Az, hogy a mip-map szintek közötti váltás pontosan a hányados mely értékénél történik, chipről-chipre változik, illetve a "MipMap LodBias" állítgatásával (a driverben) a felhasználó is befolyásolhatja. Talán van, akinek feltűnt, hogy az u/x és v/y hányados egymástól igencsak eltérő értékeket is felvehet, itt felmerül a kérdés, hogy melyik érték alapján történjen a választás. Ma gyakorlatilag az összes kártya a két szám közül a nagyobbat választja, azaz mindig a rosszabb felbontású mip-map szintről olvas be texeleket. Az egyetlen kivétel az S3 Savage sorozat, ami a két érték átlagával számol, ennek is köszönhető az igen szép textúrázás (és a néhol fellépő aliasing hatás).

A textúrázás maga oly módon történik, hogy minden egyes, a képernyőn megtalálható háromszögponthoz az eddig elvégzett tértranszformációk inverzének elvégzésével megkeressük az ahhoz a pixelhez tartozó textúrakoordinátát. A visszatranszformálás után azonban a legritkább esetben kapunk egy tényleges texelkoordinátát, a legtöbb esetben az adódó eredmény a texelek "közé" esik.

"Point Sampling" használatánál a kimeneti pixel a számított koordinátához legközelebbi texel értékét kapja meg. Előnye, hogy csak egy texel beolvasását igényli, hátránya, hogy mozgás közben igen csúnya aliasing hatások lépnek fel ("zizegnek" a textúrák).

"Bilinear Filtering" használatakor a kapott koordináta körül elhelyezkedő négy texel súlyozott átlaga adja meg a kimenet értékét, a súlyozás a texelektől levő távolságnak megfelelően történik. Egy kimeneti pixel előállításához négy texelre van szükség.

A "Trilinear Filtering" az előző módszer azon gyengéjén hivatott segíteni, hogy a mip-map szintek váltása a képen igen jól látható egy határozott vonal képében. A cél eléréséhez két mip-map szinten történik bilinear filtering, majd ezek eredményét átlagolja a fentebb említett hányadosokkal súlyozva. A szükséges texelek száma éppen ezért duplája az előzőnek, azaz 8.

A legtökéletesebb megoldás az "Anisotropic filtering". Használatakor az u/x és v/y hányadosok közül a kisebbik határozza meg a használt mip-map szintet (tehát a részletesebb textúrából olvasunk), de a texeleket nem négy pixelnyi négyzet alakú területről olvassuk be, hanem az u/x és v/y hányadosok hányadosa által meghatározott oldalarányú téglalapról (tehát ha például u/x=1, v/y=8, akkor a legrészletesebb textúrából olvasunk, egy 1:8 oldalarányú téglalapról). Hogy ténylegesen hány texelt tud a szűréshez egy chip felhasználni (ugye egy 1:8 oldalarányú téglalap lehet 1x8 texeles, de akár 2x16-os, vagy 4x32-es is), azaz hogy hány tapes a szűrés, az architektúrától függ. A GeForce2, Kyro chipek 16, a GeForce3 64, míg a Radeon akár 128 texel felhasználására is képes (ugyanakkor a Radeon nem tudja kombinálni a trilinear filteringgel az anisotropicot, míg a többiek igen, más kérdés, hogy ez mennyire látható).

[oldal:Textúraszűrési eljárások -- képminőség]

Az alábbi képek a GeForce3 megoldását szemléltetik, kétszeres nagyításban (a nagyítás során nem használtam szűrést):

Trilinear Filtering

16 Tap Anisotropic

32 Tap Anisotropic

64 Tap Anisotropic

Azt hiszem, a képek magukért beszélnek.

[oldal:Textúraszűrési eljárások -- sebesség]

Hogy ezirányú vizsgálódásunk teljes legyen, azért nézzük meg, mekkora sebességvesztéssel jár a minőség javulása. Ezeket a méréseket nyilvánvaló okból csak a GeForce3-on végeztem el, de mindkét vizsgált driverrel. A mérések során az 1024x768x32 és 1600x1200x32 felbontásokat használtam, D3D alatt a Z: Steel Soldiers és az F1 Racing Championship, míg OpenGL alatt a Quake3 és a Serious Sam volt segítségemre.

Sajnos az összes eredmény nem fért el (olvashatóan) egyetlen diagramban, de a lényeg így is látható: ha valakinek túl gyors a kártya, akkor könnyedén felezheti a sebességet a 64 mintás szűrés bekapcsolásával. Az F1 Racing Championship TC és nTC oszlopai a be/kikapcsolt textúratömörítéssel végzett mérések eredményeit mutatják, a chip inkább tűnik fill rate, mintsem memória-sávszélesség limitáltnak. F1RC alatt a Detonator4 meghajtó előnye igencsak látványos, ami nem mondható el a Z-ről (erre a megfelelő oldalon még visszatérek).

Az új driver előnyei itt megkérdőjelezhetetlenek: mindkét program mindkét felbontásban sokkal gyorsabban teljesít.

[oldal:Élsimítás]

Bár Ytse a GF3 által használt MultiSampling módszert már elég alaposan kivesézte, azért a teljesség kedvéért nézzük meg, mennyiben befolyásolja a Quake3 sebességét az újabb meghajtó (a D3 a Detonator3, a D4 a Detonator4 jelölése, míg a 2X, Q, 4X rendre a 2X, Quincinux és 4X FSAA beállításokat rövidíti).

A javulás -- ha nem is döbbenetes -- azért minden felbontásban jól látható.

Bár az NVIDIA által terjesztett gyorsulás itt sem tapasztalható, azért a 4X FSAA esetén 1280x1024-ben mérhető 36%-os nyereség igencsak figyelemre méltó.

Amit még a GF3 által alkalmazott MultiSampling módszer kapcsán fontos megjegyezni, hogy működési elvéből adódóan a textúrázás minőségét nem javítja (ellenben az eddig használt SuperSampling megoldás egy eredetileg Bilinear Filteringgel renderelt képből a 16 mintás Anisotropic Filtering minőségét hozza ki), így ha ugyanazt a minőséget szeretnénk elérni, mint amit GF2-n, Radeonon és Kyrón láthatunk, akkor be kell kapcsolni az Anisotropic szűrést.

[oldal:3DMark2000]

Áttérve a megszokott tesztprogramokra kezdjük vizsgálatainkat a szintetikus szoftverekkel, azokból is a MadOnion termékeivel.

Őszintén meg lettem volna lepődve, ha az eddig is 3DMarkra optimalizált driverekből ki tudtak volna csikarni jelentős többletteljesítményt, de mint az látható, ez -- legalábbis 16 biten -- nem is sikerült.

Növelve a színmélységet a gyorsulás már számottevő, főleg a GeForce3 esetében.

[oldal:3DMark2001]

Az egyetlen program, amelyben az NVIDIA által emlegetett gyorsulás megfigyelhető, bár itt is csak a Vertex és Pixel Shadereket felvonultató Nature tesztben. Érdekes volt, hogy míg a 12.60-as driver esetén a szoftveres Vertex Shader számottevően gyorsabb, mint hardveres társa, addig a 21.81-es verziónál a viszonyok megfordulnak.

GeForce3-nál a méréseket mind Hardware T&L, mind pedig Pure Hardware módban elvégeztem.

Míg GeForce2 esetén nincs javulás, addig a GeForce3 egészen megdöbbentő mértékben gyorsul már 16 biten is. Ugyanakkor a Pure Hardware mód sebességbeli fölénye megkérdőjelezhető.

Bár az NVIDIA állítása szerint a memóriavezérlő kihasználtságán javít sokat az új meghajtó, mégsem tapasztaltam, hogy 32 biten sokkal többet gyorsult volna, mint 16-on.

[oldal:VillageMark]

A PowerVR által készített benchmark a valós alkalmazásokban elérhető fill rate tesztelésére a legalkalmasabb szoftver. Köszönhetően a hatalmas mennyiségű, egymást fedő objektumnak, a renderelés hatásfokának javítására bevezetett trükkök (Z buffer tömörítés, Occlusion Culling) demonstrálására is kiváló eszköz.

16 biten mind a kártyák, mind a driverek közti különbségek elhanyagolhatók, a pixelfeldolgozási sebesség a limitáló tényező.

A színmélységet növelve alapvetően változik meg a helyzet. Tekintve, hogy a GeForce3 egy menetben négy textúra feldolgozására képes, míg a GeForce2 csak kettőre, a két kártya közti különbségek rögtön érthetővé válnak (a program három textúra réteget használ). A driververziók közti különbséget szemlélve rögtön az NVIDIA magyarázata juthat eszünkbe: tényleg voltak tartalékok a GeForce3 memóriavezérlőjében.

[oldal:Z: Steel Soldiers]

Áttérve a valós alkalmazásokra kezdjük a felhozatal fekete bárányával, a Z: Steel Soldiersszel.

Egy oka van, amiért az NVIDIA nem érdemel elmarasztalást: az összes videokártyán megfigyelhető, hogy a program sokkal rosszabbul teljesít DirectX 8-as meghajtókat használva (annak ellenére, hogy DX8-t igényel). A két chipgeneráció között viszont nincs sebeségbeli eltérés.

GeForce2-őt használva a driverek okozta különbségek hamar eltűnnek, a memória-sávszélesség válik korlátozó tényezővé. Ez a tendencia a GeForce3 esetében is megfigyelhető, de mértéke sokkal kisebb, és a chip sokkal jobban teljesít, mint egy generációval öregebb társa.

[oldal:Mercedes Benz Truck Racing]

Nem is olyan régen még annak örülhettünk, hogy az MBTR eredmények átlépik a bűvös 40 FPS-t 1024x768-ban. Azóta -- többek között a továbbra sem elhanyagolható CPU számítási teljesítmény rohamos növekedésének -- már a 100 FPS-es határt ostromló rendszereket állíthatunk össze viszonylag jó áron (itt most nem a tesztelt videokártyákra gondolok):

Ezen a színmélységen a program szinte az összes felbontásban processzorlimitált, ezeket a videokártyákat nem nagyon izzasztja meg. A Detonator4 ellenben -- még ha csak hangyányit is -- képes javítani eredményeinken.

A színmélység növelésével a GeForce2 sávszélesség-limitáltsága nyilvánvaló, ezen semmiféle driver nem tud segíteni, ugyanakkor az is igaz, hogy a GeForce3 esetén is csak alacsonyabb felbontásokban tűnik fel a különbség, amit az új driver okoz.

[oldal:F1 Racing Championship]

Az UbiSoft Forma1-es programja továbbra is a legszebb (na jó, az F1 2001 szebb) a piacon, és engine-je is a legfejlettebb: támogatja többek között T&L-t és textúratömörítést. A mérések a legmegterhelőbb pályán, Monacóban történtek 22 versenyző részvételével.

A Detonator4 előnye mindkét kártyán figyelemre méltó, főleg alacsonyabb felbontásban.

32 bitre váltva mind a GeForce3, mind pedig a Detonator4 előnye egyértelmű, utóbbi főleg az újabb kártya esetében számottevő, de azért a GeForce2-tulajdonosok is örülhetnek a többletnek.

A program ugyancsak tökéletes szemléltetése az NVIDIA kártyákban "helyet kapott" textúratömörítési hibának: sokan hajlamosak ezt egy kézlegyintésel elintézni, mondván úgyis csak a Quake3 egén feltűnő. Ennek cáfolatára két kép (az aszfaltot figyeljétek, a képek mérete 400K):

  • GeForce3
  • KyroII

    [oldal:Evolva]

    Az Evolva azon kevés program közé tartozik, melyek képesek BumpMapping használatára (legalábbis T&L-t használó kártyákkal), az itt látható eredmények is ennek engedélyezésével készültek.

    A driververziók közötti különbségek elhanyagolhatók, és érdekes módon inkább a GeForce3-nál valamivel jobban teljesítő GeForce2 esetén figyelhetők meg.

    Itt a kártyák között a papírforma érvényesül, a Detonator4 használata nem jár kézzelfogható előnyökkel.

    [oldal:No One Lives Forever]

    Hangulata mellett tesztelési szempontból is érdekes program, hiszen az egyre inkább terjedő -- 2.5-ös verziójú -- LithTech engine szolgál motorjául. Ennek megfelelően T&L támogatás nincs, de videokártyánkat rendesen megizzasztja.

    A 16 és 32 bites eredmények nem összehasonlíthatók, mert utóbbinál engedélyezve voltak a tükröződések.

    Míg GeForce2 esetén az újabb driverek jelentős teljesítmánynövekedést okoznak, addig GeForce3-at használva inkább csökkenés tapasztalható.

    Színmélységet váltva a GeForce2 továbbra is sokat profitál a Detonator4 használatából, és itt már ugyanez mondható el a GeForce3-ról is (ami mellesleg igen alaposan lehagyja elődjét).

    [oldal:MDK2]

    OpenGL által uralt vizekre evezve következzenek a lassan-lassan kiöregedő (pontosabban szólva túlzottan processzorlimitálttá váló) MDK2 eredmények.

    Az újabb driver csak a GeForce3-at segíti jobb teljesítmény eléréséhez, azonban a GF2-nek így sem kell szégyenkeznie, állja a sarat...

    A Detonator4 előnye a GeForce3 - 32 bit páros esetén igen jól érzékelhető, míg a GeForce2 újfent immunis a driverek verziójára.

    [oldal:Quake3]

    Carmack bácsi lassan ipari szabvánnyá váló programja természetesen nem maradhatott ki.

    A GeForce2 kicsit, a GeForce3 annál többet profitál a Detonator4-ben bevezettett újításokból.

    Az eredményeket nézegetve akaratlanul is felmerül az emberben a kicsit tán rosszindulatú megjegyzés: azért az NVIDIA szoftvereseinek szeme előtt még mindig a leggyakrabban használt benchmarkok lebegnek. De a tényen, miszerint mindkét kártya meglehetősen sokat gyorsul, ez mit sem változtat.

    [oldal:Serious Sam]

    Számomra az egyik legkedvesebb tesztprogram, ami két dolognak is köszönhető: egyrészt a fejlesztők vették a fáradságot, és az összes piacon lévő chipre megfelelően optimalizálták a motort, másrészt pedig bizonyították: megfelelő minőségű és mennyiségű textúrával a vizuális hatás legalább oly mértékben javítható, mint többezer háromszögből álló szereplőkkel (félreértések elkerülése végett: az is fontos, csak a fejlesztők hajlamosak a megfelelő textúrázás felett elsiklani).

    A Detonator4 csak a GF3 esetében képes gyorsítani, de ennek mértéke ott sem túl nagy.

    A driverek okozta különbség nem változott jelentősen a színmélység váltásával, csak a GeFroce3 tett szert behozhatatlan előnyre (ami persze megintcsak a memóriavezérlő és az egymenetes quad-texturing számlájára írható).

    [oldal:DroneZMark]

    Ami a Serious Samnak számomra egyik pozitívuma, az a Droneznak legnagyobb hátránya: a motor olyan szinten a GeForce kártyákra optimalizált, hogy pl. bumpmapping használatára más gyártó termékeivel nincs is lehetőség.

    Mindkét kártyához a lehető legjobb képminőséget biztosító beállításokat használtam, ami a GF3 esetében a Vertex és Pixel Shaderek hardveres számítását jelenti, míg a GF2 esetében a transzformációt végző algoritmusok jó részét a CPU számítja, viszont a bumpmapping itt is be volt kapcsolva.

    Teljesen mindegy, melyik chipet vizsgáljuk, a Detonator4 használata nem jelent gyorsulást. A legmagasabb felbontáshoz érve a GeForce3 előnye is semmivé lesz: itt már a GF2 esetén sem a processzor, hanem a fill rate korlátozza az elérhető sebeséget.

    A drivereknek itt sem sok szerep jut, ami viszont érdekes, hogy a GF2 hamarabb megközelíti utódját: itt már a GeForce3 is a sávszélesség okozta korlátokba ütközik.

    [oldal:Konklúzió]

    Akiknek már volt szerencséjük(?) általam elkövetett videokártyateszthez, két programot hiányolhatnak: az AquaMarkot és a Dagoth Moor Zoological Gardent (DMZG).

    A hiány oka mindkét esetben rendkívül egyszerű, és a drivereknek köszönhető. Az Aquamark "csak" a 21.81-es verzióval nem futott (nem sikerült elég videomemóriát találnia a 64 megás kártyákon), míg a DMZG semmilyen újabb NVIDIA meghajtóval sem működik (a 6.x sorozattal még ment), ami elég furcsa, lévén egy GeForce technológiai demóról van szó (pedig igazán szép, egyszer érdemes megnézni).

    Ezenkívül nem szóltam az egyes programokban (pl. 3DMark 2001 Dragothic teszt) tapasztalható hibákról -- ezeket az újabb verziójú Detonator4-ben az NVIDIA javította (sőt, tesztjeim szerint a teljesítmény is javult valamelyest).

    Végkövetkeztetésünk nem lehet kétséges: hihetetlen, amit a cég programozói csoportja művel (azon mondjuk el lehet merengeni, hogy mennyire tudatos az új kártyák első drivereinek alacsonyabb teljesítménye). Természetesen -- mint minden meghajtóval -- kisebb problémák adódhatnak a driverek előtt megjelent programokkal, de ez tényleg elhanyagolható.

    Ami a GeForce3-at illeti, előnye tovább nőtt a régi generációval szemben, ugyanakkor olyan programot még mindig nem tudok mutatni, ami grafikailag nagyságrendekkel szebb lenne ezt a chipet használva (a DroneZ sem ilyen, és nagy valószínűség szerint a lassan befutó Aquanox -- ebből készült az AquaMark -- sem fog áttörést jelenteni ezen a téren). Minőségi szempontból tehát továbbra is az Anti Aliasing tényleges használhatósága és az Anisotropic Filtering jelenti az előnyt (bár azt megjegyezném, hogy Quincinux AA és Anisotropic Filtering együttes használata 1024x768x32 felbontásban azért már vezethet lassulásokhoz).

    A tesztben használt MSI StarForce 822 és Leadtek WinFast GeForce2 Ultra videokártyákat a Kelly-Tech Kft. bocsátotta rendelkezésünkre, amiért ezúton mondunk köszönetet.

    Szólj hozzá a fórumban!

Milyen technológiai és munkaerőpiaci hatások érhetik a backendes szakmát? Május 8-án végre elindul az idei kraftie! meetup-sorozat is (helyszíni vagy online részvétellel).

a címlapról

Hirdetés

Security témákkal folyatódik az AWS hazai online meetup-sorozata!

2024. április 26. 12:14

A sorozat május 28-i, harmadik állomásán az AWS-ben biztonsági megoldásait vesszük nagyító alá. Átnézzük a teljes AWS security portfóliót a konténerbiztonságtól a gépi tanulásos alkalmazások védelmén át, egészen az incidenskezelésig.