NAGYVAS

Tágra zárt szemek - 3dfx Voodoo5 5500 AGP 64MB

 

"majd a 3dfx, a 3D-s világ teremtésének (3df)x. napján, megteremtette az FSAA-t, és látá (ő is, és mi is), hogy ez jó. Persze a 4x-es (FSAA) az igazi, de ahhoz már a V5 6k lenne must have, ami még sehol se. Addig is V5 5500, mert megérdemlem."

"aki még nem látott V5 5500 által performált 4x-es FSAA-t, az nem látott semmit. GTS? Was? Ndívia? Lécci betűzd!"

 

Generation (3df)x

A 3dfx története a 3D-s világ története is egyben. Persze a PC-n. A Voodoo chipset ’96-os debütálása, kis képzavarral élve, mindössze a leendő poligon-jéghegy csúcsát jelentette. Azóta négy év telt el, és ezalatt a négy év alatt, olyan cégek futottak zátonyra, mint a jó öreg Hercules, olyan cégek nőttek irdatlan nagyságúvá, mint az NVIDIA, vagy a Creative, olyan cégek tűntek fel (most már mindenkinek), mint a Guillemot, és olyan cégeknek költötték a halálhírét, mint az Elsa, bár ez utóbbit senki sem vette komolyan.

 

Egy márkanév viszontagságai

Az első, akkor még 3Dfx-es chipset Voodoo Graphics névre hallgatott. A köré épített 4MB-os kártyák ma már szinte muzeális értékűek, és míg sok egyéb PC-s hardvernél a négy év még belefér, ezek a kártyák ma már szinte semmire sem jók. Legfeljebb az akkori játékok korhű megidézésére, bár ennek sincs túl sok értelme, hiszen a mai darabok lefelé kompatibilisek. A Voodoo sikere sokáig megkérdőjelezhetetlen volt, hiába minden Riva128-ak, de persze semmi sem tart örökké. Ugyan a Voodoo2 megjelenésével még nem sok minden változott, már ami a "kié a legtutibb chipset" kérdésre adandó válaszokat illeti, de azért mégiscsak eltelt két év, ami általában nem telik el nyomtalan. A 3D-s tortából sokan szerettek volna hasítani, nincs is ezen mit csodálkozni.

Invenciózus mérnökök tervezték rendíthetetlenül pipeline-ok garmadáját, régi holland szokás szerint érlelték és növesztették a chipeken a szilíciumot, akár a sajtot, mindenre elszánt marketingesek vasalták simulékony szövegükkel a leendő divat szerinti market inget (ez csak részben saját), valami készült tehát.

És lett este és reggel, és mindez sokszor, és lett TNT és Banshee, és lett Voodoo3 és TNT2, és lett Voodoo3 3500 is, bár nem kapkodták el, és TNT2 Ultra is, és vitte a prímet. És lett GeForce, majd GTS, és még mindig nem volt semmi új, az ekkor már 3dfx napja alatt. Semmi kézzelfogható. Csak egy bejelentés, úgy egy éve, november 15-én. Meg képek, amelyekről azóta persze részben kiderült, hogy csak idealizált kártyákat ábrázoltak (lsd V5 6k). És amíg az S3 és az NVIDIA azon versengett, hogy melyikük hozza ki egy nappal(m) korábban a hardver T&L-t lobogtató legújabb cuccát, addig a 3dfx mindezzel látszólag semmit se törődött. Persze ezzel pengeélen táncolt, hiszen a nagy nemtörődömség akár a piac beletörődését is kiválthatja, amikor már senki sem hiszi, hogy nem lesz ez még így se…

 

Novemberi eső

Az a bizonyos bejelentés november 15-én ugyan megtörtént, sőt még érdektelennek sem nevezném, mint egyes Intel happeningeket, de a piacra kerülés körüli bizonytalanság hideg zuhanyként zúdult a közönségre. "Mindezt mikor, mennyiért?" És ezek a kérdések, bár csak valahol nagyon mélyen, de egyben azt is kérdezték, hogy "meddig?" Meddig hisszük még el a 3dfx-nek, hogy a javunkat akarja, és itt inkább ne a kifejezés pejoratív értelmére tessetek gondolni. Mert bár mind a T-Buffer effektezhetősége (Depth of Field, Motion Blur, Reflectance Blur, Soft Shadows), mind az API független FSAA (pontosabban RGAA), mind a scaleable architecture szépen hangzott, de egy bejelentés még sosem csinált nyarat, komoly bevételeket pedig, amire a 3dfx-nek –azóta is- égető szüksége lenne, még annyira sem. 2000 második negyedévéig kellett várni és remélni, és azóta talán folyamatosan csodálkozni, mert azóta már megvehető/megszerezhető ez a megkapó/meglepő, meg minden kártya.

 

VSA-100 - Valami Sikert Arat

