Egy KYRO II chipes videokártya: Videologic Vivid!XS

A memória nem véletlenül futott így, sajnos az egyik modulom egy régebbi, PC100-as modul, mely visszafogja a másik PC133-as CAS2-est; de számomra fontosabb a memória mennyisége, mint a 10%-al nagyobb sebesség. Nem ez lesz az egyetlen korlátozó tényező, mint látni fogjuk, de jól reprezentálja a fenti konfiguráció, mit várhatunk egy jelenleg ma már low-endnek tekinthető géptől.

A tesztelésben részt vett összhasonlítási alapként a KYRO I-es, 115MHz-es Videologic Vivid! kártya is, valamint az Abit Siluro MX400 64MB-os kártyája. A Silurót az alap 200/166 MHz (core/memória) órajelen teszteltem.

[oldal:PowerVR3 aka KYRO]

Ugyan Tessier igen kitűnő cikkében tökéletesen leírta a PowerVR technológia lényegét, pár szóban azért összefoglalnám, miről is szólnának a fenti kifejezések.

A KYRO chipek ugynevezett tile-okra, 32x16 pixeles részekre bontják a renderelt képet, s egy-egy ilyen tile feldolgozása külön-külön történik meg. A tile kis méretéből adódik, hogy ezek feldogozása teljes mértékben a chipen belül zajlik le, ezzel is csökkentve a sávszélességigényt. A deferred rendering szintén teljesítményt spórol, a renderelésre kerülő háromszögek, felületek ugyanis renderelés előtt sorbarendezésre kerülnek, eldöntve, mely háromszögek pixelei látszanak, s melyekéi nem. A chip csak a látható felületeket tölti ki, tehát a nem látható, feleslegesen többszörösen renderelésre kerülő pixelek problémája megszűnik. Ez a két technológia határozza meg főként a PowerVR által képviselt technikát, mely mint látni fogjuk, meglehetősen hatékonyan működik.

A sorbarendezéshez természetesen a hagyományos renderelési technikától eltérően -- mely a háromszögeket egymás után tölti ki -- itt meg kell várni, míg a teljes scene adatai a kártya rendelkezésére állnak, de ez nem jelent igazán problémát, a poligonok feldolgozási sebessége kellően nagy. A KYRO chip 32 db Z-műveletet képes egyetlen órajel alatt elvégezni. A szükséges adatokat a videokártya memóriájában helyezi el, melyekhez így gyorsabban fér hozzá.

Fentiek bemutatására a PowerVR több technológiai demót is készített, többek között az igen nagy átfedéssel, overdraw-val bíró VillageMark, és a speciális Fortune tesztprogramot.

A Fortune 52 kártyalapot animál, egyenként 2 átlátszó és egy normál textúrával, jelentősen átfedve egymást. Ez a speciális demó a hagyományos gyorsítóknak meglehetősen nagy falat. De, mint látható, a KYRO lazán megbírkózik vele, nézzük csak meg azt az elméleti Mpixel számlálót!

Constant Stencil-Buffer, Z-buffer

A KYRO által képviselt megoldás több előnnyel is jár: mivel egy-egy tile igen kis méretű, könnyen létre lehetett hozni a chipen belül belső buffereket, melyekben a szükséges adatok könnyedén elférnek, kitűnő kompatibilitást nyújtva (az előd Neon 250 lényegében ezek hiánya miatt bukott meg), ugyanakkor nem növelik lényegesen a tranzisztorok számát, sem az előállítási költséget. A játékok által használt, pontosan a láthatóság megállapítására szolgáló Z-buffer a KYRO chipen belül a színmélységtől függetlenül áll 16-24-32 bites módban rendelkezésre, választhatóan -- már amennyiben az adott alkalmazás erre lehetőséget ad. Ugyanez áll a stencil bufferre is, mely az árnyékok, tükrözödések leképezésében nyújt legtöbbször segítséget.

