A shaderek sebessége
Egy általunk korábban nem használt szintetikus tesztprogramot vetettünk be a DeltaChrome architektúrájának megismerésére és az ATI és NVIDIA chipjeivel történő összehasonlítására. A D3D Right Mark az iXBT.com fejlesztése, még béta állapotban van, de már most is jól használható. A szoftver olyan, mint az EKG masina, nem valami szép, átlagember számára szinte teljesen érthetetlen eredményeket produkál, de a szakavatottak hasznos következtetéseket tudnak levonni a segítségével. A program jelenlegi állapotában vertex- és pixelshader-teljesítményt, fill-rate-et és HSR- (hidden surface removal) hatékonyságot tud mérni, és használható a filterezési eljárások minőségének elemzésére. Nem produkál látványos képet, de úgy van összeállítva, hogy csak az éppen tesztelni kívánt egység legyen terhelés alatt, ezért szinte teljesen CPU-független. További nagy előnye, hogy nyílt forráskódra épül, ezért pontosan lehet tudni, mikor mi történik.
Hirdetés
A következő tesztekben a közel azonos órajelen mértük össze az ATI, az NVIDIA és az S3 Graphics középkategóriás megoldásait, így össze tudjuk hasonlítani az egyes architektúrákat technikai oldalról. Az NVIDIA 5600-nak adtunk egy kis előnyt, durván annyit, amennyivel az újabb 5700 gyorsabb. A tesztalanyok az alábbi sebességeken futottak:
- ATI Radeon 9600 300/300
- S3 Graphics DeltaChrome S8 300/300
- NVIDIA GeForce FX 5600 340/275
A geometriai feldolgozó egység tesztje
A felhasznált fejmodell 6542 vertexből áll
100 apró fej a képernyőn, izzadnak a vertex shaderek
Ez a teszt a maximális geometriai sebesség mérésére használható. A program egy 6542 vertexből álló fejmodellt jelenít meg 100-szor, így jelentős poligonszámot ér el. Ezen a képen aztán alkalmaz 3 diffúz és spekuláris fényforrást, ez ma általánosan használt, jó minőségű megvilágítást eredményez. A textúrázó egységet és a memória-sávszélesség beszűkülését azzal küszöböli ki, hogy nagyon aprók – megközelítőleg egy pixel nagyságúak – a poligonok, így alig kell textúrát számolni és nem kell komoly memória-sávszélesség sem. Lemértük a DirectX 7-teljesítményt fix hatáskészlettel (fixed function, továbbiakban FF), a DirectX 8-sebességet Vertex Shader 1.1 és Pixel Shader 1.4 beállítás mellett és a DirectX 9-sebességet VS2.0 és PS2.0 beállítással. A VS1.1 és VS2.0 programkód (shader assembler nyelvben) csak abban tér el egymástól, hogy az elsőben a fényforrások kódja háromszor van leírva, míg a másodikban egy hármas ciklusban kapott helyet.
A DeltaChrome a 4 geometriai egységnek köszönhetően jól teljesít DX7-ben, de a későbbiekben lemarad, az ATI kártyája mögött. Az FX 5600 jeleskedik DX7-ben, de ahogyan haladunk az újabb shaderek felé, egyre gyengébben teljesít. A Radeon 9600 teljesítménye közel egy szinten van mind a három DX-verzióban. Jó látni, hogy a DeltaChrome S8 DX8- és DX9-eredményei nem térnek el túlzottan, a különbség a cikluskezelésnek köszönhető. Az már kicsit kellemetlenebb, hogy a chip a négy vertex egységgel is alaposan lemarad az ATI két egységet tartalmazó GPU-ja mögött. Valószínűleg a kisebb DeltaChrome S4 ezeknek az eredményeknek a felét tudja majd felmutatni, ami nem túl kecsegtető.
Az eredmények igazolnak minden eddigi feltevést:
- Az FX 5600 tartalmaz egy erős FF egységet, de gyengébb VS egységgel rendelkezik, külön-külön DX8-as és DX9-es útvonallal.
- a Radeon 9600-nál ugyanazt az utat járják be az adatok mind a három DX-verzióban, nincs külön hagyományos FF egység, hanem a shaderek emulálják. DX8-as esetekben is a lefelé kompatibilis VS2.0 dolgozik.
Pixel Shader 2.0-tesztek
A geometriai egység kiküszöbölésére egy nagyon egyszerű alakzat jelenik meg, ennek a textúrázását valósítja meg a PS2.0. Beállítható teljes (32 bites) és feles (16 bites) precizitás.
Balra diffúz, jobbra diffúz + spekuláris fényhatás
Az első részben 3 diffúz fényforrás világít meg egy egyenetlen felületet. A felület rücskösségét és színét egy-egy textúra tartalmazza. Egyetlen változtatható tényező a felület rücskösségén visszaverődő fény kiszámolásának módszere, ami megoldható PS-számolással (aritmetikai) vagy a textúra mintavételező (sampler) által egy előre elkészített "normalizációs térképből", amely az előre kiszámított értékeket tartalmazza, ezáltal tehermentesíti a PS-t.
A számolást használó esetben a DeltaChrome S8 eredményei eltérnek 16 és 32 biten, ami azt mutatja, hogy valóban létezik a feles precizitású, de gyorsabb mód. Sebességben a chip a dupláját tudja az FX 5600-nak, és 16 biten még a Radeon 9600-at is legyőzi. Ezek az eredmények jónak számítanak, de megint meg kell jegyezni, hogy az S8 kétszer annyi feldolgozó egységgel gazdálkodik, mint a riválisok. Normalizációs térkép használatával tesztalanyunk 32 bites sebessége logikusan növekedett (tehermentesült a PS), de 16 biten lassult. A memória sebességének emelésével nem kaptunk jobb eredményt, de a 20 MHz-es GPU-tuning hozott további 5 FPS-t, ami arra utal, hogy a textúra mintavételező (sampler) fárad el.
A modul második részében a korábbi 3 diffúz fényforrás kiegészül spekuláris komponenssel. A spekuláris tényezőt egy hatványfüggvény (pow) segítségével tudja kiszámolni a PS, vagy mintavételezhető előre kiszámolt textúrából, a normalizáláshoz hasonlóan. Az ilyen textúrákat LUT (look up table) textúráknak nevezik; ezek esetében a koordináták a kiszámolni kívánt értékek, míg a művelet eredménye van a textúrában. Egyszerű LUT például a szorzótábla: 2×3=6, ahol a (2,3) koordinátán a szorzás eredménye (6-os) van tárolva. Itt a normalizálás és a pow függvény kiszámolásának módja is állítható.
A PS-ekre hagyatkozó számolás során a 8 futószalaggal rendelkező DeltaChrome kicsivel megelőzi a 9600-at, és háromszor gyorsabb, mint az FX 5600. Érdekes módon azonos a 32 és 16 bites eredmény. A normalizálást textúrából olvasva felére esik vissz az S8 eredménye 32 biten, míg 16 biten alig változik. A konkurensek sebessége ugyanakkor durván 10%-kal nő. Fordított esetben (számolt normalizálás és LUT textúrából) ismét megegyezik az S8 32 és 16 biten nyújtott teljesítménye. A Radeon 9600 kicsit gyorsul, az FX 5600 pedig kicsit lassul. Teljesen a mintavételezőre támaszkodva hozza a DeltaChrome a leggyengébb eredményt, nem fekszik neki ez a megközelítés.
A modul harmadik részében megismerkedhetünk a PS-ek egy izgalmas lehetőségével, a valós idejű textúralétrehozással (procedural texturing). Ebben az esetben nincs szükség a memóriában tárolt textúrára, így takarékoskodhatunk a memória-sávszélességgel. Elég megadni néhány alapszínt, egy mintavételező függvényt és némi rendezetlenséget (zajt). A PS a mintavételező függvény pillanatnyi értéke szerint keveri össze az alapszíneket, és hogy ne legyen túlzottan "műanyag" az eredmény, belekever egy kis zajt. Ez a hatás ismerős lehet a 3DMark03 PS-tesztjéből (fa mintázatú elefánt és orrszarvú).
Márvány és tűz: valós időben számolt textúra
A Rightmarkban egy márvány és egy tűz textúrával lehet tesztelni, ezek megközelítőleg azonos sebességgel futnak. Ezekben a tesztekben szinusz mintavételezési függvényt alkalmaz a PS, ezt lehet számolni, vagy ismét LUT textúrából elővenni (egy dimenziós textúra). Számolásos esetben ismét a DeltaChrome diadalmaskodik, méghozzá jelentős előnnyel, ám LUT-mintavételezős esetben az S8 lassul 5%-ot, míg a konkurensek gyorsulnak.
A cikk még nem ért véget, kérlek, lapozz!