Ehhez persze nem mindegy, hogy mit vetsz el, a sulykot, a sejket, vagy egy tök egyedi megközelítés magját, mert haladni kell a core-ral, már ami az NVIDIA tranzisztor temetőit illeti. Mert ha pl. GeForce2, akkor az kapásból 25.000.000, és ebben semmi túlzás nincs, az én részemről. A haladásnak persze vannak kerülőútjai, azaz léteznek alternatív megoldások is, elég ha csak a klasszikus sünös-nyulas mesére gondolunk, ahol ugye egy (GTS) nyuszi és két (VSA) sün mérkőzött, a (poligon-tarackos, trilineárisan filterelt, alphablendingelt) szántáson… Az eredmény, hogy ne tűnjek alapból elfogultnak, ott inkább volt egyértelmű, míg itt már kevésbé az, hiszen a cikk java még hátra van.

A Voodoo Scaleable Architecture (VSA) alapötletéért nem is kellett a 3dfx-nek túl messze menni, elég volt csupán szétnéznie saját szabadalmai közt. Egy ilyen szétnézés során tűnhetett fel, hogy a Voodoo2 óta talomban tartott SLI (Scan Line Interleave) talán megéri a leporolást, leemelték hát a polcról, csavartak rajta egyet, kettőt, valahányat, hozzácsapták az SGI Onyx-okban egy ideje már felkapott hardveres FSAA-t, miután T-Buffer (Tarolli-Buffer) néven levédették saját Accumulation Buffer értelmezésüket, vettek egy majdnem full sized kártyát, rajzoltak rá egy AGP interface-t, meg saját tápcsatlakozót, amit eddig talán csak a Canopus engedett meg magának GeForce-os holmiján, raktak rá 2db VSA-100-as chipet, 64MB SDRAM-ot, nem raktak rá, csak egy árva videókimenetet, elnevezték V5 5500-nak, és 300$-ért bárkinek elérhetővé tették.

 

Párban

 

De nézzük szép sorjában. A VSA-100-as chipről nagyjából ezeket érdemes tudni:

• integrált, 128-bit-es 2D/3D/videógyorsító
• 0,25e micron-os, 6 rétegű lapkára álmodva
• 14 millió tranzisztort tartalmaz
• 166MHz-es alapórajelen fut
• 2db rendering pipeline-nal bír, egyenként 1-1db texturing block-kal
• 2db pixelt/texelt dolgoz fel órajelenként (vagy 1db dual textured pixelt)
• 332 megatexel-es fill rate-re képes (mert 166MHz=166.000.000 órajel)
• 350MHz-es integrált RAMDAC kapott rajta/benne helyet
• 32-bit színmély renderelést is támogat
• 24-bit-es Z & W bufferekkel
• 8-bit-es stencil buffer-rel
• 32-bit-es texturákat is kezel, ahol
• 2048x2048-as lehet a maximális textúra méret
• FXT1 és DirectX (mind az öt DXTC mód) textúra tömörítés mellett
• 64MB SDRAM-ot támogat
• 128-bit-es a memória interfész
• 166MHz a memória órajele
• 2,656GB a memória sávszélessége (mert 166MHz*16-byte)
• 2048x1536-os legnagyobb 2D-s felbontásra képes, 85Hz mellett
• PCI 2.2 kompatibilis
• 1x/2x/4x-es AGP-t is támogat, Side Band Addressing-gel akár (de minden esetben csupán 1x-es a data transfer rate)

 

Ami meglepő

Ismerve a riválisok verzióit, talán furcsának tűnik, hogy a 3dfx még mindig 0,25 micron-ban gondolkodik. Bár ugye ott van az a bizonyos “e” toldalék, amely talán pont arra utal, hogy a lapka 6 rétegű. Nem 5, mint pl. az NVIDIA-nál, aki már a 0,22 micron-os GeForce-okat is ezzel a módszerrel készítette. Hogy ez pontosan mi mindent jelent, csak sejteni lehet, mindenesetre a többrétegűség, alaplapi nyák esetén, mindenképp bonyolultabb gyártási technológiát takart, gondoljunk csak a korai Athlon lapok kálváriájára. Szintén fura a 14 milliónyi tranzisztor, hiszen pl. az S3 Savage 2000, úgy 12 millió, hogy egy T&L egység is helyet kapott benne. És bár egyes vélemények szerint, ennek a lehetőségét a 3dfx esetében sem zárhatjuk ki, én azért mégiscsak kizárnám. Annál is inkább, mert azóta már nyilvánvalóvá vált, hogy a kezdeti találgatásokkal részben összhangban, amelyek szerint a 3dfx, ha majd elérkezettnek látja az időt, mindenképp külső T&L coprocesszorral rukkol elő, a 3dfx tényleg a külsős T&L-t favorizálja. De hogy ez végül mennyire lesz a Mitsubishi-féle IMPAC-GE cucc, arról fogalmam sincs… Szintén kicsit csalódás, hogy a texture fill rate giga alatt marad, amely így azért még igen messze van a GTS-ek 1600-2000 megatexel-étől, bár mindennek ugye csak multitextúrás játákoknál van jelentősége. Szó volt ugyan róla, hogy mindkét pixel pipeline 2-2 texturing block-kot kap, de ez ugye nem így lett.

 