A 32 bites Z, vagy 24 bites Z és 4 bites stencil buffer 16 bites színmélység mellett is kiválasztható, pontosabb megjelenítést, korrektebb képet biztosítva, eltérően a ma használt legtöbb 3D-gyorsítókártya megoldásától, mely ragaszkodik a használt színmélységnek megfelelő Z-buffer mérethez.

Internal True Colour

A KYRO az Internal True Colour technológia segítségével a ma látható legszebb 16 bites képet biztosítja. A belső számítások 32 bites pontossággal zajlanak, s csak a végső, frame-bufferbe történő kiíráskor történik meg a 16 bitre konvertálás, mely így láthatóan szebb képet biztosít a többi kártyához képest. A fentiekből következik, hogy a kártya lényegében ugyanakkora mennyiségű számítást végez el 16 és 32 bites színmélység esetén: nincs is lényeges különbség a teljesítmények között, vagy ha van is, az csak nagyon magas, 1280x1024 vagy 1600x1200-as felbontásnál érzékelhető. Aki azt várja, hogy 16 biten jelentősen gyorsulni fog a kártya, csalódni fog, ugyanakkor a változatlan sebesség kitűnő képminőséggel ajándékoz meg. Ma már alapkövetelmény a 32 bites színmélység véleményem szerint, ugyanakkor a régebbi, csak 16 bites játékaink valóban szebbek lesznek a KYRO-n.

8-layer multitexturing

A KYRO chipek ugyan csak 2 pipeline-nal és egy-egy textúrázó egységgel rendelkeznek -- s egyéb paramétereik is igen szerények -- , mégis meglepő dologra képesek: akár 8 textúrát is fel tudnak húzni egyetlen felületre, nagyon minimális teljesítményveszteség árán. S noha a jelenlegi játékok nem nagyon profitálnak még ebből (kivétel talán a Serious Sam), de a jövőben kétségtelenül várható az egy felületre felhúzott textúrák mennyiségének növekedése. A chip ezt igen trükkösen oldja meg: egy úgynevezett loopback technikával az adott pipeline kimenetét képes visszaküldeni úgy a bemenetre, hogy nem szükséges az adatok újbóli feldogozása, sávszélességzabáló mozgatása, csupán egy újabb textúraréteg kiszámítása.

A technológia előnyeit szintén egy demóval szemléltette a PowerVR. A Temple Demo egyszerre öt réteg textúrát használ, s bizony a 115 MHz-es KYRO I is igen becsületes teljesítményre képes a nem is egy kategóriával drágább társaihoz viszonyítva. Ugyebár egy hagyományos, 2 vagy maximum 3 (pl. Radeon) textúrát egy órajel alatt feldolgozni képes gyorsító jelentősen lelassulhat, ha egy-egy pixellel legalább kétszer annyi ideig kell foglalkozni...

EMBM, DOT3 bump-mapping, textúratömörítés

A KYRO támogatja az egyre elterjedtebben használt felületi egyenetlenségeket szemléltető bump mapping technikákat. A Matrox által köztudatba berobbantott EMBM mellett a DirectX által definiált DOT3 és Embossed (1-2-3 rétegű) bump mappinget is támogatja, meglepően kellemes sebességgel (lásd előző pont).

A KYRO II textúratömörítést is támogat hardveresen, azonban sajnálatosan még mindig csak a DXT1-et, a többi DXT2-5 tömörített textúra kitömörítésre kerül a memóriába. OpenGL alatt is igénybe vehető a textúratömörítés a szabványos extensionök által.

FSAA