Ami nem

Nincs mit csodálkozni azon, hogy bár hosszas évődés után, de végül a 3dfx is beadta a derekát, és immár a VSA-100 is lazán megfutja azokat a kötelező köröket, amelyeket a többiek egy ideje már rovogatnak… Itt természetesen olyanokra kell gondolni, mint a 32-bit-es rendering, a 24-bit-es Z és W bufferelés, a 8-bit-es stencil buffer, vagy a “nagy” textúrák. Szintén nem meglepő, hogy azok után, hogy a 3dfx eddig sem értékelte túlzottan az AGP nyújtotta előnyöket, amely előnyök, mint pl. az AGP-s textúrázás, talán nem is annyira mérvadóak, mint azt kezdetben hinni lehetett, hiszen kellő videómemória mellett, már teljesen felesleges a real time textúra mozgatás, most sem tesz másként. Abban is hű maradt a 3dfx önmagához, hogy bár a 32-bit-es rendereléssel tényleg semmi gond (FSAA nélkül gyakorlatilag alig tapasztalható teljesítmény esés!), arról a bizonyos, poszt filterezéssel kicsikarható kvázi 22-bit-ről most sem kell lemondanunk (az ehhez tartozó beállításokat kicsit később).

Ezek a fícsörök azonban még csak a nagyon elejét jelentik mindannak a jelenségnek, amit V5 5500-nak hívunk. Ez tehát az alap.

És hogy mit lehet kihozni belőle?

 

T-Buffert mindenkinek!

A dolog persze nem új keletű. Az FSAA (Full Scene Anti-Aliasing) iránti igény a nem PC-s világban már jó ideje adott volt, és megoldásokban sem volt hiány. Ezeknek amúgy igen korrekt és komoly szakirodalma létezik, white paper csomók, miegyebek, a cikk alján, az irodalom jegyzékben szó is esik majd róluk. Ha csak nagyon messziről tekintünk az egészre, olyasmi látszik, mert szerencsére nem mondvacsinált problémáról van szó, hogy az aliasing, mint olyan, egy baromi zavaró és csúnya izé, mert szőrös vonalak, izgő-mozgó 3D-s scene, ilyesmi… Az oka mindennek ráadásul valahol (nem akárhol, de erre még visszatérünk) végtelenül egyszerű, hiszen mindössze arról van szó, hogy túl kevés adat írja le az adott felbontásban a 3D-s univerzumot. Az adott felbontás azért lényeges szempont, mert egyes megközelítések szerint, a felbontás növelésével a probléma orvosolható, míg más vélemények szerint természetesen nem. Persze rögtön hozzátesszük, mert ők is hozzáteszik, hogy ez utóbbi bőven nevezhető átmeneti állapotnak, és csak idő kérdése az egész. "Ha majd mindenki 4096x4096-os csendéleteket bámul a monitoron, akkor már tényleg semmi szükség nem lesz az FSAA-ra." Aha. Ezek szerint akkor még igen sokáig bányászható a valamilyen Anti-Aliasing-gal letisztított képet produkáló dollárbánya. A 3dfx-es tárnákat persze más eszközzel fejtik, mint az NVIDIA-nál, és itt történetesen hardveres implementációról van szó. Más kérdés, hogy az NVIDIA eddig még nem foglalt ténylegesen állást a kérdésben, ugyan szoftveresen elérhető valami FSAA-féle (minden NVIDIA kártyához), ez azonban egyelőre kevésnek tűnik. Kicsit pontosabban, az NVIDIA megoldása, az OGSS (Ordered Grid Super Sampling), nagyobb felbontást alapul véve interpolál az orrunk elé egy kisebbet (felbontást), viszont mert szoftveres megoldás, elég laassaan…

Azt se felejtsük el, hogy az NVIDIA kezdetben mondhatni szkepszissel fogadta ezt az egész FSAA mizériát, bár az olyan korai kijelentéseikre, amelyekkel az egész kérdés komolytalanságát próbálták hangsúlyozni, már biztos ők sem emlékeznek szívesen. "Amíg egy Hollywood-i film úgy 2000x2000-es felbontású, addig minket elég nehéz meggyőzni arról, hogy van az FSAA-nak létjogosultsága. Felettébb csodálkoznánk, ha a legújabb George Lucas múvi 640x480-ban készülne, 4x-es FSAA-val…" A GeForce-ok irdatlan fill rate-je is egyfajta állásfoglalás, hiszen így elvileg nagyobb felbontás renderelhető nézhetőre.

 

TT kuplé – tarol a Tarolli