Az úgynevezett aliasing hatás csökkentésére már régóta kísérleteznek a gyártók az FSAA (Full-Scene Anti Aliasing) technológia hatékony implementálásával. A témával egy cikkünk igen behatóan foglalkozott, melyet melegen ajánlanék a kedves olvasónak, s mely megvilágítja, hogy az FSAA magyar fordításaként használt teljes képernyős élsimítás mint fogalom nem állja meg a helyét. Ugyan a technológia kellemes mellékhatása az alacsonyabb felbontásokon igen "lépcsőzetes" képet mutató felületi élek kisimítása, a lényege ettől eltérően mindenképpen a képminőség javítása lenne.

A KYRO egyszerű super-sampling FSAA technológiát használ, 2x-es vagy 4x-es módban. Legegyszerűbben ezt úgy lehetne megfogalmazni, hogy 4x FSAA esetén a 800x600-as felbontású képet a kártya úgy számolja, mintha 1600x1200-as felbontású kimenetre (4x-es, 2x2-es FSAA esetén) renderelné le. A frame-bufferbe történő kiírás előtt a képet "visszaátlagoljuk", lekicsinyítjük a cél, 800x600-as felbontásra. Ugye nem kell azt ecsetelni, mekkora az említett technológia sávszélesség és számításigénye egy hagyományos renderelő technológia esetén. De nem így a PowerVR esetén: az említett kicsi, 32x16-os tile-okkal való mahináció irtózatos előnyt nyújt a KYRO-nak. Hiszen sokkal könnyebb egy ilyen kis méretű adatmennyiséggel dolgozni akár 2x2-szeres méretben, mint egy egész 1600x1200-as képpel...

Szóval a KYRO FSAA implementálása annyira jól sikerült, hogy a 800x600-as, 4X FSAA mellett nyújtott teljesítmény lényegében megegyezik az 1600x1200-as felbontásban nyújtott teljesítménnyel, legalábbis az általam használt processzoron ez tapasztalható, ez pedig pusztán fill rate limitáltsági problémává degradálja a kérdést. Alacsony felbontáson kitűnő teljesítményt nyújt. Elmondható, hogy a 640x480-as felbontáson már kiválóan alkalmazható a KYRO 4x-es FSAA képessége, 800x600 és 1024x768-ban pedig a 2x-es FSAA is megfelelő teljesítményt nyújthat az adott játék típusától, és az elérni kívánt sebességtől függően. Régi játékainkat, melyek esetleg fix, alacsony felbontásban és 16 bites színmélységben hajlandóak csak futni, valóban "digitálisan felújított" formában láthatjuk viszont a KYRO segítségével. De felhozhatnám példának az egyik kedvencemet, az Operation Flashpoint:1985 című játékot is, mely tökéletesen játszható 1024x768x32 2x FSAA mellett, ugyanis processzor-limitált, nem a videokártya a szűk keresztmetszet, ráér FSAA-t számolgatni fölös idejében...

A fenti képen kívül készítettem még két darab .png kiterjesztésű képet, melyek meglehetősen nagy méretűek, de a veszteségmentes tömörítés segítségével kiválóan bemutatják, mire is jó az FSAA. A példaprogram a PowerVR3 SDK részeként letölthető D3DTree, és egy egyszerűbb fát ábrázol, leveleivel. Az FSAA nélüli kép ide kattintva, míg a 4x-es FSAA-val készített innen érhető el.

[oldal:Telepítés, 2D, képminőség]

Javasolt mindazonáltal frissen telepített rendszerbe installálni a kártyát, hiszen az ördög sosem alszik...

A telepítés lezajlása után Win98 SE alatt szépen be kell(ene) állítgatnunk egyesével az adott felbontáshoz és színmélységhez tartozó frissítési frekvenciákat, a telepítő ezt 1024x768-ig alapból 75 Hz-re lövi be. A nem éppen monitorkímélő és igen fárasztó manuális módszer helyett javasolt a Kyro Power Tools segédprogramocska használata, itt ezt pár kattintás segítségével, majd egy újraindítással megoldhatjuk.

Az említett segédprogram Windows 2000 alatt különösen jól jön, ugyanis a Vivid! és Vivid!XS itt ugyanolyan problémákkal küzd, mint más kártyák: ez a grafikus alkalmazások, D3D és OpenGL alatt "beállított frekvenciától függetlenül stabilan 60 Hz-en frissítő videokártya" esete. Nem igazán tudom, hogy ki a ludas ebben, de ha nem tévedek, több kártya is szenved ettől a problémától, így feltehetően nem csak a driverek írói a hibásak. A 2D-t, a desktop frissítését ez a gond nem érinti.

Szerencsére az említett segédprogrammal ez a probléma is áthidalható, bár ez nem fog piros pontot jelenteni a végső értékelésnél. Ígéretek szerint a következő driverfrissítés már megoldás hozhat.

A 2D sebességét, hogy őszínte legyek, nem mértem (megtette más :), mivel véleményem szerint a megcélzott vásárlóközönség nem annyira kényes a 2D sebességére, főleg, ha az csak tesztprogramokkal kimutatható különbségben nyilvánul meg. A való életben nem jelent semmilyen érezhető különbséget. Én legalábbis meg voltam elégedve a kártya ezen paramétereivel.

Ugyanígy meg voltam elégedve a nyújtott kép minőségével is. A színek teltek, az élesség kitűnő. A Vivid!XS-en lévő 350MHz-es RAMDAC egyeseknek ugyan kevésnek tűnik, de sokan hibásan ezt társítják az életlen képhez, pedig -- mint tudjuk -- ahhoz nagyon kevés köze van. Lényegében csupán a maximális elérhető képfrissítési frekvencia függ ettől a paramétertől, s bizony már a 270 MHz-es Vivid! is bőven megfelelő volt ezen a téren, legálábbis az általános 15-17"-os monitormérethez. A Vivid!XS 1024x768-ig 150, e felett 1280x960-ig 120, 1280x1024-ben 100, 1600x1200-ban 90 Hz-es képfrissítési frekvenciát biztosít maximálisan: csak bírja a monitorunk.

Visszatérve a képminőségre: az élesség magasabb felbontáson (értsd 1280x1024) sem változik láthatóan, s bár az általam használt Belinea 103040 17"-os monitor nem dokumentáltan 1600x1200-ban is képet ad, a 0,26-os képpontméret itt már nyilván nem elegendő eme, amúgy is igen objektív paraméter megítéléséhez.

Egy szó mint száz: az általam preferált 1024x768@100Hz-es felbontáson a kártya kitűnő minőségű képet szolgáltat, ugyanúgy, mint 800x600@120Hz alatt. Az összehasonlításként használt Abit Siluro MX400T 64MB-os kártya valamivel életlenebb volt, de a különbség szerintem csak nekem tűnhet fel, aki már 9 hónapja bámulja a Vivid! képét.

A frissítésen kívül találkoztam még egy igen bosszantó hibával, ez pedig bizonyos alkalmazások esetén jön elő mind a két KYRO kártyán, garantáltan meghajtóprogram-javítást igényelve. Van átmeneti megoldás erre is, de nagyon érdekes, hogy csak és kizárólag 32 bites színmélyégben jelentkezik az egyes alkalmazások ikonjainak hibás megjelenítése. Két alkamazásban tapasztaltam ezt: a StarOffice 5.2-ben, és a Paint Shop Próban, mint az a lenti képeken látható.

A problémára megoldás az asztal színmélységének 24 bitesre változtatása. Számomra kicsit érthetetlen, mi okozhat ilyen hibát, ami ráadásul az eddigi összes meghajtóprogramban megtalálható. A következőben ígéretek szerint javítva lesz ez is.

[oldal:3D, D3D, OpenGL]

A másik, igen fontos fül a 3D Optimisation kattintásra hallgat, itt lehet a KYRO meghajtóprogramját mindenféle csodálatos, és jól használható dolgokra rávenni D3D és OpenGL alatt külön-külön. Az adott alkalmazáshoz akár saját profilt is létrehozhatunk, egyéni beállítást biztosítva neki, függetlenül az általános beállításoktól.