Nézzük meg közelebbről a 3dfx megoldását! A hardveres FSAA amúgy már önmagában is van annyira látványos, hogy egymaga elfújná minden hiányérzetünk, azonban erről szó sincs. Az FSAA ugyanis csak egy –bár eddig mindenképp a legfontosabb- tulajdonsága a T-Buffer nevű 3dfx-es szabadalomnak, amelynek a lényege, hogy egyszerre több frame buffer használatát teszi lehetővé. A frame buffer-ben (a videómemória egy területe) alkotódik meg a megjelenítendő/monitorra kerülő 3D-s kép, ha tehát ebből több áll rendelkezésre, az minimum érdekesnek nevezhető. Használatával viszont olyan effekteket (Digital Cinematic Effects) lehet monitorra rittyenteni, amelyeket eddig szinte egyáltalán nem. A Depth of Field, a Motion Blur, a Reflectance Blur, vagy a Soft Shadows, mind arra jók, hogy még realisztikusabb képet kapjunk -a monitoron- arról, amiről a legrealisztikusabbat úgyis akkor kapjuk, ha kinézünk az ablakon… Ezek az effektek a filmek világából mindenkinek ismerősek, ha névről nem is, de látványra mindenképp, és bár pl. a Bug’s Life remekül szimulálta ebben is a valóságot, a mélységélesség produkálásához egy megfelelő optika is bőven elég, ami egy mezei, lencsés kamera, de akár a szemünk is lehet… Kissé szakszerűbben, a T-Buffer gondoskodik arról, hogy a különböző képfázisok a végleges képen már mélységéles, így blur-úgy blur, vagy épp FSAA-zottan jelenjenek meg. Ezeket azonban szoftveresen is támogatni kell.

 

A sült galamb itt sem repked sehova. Vagy mégis?

Egyedül az FSAA jelent kivételt ez alól, amely FSAA, egész pontosan Full Scene Spatial Anti-Aliasing-ot takar/rövidít, amelyet még pontosabban RGAA-nak (Rotated Grid Anti-Aliasing) illik nevezni, 3dfx-ék szerint. Remek tulajdonságai, hogy egyrészt API független, azaz mindhárom interfészt hozza (Direct3D / OpenGL / Glide), hogy 4x-es is lehet (persze 2x-es is, de az nem az igazi…J ), legfőképp pedig az, hogy nem kötelező. Választhatunk, hogy kell-e, vagy kell… Mivel tehát nem nagyon érdemes nem használni, szóljunk pár szót arról, mit is csinál az FSAA. Mint korábban említettük, a cél az lenne, hogy egy felbontást jó sok adattal írjunk le. Ennek érdekében a 2x-es FSAA 2db, míg a 4x-es 4db al-pixelt használ 1db végleges pixel előállításához. Ez persze bőséges memória sávszélességet igényel, de a végeredmény tényleg lenyűgöző. És nemcsak csendéleteknél, hiszen itt korántsem kirakat-technológiáról van szó. Amikor mindez mozgásba lendül, és mondjuk Unreal alatt kipenget 100fps-t, na, az az igazi truváj!

 

Frame rate is king – Álmában repked egy kicsit (V5 5500 640x480 4x FSAA)

 

Két dudás - egy csárda

Namost. Egyre közelebb vagyunk ám a tényleges kártyánkhoz, már csak egy karnyújtás, és… Említettük, hogy SLI, meg hogy ez is (naná!) rövidítés… Az úgy volt, hogy a Voodoo2 idején, bő két éve, a Quantum3D gondolt egy nagyot, és 650$-ért elkezdett árusítani egy érdekes kütyüt, amely nem volt más, mint 2db Voodoo2 közös köldökzsinóron. Obsidian2 X-24 volt a neve. "2", mert 2db kártyából állt, és "-24", mert 24MB RAM volt rajta. Eddig rendben is lennénk, de a két –ekkor még különböző- kártyán helyet kapott chipset-et, valahogy együtt kellett ugye működtetni. Erre a következő megoldást eszelték ki. Dolgozzon a két kártya váltott sorokon, azaz az egyik pakolja a frame buffer-be a páros, a másik pedig a páratlan sorokat. Páratlan, mi? És ráadásul pofon egyszerű, volt is sikere neki nagy. Aztán a Voodoo3 már nem tudott ilyet. Hozzá tartozik persze, hogy amíg a Voodoo2 még csak egy(kettő) szimpla 3D-s bővítő kártya volt, azaz kellett mellé még valami más is, addig a Voodoo3 már 2D/3D cucc volt egyben. (emlékét sokáig megőrizzük, főleg karib 210MHz-en(!) futó alien Voodoo3 2k-ját, amit Mulder ügynök kaparintott meg egy lezuhant Hollóházi csészealjból…) Ez volt tehát a Scan Line Interleave maga, és ezt szedték most elő, hogy a Voodoo5 5500-ön immár két chipset zakatolhasson együtt. A korábban emlegetett leporolás, és rajta csavarás által ez a technológia, mintha kicserélték volna került tehát újra képbe.

 

SLI is, meg nem is

A páros-páratlan soros megoldás manapság már nem rúgna labdába, annál is inkább, hiszen itt már kevés két chipset párhuzamosítása, legalábbis 3dfx-ék olvasatában. Amíg az Obsidian2 X-24 nem volt több szimpla kuriózumnál, addig a VSA platform már sokkal többet akar. Hiszen ezek a mostani kártyák csak a kezdetet jelentik, a rendszer ennél sokkal többre képes. (persze nem feltétlen VSA-100-as alapokon) Igen, még mindig Quantum3D, csak most épp Aalchemy, Obsidian helyett. Benne akár 32db(!) VSA-100-as proci falja a textúrákat, úgy 3 gigapixeles fill rate mellett. Hátezvan. J A 3dfx persze nem fog 4db VSA-100-as chipnél többet felzsúfolni semmilyen újabb termékére.