Minden meghajtóprogram tartalmaz egy-egy gamestng.reg file-t, mely a telepítés során automatikusan lefut. Ebben, a ma már 46 Kbyte-os file-ban már több száz, a PowerVR által előre definiált és kipróbált játékbeállítást találunk, melyek a regisztrációs adatbázisban rögzülnek, s a meghajtóprogram folyamatosan ellenőrzi őket egy-egy program indításakor. Így többnyire az optimális eredményt kapjuk az adott játék futtatásakor. Ezeknek a beállításoknak a nagy része nem is érhető el a felhasználó számára még az említett 3D Optimisation fülön sem.

Tehát itt D3D alatt a következő beállítási lehetőségeink vannak:

Control Full-Scene Anti-aliasing
Ez alatt a szekció alatt az alkalmazás tudta nélkül kapcsolhatjuk ki-be a 2 vagy 4x-es FSAA használatát. Ha itt beállítjuk az FSAA használatát, a KYRO garantáltan FSAA-t fog használni, függetlenül a játék beállításaitól. 2x-es (1x2 vagy 2x1) FSAA esetén választhatunk, hogy horizontális vagy vertikális irányban szeretnénk az FSAA-t elérni.

Disable Waiting for Vertical Sync
Ez a jelölőnégyzet a vsync kikapcsolására szolgál, mely hsonlóan az FSAA-hoz, garantált eredményt ad, a játék, alkalmazás beállításától függetlenül ki lesz kapcsolva. Ez a kapcsoló oldalirányú mozgásoknál törést idézhet elő a képben, de a maximális képfrissítés a monitor frekvenciája által nem lesz korlátozva.

Defer Render Until Flip
Ez a kapcsoló arra utasítja a meghajtóprogramot, hogy minden esetben várja meg, amíg a teljes scene betöltésre kerül, s csak ezután kezdje el lerenderelni a képet. Növelheti a sebességet, s bizonyos esetekben hibásan megjelenő játékoknál megszüntetheti a problémát, de ugyanakkor okozhat is gondokat: ki kell próbálni. Én egy igen kellemes mellékhatását tapasztaltam: kicsit növelt teljesítmény mellett megszüntette a vsync kikapcsolása által keletkezett töredezettséget. Nem minden alkalmazás tűri meg ezt a kapcsolót, pl. a The Sting! demója csak kikapcsolva nyújt tökéletes képet.

Force Anisotropic Filtering
Ez a kapcsoló fixre állítja az anisotropic filter használatát, mely nagyban javítja a kép minőségét, főleg ami a mipmap átmeneteket illeti. Használata viszont igen jelentős teljesítménycsökkenéssel jár.

Force Texture Compression
Az előző ponthoz hasonlóan ez is fix beállítást jelent: amennyiben lehetőség van rá, mindenképpen használni fog a kártya textúratömörítést. Néhány esetben növelheti a sebességet, mivel a tömörített textúrák értelemszerűen kisebb sávszélességet fogyasztanak, viszont a textúra minőségétől függően ronthatja a kép minőségét.

Force Trilinear Texture Filtering
A kártya ezzel a kapcsolóval mindenképpen trilinear szűrést fog használni, függetlenül a játék beállításától. A bilinear filterhez képest csupán minimális, pár százalék a teljesítménykülönbség, így mindenképpen érdemes ezt a kapcsolót használni.

Force W Buffering
A Z-bufferhez hasonlóan az egyre elterjedtebben használt alternatív megoldás, a W bufferelés is a láthatóság megállapítását szolgálja, pontosabb eredményt biztosítva. Ezzel a kapcsolóval utasíthatjuk a kártyát a W bufferelés használatára a KYRO saját RHW (Reciprocal Homogenous W) számítási módszerével, pontosabb megjelenítést biztosítva, viszont néhány esetben különböző renderelési problémákat tapasztalhatunk. Javasolt kikapcsolva hagyni.