Quantum3D Aalchemy - Legyenek tiszták a vadászterületek

E rövid kitérő után, vissza a főcsapásra, és vizsgáljuk meg ezúttal a V5 5500-ön szolgálatot teljesítő 2db VSA proci szervezettségét. Elhangzott, hogy az FSAA egyáltalán nem kötelező kűr, nézed, ha teccik. Ebben az esetben tehát, ha mégsem lennénk rá kiváncsiak, csak tegyük fel… J , na, ebben az esetben élvezhetjük/érezhetjük –és csak itt- az SLI hatását.

A működéséről kb. ennyit érdemes tudni:

• skálázható, azaz nem csak 2db, hanem "bárhány" (max. 32) VSA chipet összefoghat
• egy kártyára (PCB-re) több chipset is kerülhet
• boldogul az 1024 feletti felbontásokkal (1600x1200-ig)
• páros-páratlan sorok helyett, sor-kötegeket (sávokat) oszt ki az architektúra minden chipnek, amely sávok szélessége dinamikusan állítható (a képernyő 1-128 “sorig” osztható, ahol ezen a max. 128 soros sávon osztoznak a chipek…)
• SLI-s működéskor minden chip csak a neki kiosztott rész-képterületet dolgozza fel, külön frame bufferben, amelyek tartalma végül átkerül a final/general frame bufferbe, és ezt látjuk viszont a monitoron
• elvileg van arra mód, hogy egyes chipek csak szimpla sorokat (egy-egy vonalat) számoljanak, de ez kevésbé hatékony a textúra használat oldalán, mintha nagyobb szeletekkel dolgoznának
• végül, de nem utolsó sorban, hátrányként megemlíthető, hogy SLI közben a textúra adatokat minden chipnek külön-külön fel kell tölteni, amely bár máshogy nyilván nem működne, mégis, kissé pazarlóan hangzik

 

Nekünk FSAA kell!

És ha FSAA, akkor T-Buffer, és ha T-Buffer, akkor már nem SLI. A két VSA chip ugyan még mindig együtt kavar, de már más módon, mint az előbbi, FSAA nélküli esetben. Mindkét chipset saját és teljes képen dolgozik, persze itt is külön frame bufferben, amely frame buffereket végül a T-Buffer ollózza össze, mint arról korábban már esett szó. Az SLI előbbi specifikációja persze részben idekívánkozik, hiszen a skálázhatóság itt is igaz, ahogy a fizikai kialakításban sem lehet különbség. Fontos azonban hangsúlyozni, hogy ez azért két, merőben más megközelítés. Mivel magáról a skálázható architektúráról kívántunk szólni, végig több VSA chipet emlegettünk. A T-Buffer azonban egy VSA-100-as chip mellett is működik (pl.Voodoo4 4500), bár ilyenkor mindössze a 2x-es FSAA-t érdemes használni, mivel már ez is felezi a fill rate-et. Kis kerülővel ugyan a 4x-es is elérhető, de ennek szerintünk nincs gyakorlati jelentősége.

Hát valahogy így. Ez mind lenne az, amit a cikk elején Nagyvasnak neveztem. Más attitűd, ez napnál világosabb, de hogy ez mire elég, főleg hosszú távon, még a jövő zenéje. Egy új, skálázható chipset, és a T-Buffer, ez tehát a 3dfx legújabb dobása.

 

Tes(z)tközel

Persze nem lenne teljes a kép, ha nem lennénk itt a vége felé sokkal, de sokkal konkrétabbak. Lehetünk, hiszen a hardver, már több mint egy hónapja itt figyel. Viszont tudni kell, hogy a Voodoo5-ös hatalmas papírládája, a kártyán kívül csak pár köbdeci levegőt rejt, hogy az adott leírás alig több a semminél, hogy a mellékelt driver CD-n csupán ősrégi meghajtóprogramokat lelni, amelyeknek az installálása csak a legerősebb idegzetűeknek ajánlható, nekik is csak félve, és hogy a legújabb (1.03 final) driver verzió is helyenként erőteljes pofára esésnek tűnik, jóllehet, a kártya 2D-s képe tökéletes, és a kompatibilitással sem volt gondunk.

 

Kinéz valahogy

 

A Voodoo5 5500 specifikációja ugyan már mindenki előtt tiszta kell legyen, pár dolgot azonban pontosítanék. A két VSA-100-as chip miatt, a memória sávszélessége is duplája annak, amit egy chip hozna, és így már 5GB feletti értékről beszélhetünk (5,312GB), amely épp akkora, amekkorával egy GeForce2 GTS bír. A külön táp csatlakozóról ugyan már szintén volt szó, azonban annyi még idekívánkozik, hogy a saját tápja nélkül a V5-ös meg se nyekken. A VSA egységekről AAVID coolerek szippantják el a felesleges hőt, ami azonban nem muszáj, hogy így legyen, hiszen ezektől a gyári szerkezetektől elvileg megszabadítható a kártya. (a használható ötletek beküldői közt valamit biztos kisorsolunk, és ugyan a Mellenger-féle V5-ös cooling kit-ről szó sem lehet, de talán egy mozijegy belefér…J )

Thomas McGuire, a 3DSpotlight reviewere szerint, elég pár órára bevágni a mélyhűtőbe a kártyát, ami után már sokkal könnyebb lefeszíteni róla a bordákat. Hát, nem tudom…

 

Contest - csak a tesztemen keresztül

A továbbiakban pedig a táblázatoké lesz a főszerep, és bár a számok úgyis mindig magukért beszélnek, némi kommentárnak azért mégis igyekszünk majd helyet szorítani. Tesztünk nem jöhetett volna létre, ha nincs a 3dfx, az NVIDIA, az Asus, az Intel, az Infineon, a Panasonic, és az Elsa. Továbbá köszönet illeti a Digital Extremes és az id programozóit, hogy lehet nekünk Unreal Tournament és Quake III Arena, Gary Tarollit, hogy lehet nekünk T-Buffer, und so weiter…

Kicsit konkrétabban, a teszteket a következő konfiguráció(ko)n futtattuk:

• Asus P2B-L alaplap (BX chipset)
• P2-400 @ 448MHz (SL2W7) és Celeron 566 @ 875MHz
• 192MB Infineon CAS-2 SDRAM
• 3dfx Voodoo5 5500, Elsa GeForce256, Elsa GeForce2 GTS
• Panasonic PanaSync/Pro P70 (17”, 96kHz, a frissítések optimal értékei 480/600/768/960/1024/1200 sor mellett, rendre 160/140/100/85/85/75Hz volt)

A szoftverkörnyezet pedig olyanokból állt, mint:

• Win95 OSR2 és Win98
• DirectX 7.0 (4.07.00.0700)
• V5 beta driver (1.01.03 beta) és a Detonator 3
• Unreal Tournament 4.28 és Quake III Arena 1.11

Az Unreal Tournament a következő beállításokkal futott:

• UseVSync: True (V5)
• UsePrecache: False (V5-GeForce-GTS)
• Texture Detail: High

 

Grafikoncept

A teszteknél saját timedemo-kat használtunk, az eredmények azonban némi magyarázatra szorulnak, hiszen itt nem normális timedemo-król van szó. Jól értelmezhető eredményekkel akartunk dolgozni, amelyek alapján lehetséges két kártya korrekt összehasonlítása, eredményekkel, amelyek nem elfogultak, azaz nem arról szólnak, hogy miért nincs még erősebb proci a gépben… Erre a célra olyan demókat építettünk, amelyekben nincsenek bot-ok, azaz csak magunk vagyunk egy-egy pályán, ahol kényünk-kedvünk szerint szaladgálunk, persze mindig ugyanúgy, hiszen ezek referencia demók. UT alatt a Peak-en, míg a Q3A-ban a Temple of Retribution-ön róttuk a köröket, rendületlen. Demóink amúgy hamarosan elérhetők lesznek a szájton, ha Parci is úgy akarja… Az eredmények reprodukálásához ezek mindenképp szükségesek, de még más is, hiszen nem véletlen, hogy pontos Hz értékekről szóltunk az előbb. Ezeknek ugyanis meghatározó szerepük volt abban, hogy mekkora frame rate-et mértünk. Az igazat megvallva, sokkal inkább látjuk értelmét annak, hogy 640x480-ban az alap 160Hz helyett, inkább 85Hz-et állítsunk be, mint annak, hogy elhanyagolható fps nyereséget erőltetve, a Voodoo túlhajtását pedzegetnénk. A túlhajtásba természetesen mi is belekóstoltunk, de mivel már 1-2%-os tuning esetén is szemetes lett a kép, ezt nem igazán erőltettük. Viszont 60Hz-es képernyőfrissítés mellett igazán impozáns többleteket facsartunk ki a Voodoo5-ösből, mind D3D, mind OpenGL alatt. Hogy miért nem kapcsoltuk ki inkább a VSync-et? Mert a V5 drivere ugyan papíron felkínálja, és az UT is konfigurálható rá, de mindezek ellenére nekünk mégsem sikerült. Talán nem is lehet. Timedemo-inkban tehát leginkább a videókártya képességein van a hangsúly, pl. hogy mekkora teljesítményt veszít adott felbontés 16 és 32-bit színmély abszolválása közt, hogy mennyivel fut kevesebbet, ha mondjuk 4x-es FSAA-t választunk 2x-es ellenében, és így tovább. A gyengébb processzorunk ugyanis -rendes játék közben- túlontúl visszafogta mindkét engine-t, olyannyira, hogy ilyen rendes játék során rögzített timedemo-val szinte mindig ugyanolyan alacsony frame rate-et mértünk, amelyre korrekt, árnyalt tesztet nem mertünk volna alapozni. Megoldásunk persze nem feltétlen a legnagyszerűbb megoldás, de szerintünk mégis így érdemes.

 