Enable Soft Edges on Cut-out Textures
Ez a kapcsoló azon textúrák éleit hivatott elsimítani, melyeknek csak egy része lett lerenderelve, s a sebességet sem befolyásolja, de szintén gondokat okozhat a renderelésben bizonyos esetekben.

Enable External Depth/Stencil Buffer
Ez az egyik olyan kapcsoló, amivel iszonyatosan lelassíthatjuk a kártyát, viszont 100%-os kompatibilitást kapunk érte. Van néhány játék, mely szeret közvetlenül hozzáférni a Z és stencil-bufferekhez, a frame-bufferhez. A KYRO viszont saját, belső Z buffert használ, mely a külső alkalmazások számára elérhetetlen, így a játék nem fog helyesen futni. A kapcsoló hatására a KYRO a videokártya memóriájában hoz létre Z és stencil-buffert, így viszont elveszik az az előny, mely a belső felépítésből adódik: minden műveletért ki kell nyúlni a videomemóriába. Nem kell mondanom, mekkora lassulást okoz mindez. Jómagam még nem találkoztam olyan esettel, amikor ennek a kapcsolónak a használatára lett volna szükség, de jó tudni, hogy van, a fejlesztők erre is gondoltak...

Ezek voltak a D3D lehetőségei, most következzenek az OpenGL alatti beállítások:

Control Full-Scene Anti-aliasing
A D3D-hez hasonlóan ez is az FSAA bekapcsolására szolgál. Minden körülmények között használni fogja a kártya az FSAA-t.

Disable Waiting for Vertical Sync
Szintén zenész: a D3D-nél leírtakhoz hasonlóan ez is garantáltan eliminálja a vsync-et...

Use Application Specified Buffering
A KYRO chip az alkalmazások alatt törekszik a triple-buffering használatára, függetlenül az alkalmazás beállításától. Ezzel a kapcsolóval ezt kikapcsolhatjuk az OpenGL alatti alkalmazásoknál, tehát ha például a Q3 single-bufferre van beállítva, a kártya nem fog automatikus triple-bufferinget használni, felszabadítva ezzel memóriája egy részét a textúrák számára. A triple buffering ugyanakkor növelheti a sebességet, folyamatosabbá teszi a renderelt képet, szóval érdemes ezt kikapcsolva hagyni...

Force Anisotropic Filtering
Ez a kapcsoló fixre állítja az anisotropic filter használatát, mint a D3D beállításoknál, viszont igen jelentős teljesítménycsökkenéssel jár.

Force Scissor Support Off
Ez a kapcsoló igazán számomra sem világos, hogy milyen metódust takar, de a leírás szerint növelheti a sebességet amellett, hogy vizuális problémákat okozhat: jobb kikapcsolva hagyni.

Force Texture Compression
Ez a kapcsoló is szerepelt a D3D beállításoknál: amennyiben lehetőség van rá, mindenképpen használni fog a kártya textúratömörítést. Néha növelheti a sebességet -- a Q3 jóval gyorsabb textúratömörítéssel --, mivel a tömörített textúrák értelemszerűen kisebb sávszélességet fogyasztanak, viszont a textúra minőségétől függően ronthatja a kép minőségét.

Enable Scene Manager
A nagyon sok poligont használó alkalmazásokban az optimális beállításoknak köszönhetően hiányzó részek lehetnek a képben, ilyet tapasztalhattunk például a 3DMark 2001 poligon-tesztjében. A 7.114-es meghajtóprogram már tartalmazza erre a tesztre a Scene manager automatikus bekapcsolását, így ez a teszt is hibátlanul fut le. Amennyiben ilyen hibát tapasztalnánk, ez a kapcsoló segíthet a problémán, bár ez, ismétlem, csak a nagyon nagy poligonszámmal dolgozó alkalmazásoknál fordulhat elő, jelenleg nincs ilyen játék, melynek szüksége lenne erre a beállítása. A Scene Manager használatához szükségünk lehet a külső Z és stencil-buffer használatára is.