Egy API halála

Ha Voodoo(1-2-3), akkor Glide, ha V5, akkor viszont már nem. Olyannyira nem, hogy ennek az API-nak egy 5500-ösön már semmi keresnivalója. Unreal Tournament alatt, FSAA nélküli felbontásoknál, egyszerűen nincs létjogosultsága, hiszen a kártya D3D alatt is hozza azokat a frame rate-eket, ráadásul 32-bit-ben(!), amelyeket a Glide paszíroz ki magából, 22-bit mellett. Amíg a Glide alapból 22-bit-re áll be, addig a D3D 16-bit-es renderingjét post-filterekkel tehetjük látványosabbá, azaz a 3D Filter Quality: High, és az Alpha-Blending: Sharper beállítása után érhető el a 22-bit. Ezek a post filterek 32-bit-es renderingnél amúgy már nem érvényesíthetők, hiszen ott már semmi szükség rájuk. A V5-ös finomhangolása a 3dfx Tools című dologgal történik, amely ugyan csak a 4.0-s Internet Explorer első service pack-je után hajlandó életre kelni, de ezért cserébe rendkívül sokoldalú. Mielőtt ideemelnénk a Glide és a D3D teszteredményeket, még el kell mondanunk, hogy a legutolsó V5-ös driver mellett sem képes tiszta képet adni a Glide API FSAA alatt, amely 2x-es FSAA-nál ugyan még nem annyira homályos(!), mint 4x-es mellett, de korántsem olyan makulátlan, mint bármely D3D-s beállításkor. És akkor a táblázatok:

 

Ezek az eredmények a gyengébbik processzor bentlétekor születtek, és mindössze annyit fűznénk hozzá, hogy bár mint említettük, bot-mentes pályán készültek, az alacsonyabb fps értékek bot-ok társaságában sem csökkennek. Bot-ok mellett azonban (ez persze függ attól, hogy hány van belőlük) ez a konfig 40-50fps fölé nem jut.

 

Voodoo-ász interface

Ez persze a Direct3D-t jelenti, azonban kertelés helyett csapjunk rögtön a lovak közé, lássuk a grafikonokat!

 

Itt már mindkét processzor (külön-külön) hadrendbe állt, mint azt jelöltük is, viszont furcsa mód, 1600x1200-as felbontásban, ez az API már nem volt hajladó… A frame rate-eket a Glide-osokkal összevetve látszik, hogy miről is beszéltünk korábban. Azonban folytassuk a sort a többi, FSAA alatti eredmény felsorolásával, és csak ezek után vonjuk meg a D3D mérlegét, már ami a V5-öt és az UT-t illeti.

 

Az 1600x1200-as felbontás itt már nem is szerepel. Nem véletlen. A D3D alatti FSAA ugyanis mindössze 1280x960-ig tart. És ott sem végig, de erről kicsit később. Ennél a grafikonnál is látszik, hogy a gyengébbik proci mennyit is számít, hiszen a 448MHz még ilyen laboratóriumi körülmények közt is gátat szab a kártya szárnyalásának. Ahogyan az erősebb processzor is, csak az kicsit magasabban. Hogy hol van a határ, azaz mennyit hozna a kártya, ha csak rajta múlna, nehéz megmondani, mindenesetre az erősebb proci nyújtotta előny egyértelműnek látszik.

 

Ez azonban csalóka. Ha figyelmesebben megnézzük a két utóbbi grafikont, kitűnik, hogy bizonyos felbontásoknál a két processzor közt már nincs semmi különbség, azaz teljesen mindegy, hogy milyen procit rakunk az 5500-as alá, hiszen a kártya szűksége napnál világosabb. Ez egyben azt is jelenti, hogy ha ezeket, a többnyire 32-bit-es (2x-es FSAA) vagy 4x-es FSAA melletti felbontásokat preferáljuk, a gyengébb CPU nem jelet hátrányt. És hogy miért nincsen kitöltve két rubrika? Csupán azért, mert 1024x768 fölötti, 32-bit-es felbontások, 4x-es FSAA alatt egyszerűen nincsenek. OpenGL alatt sem, bár ott, röhejesen alacsony fps-ek mellett, de még az 1600 is átjön, 16-bit-ben. Ezekben a beállításokban a V5-ös D3D alatt 2x-es FSAA-ra vált, míg OpenGL-nél (ha jól emlékszem…J ) hibaüzenetet ad. Ezennel a V5-öst ki is végeztük, már ami az UT-t illeti, azonban hadd tegyünk pár (szubjektív?) észrevételt. Szerintünk a 4x FSAA, amely ugyan csak 640x480-ban ajánlható, 32-bit-ben ad olyan vizuális élményt (amelyet screen shot-okkal itt meg sem próbálunk illusztrálni, mert nem nagyon lehet), amely bőven kompenzálja az über fps értékek elmaradását. A játék, ebben a beállításban is tökéletesen folyamatos, és összehasonlíthatatlanul szebb és képernyőrevalóbb, mint bármely más esetben. Ráadásul a Texture Quality-t Medium-ra pöckölve, kapásból 62fps-t mértünk, amelyet a monitor 85Hz-re állításával, további 9fps-sel tudtunk növelni. Aki még ennyivel sem érné be, annak ajánlható a monitor 60Hz-re állítása, amely -a feltehetőleg egyszerűbb szinkronizálás okán- további 3-4fps-t jelent. 640x480-ban ez utóbbi még nem is oly jelentős, hiszen itt 60fps feletti értékről indulunk, a dolog azonban máshol is bejön, és 1024x768/4x FSAA/32-bit-nél is 5-6 frame-et nyerhetük így, amely egyrészt valódi nyereség, tehát az alacsony fps értékek miatt, bot-ok mellett sem vész el, másrészt a kiinduló értékekhez képest kb. 25% bónuszt jelent.

 

A másik oldal

A másik oldal természetesen a GeForce kompániát jelenti, mert természetesen rájuk is kiváncsiak voltunk. Íme:

 

Olyan táblát, amelyen egyszerre látszana V5 és GeForce, nem készítettünk, azonban a számokat így is össze lehet vetni. Amellett, hogy ezek az eredmények nem sokban különböznek az 5500-as SLI-s (0x FSAA) eredményeitől, ezen a grafikonon a legszembetűnőbb a GeForce-ok közti erőkülönbség. Ez remekül látszik. Az 1024/32-bit a vízválasztó, innentől húz el a GTS. Ugyan OpenGL alatt sokkal látványosabban, de azért itt is van differencia. És mindez csak 448MHz mellett van így, hiszen az eredmények a gyengébbik procit fémjelzik.

 

Meglepő, de nem mulatságos

Mármint az OpenGL. Illetve az, amit ez alatt az API alatt mutat a Voodoo5. Mert a riválisok fényében akár kínosnak is nevezhető. Persze csak akkor, ha egyenlő pályákon versenyeztetjük őket, amelybe az FSAA természetesen (szerencsére) nem tartozik bele. Az más tészta. Más minőség. Látni kell! De előbb lássuk a teszteredményeket, amelyeket sajnos csak a gyengébbik CPU-val tudtunk elvégezni. (logisztika rulez)

 

Itt is szépen látszik, hogyan viseli a terhelést a V5-ös. A 4x-es FSAA-val idővel már nehezen birkózik meg, azonban ez érthető, a memória sávszélesség és a fill rate sem feneketlen. Azonban itt is el kell mondanunk, hogy 4x-es FSAA alatt már igen komoly fps nyereség származhat abból, ha csökkentjük a monitor frissítését. De még ez sem elég ahhoz, hogy a Voodoo labdába tudjon rúgni, akár egy GeForce256-tal szemben. Ez pedig igencsak kínos. Bár az OpenGL nem az a mindenhol használt API, nem egy D3D, amely inkább pályázhatna az “API-k igáslova“ címre. A Quake III viszont OpenGL-es, ami sokaknak épp elég érv. Viszont a kicsit földhözragadtabb frame rate, és a 4x-es FSAA szerintünk jó kompromisszum lehet, sőt.

 

Ami sok, az sok

És végül emeljük ide, az OpenGL alatt mért, GeForce fps-tobzódás mementójaként felemlegethető táblázatunkat, amely kicsit előre is mutat, hiszen ez a cikk már úgy fejeződhet be, hogy itt trónol az asztalon a Creative GeForce2 GTS Ultra kártyája, tesztre várva. De még előbb:

 

Igazándiból “no comment”, ez más dimenzió. A GTS lelépi az elődjét, persze magasabb felbontásokban. Hát igen, a GeForce ennyit tud, és ezt nagyon. Azonban a látvány szerintünk hagy némi kívánnivalót maga után. Mert hiába 1600x1200/32-bit/67fps, ha a kép/scene FSAA után kiált! És bár már tényleg alig látunk a képen pixeleket, aliasing-ot annál inkább. Végezetül annyit, hogy itt is van/volt értelme a monitor frissítésekkel játszani, mert csak félig-meddig lehetett kigyomlálni a VSync-et.

 

A kezdet vége

A 3dfx szerint új időszámítás vette kezdetét, és ezt a kezdetet ők maguknak érzik. Ne dőljünk be nekik! Csak a szemünknek higyjünk.

(keopsz!)

 

“Irodalomjegyzék”, a teljesség igénye nélkül:

• iXBT Labs: 3dfx Voodoo Scaleable Architecture Preview
• iXBT Labs: 3dfx Voodoo5 5500 Graphics Card Review
• 3DSpotlight: 3dfx Voodoo5 5500 AGP review
• 3dfx: FSAA Overview
• 3dfx: FSAA Faq
• Gary Tarolli: Anti-Aliasing vs. Transform and Lighting
• HHP: Grafikus-vezérlők táblázat