Enable Fast Colour Calculations
Mint ahogyan az adott pont neve is sugallja, gyorsabb, de pontatlanabb színszámításokat engedélyezhetünk ezzel a kapcsolóval OpenGL alatt. Bekapcsolása növelheti a teljesítményt, de hibás színeket, sötétebb, esetleg teljesen fekete képet eredményezhet. A teljesítménnyel nincs sok gond, így hagyhatjuk kikapcsolva ezt a kapcsolót.

Enable Internal Depth/Stencil Buffer
A D3D-vel ellentétesen működik ez a kapcsoló, szóval ezt bekapcsolva kell hagynunk, kikapcsolt állapotban lesz a külső videokártya-memóriában a Z és stencil-buffer létrehozva. Csökkenti a teljesítményt, de növeli a kompatibilitást.

A képernyőbeállítások között megmaradt egyetlen fülön, a Display fülön állíthatjuk be a képernyő méretét és helyzetét, az esetleges gamma korrekciót.

Ennyi előzetes után jöjjenek a száraz tények, a tesztek eredményei, némi magyarázat mellett! Az említett kapcsolók közül csupán a vsync kikapcsolását engedélyeztem, minden más a gyári beállításon maradt.

A Vivid! kártyáknál a legutolsó 7.114-es meghajtóprogramot, a Siluro esetében a legutolsó hivatalos detonatort, a 12.41-est használtam, szintén alap beállításokkal, a vsync kikapcsolásával.

[oldal:Q3, MKD2]

Nos, a számok gyönyörűen mutatják, hogy a 700-as Duron jelentősen visszafogja a teljesítményt. Amíg a kártya el nem éri a fill rate-limitáltságot, lényegében konstans az fps-számokban kifejezett teljesítmény. A számokból az is kiolvasható, hogy a 115 MHz-es Vivid! valahol a 800x600 és 1024x768-as felbontás között éri el a fill rate határát, míg a Vivid!XS emelt órajelével egy felbontással feljebb, kb. 1024x768 és 1280x1024 közöttig bírja. Ezen felbontások felett már mindegy milyen processzort használunk, a kártya elérte fizikai korlátait. Legalábbis ebben az alkalmazásban.

Az MX ilyen szempontból 800x600 és 1024x768 közötti felbontásig bírja, lényegében 1024x768-tól semmilyen esetben sem ellenfele a Vivid!XS-nek. A meghajtóprogramja viszont sokkal jobban optimalizált, ez is nagyon szépen látszik alacsony felbontáson, 800x600-ig konstans 6-7 fps-sel többet hoz a Vivid!XS-nél. Jól dolgoznak az NVIDIA mérnökei.

Az MDK2 is OpenGL-alapú játék T&L-re optimalizálva, ez a tesztereményeken erősen meg is látszik, a 700-as Duron nem kelhet birokra az MX második generációs T&L motorjával. A tesztelést itt is 32 bites színmélységben, a T&L engedélyezésével végeztem el a demóval, a jelzett felbontásokon.

Az MX gyönyörűen teljesít, de mint azt már jeleztem, nem szabad helytelen következtetést levonni az eredményekből. A Vivid!XS stabilan 42 fps-t hoz 640x480-tól 1280x1024-ig, felbontástól függetlenül. Ez csak egy dolgot jelenthet: a hardveres T&L nélkül a 700-as Duron ennyire képes. Ha erősebb processzort használnánk bizony megfordulna a kocka.

Hogy melyik kártya rendelkezik nagyobb tartalékokkal? Elég csak megnézni az FSAA eredményeket.

[oldal:VillageMark, Temple Demo]