D3D RightMark 1.0.2.7, elemzés folyanatban...

UPDATE: kijött egy frissebb verzió 1.0.4.9 amiben már van lehetőség a pontos mérési időtartam beállítására egyes teszteknél, Pixel Shading rész pedig még finomabb lett, most már a normalizálás mellett a sin() és pow() függvények is választhatók textúrából (előre kiszámolva) vagy real-time kiszámolhatóak és jött egy újabb, 2.a jelölésű Shader Profile (ezt még nem néztem meg részletesen). A batch fileket módosítottam az új verzióhoz.

3d.rightmark.org

Geomerty Processing Speed

Maximális lehetséges geometriai sebesség mérése jó sok polygonnal, amik nagyon picik (egy pixel nagyságrendűek) hogy elkerüljék a textúra filterezésből, fillelésből, textúrák memóriába olvasásából és más "mellékes" funkciókból adódó esetleges lassulásokat ezért a felbontás nem befolyásolja a sebességet. Anti Aliasing és Anisometric Filtering bekapcsolásának nincs sok értelme, mert szándékosan nagyon apró megjelenítendő felületekkel dolgozik, igazi számolós kraft teszt Vertex Shaderekre.
A picike fej, amit forgat a teszt a head.x fileban található DirectX modell és 6542 vertexből áll szóval ha medium (25fej) vagy high (100fej) beállítás szerepel akkor már jópár geometriai számítást kell végrehajtani, minden egyes vertexre mindegyik fejnél kiszámolja az aktuális fényeket.

Vertex Shader 1.1 és 2.0 kód között az az eltérés, hogy 2.0ban a több fény ciklusban van megoldva, és a normalizálás az új nrm utasítás oldaj meg, a régi dp3-rsq-mul hármas helyett (próbáljátok ki mennyivel gyorsabb vagy lassabb, nekem csak VS1.1és hardver van kéznél). Mivel geometriai tesztről van szó, pixel shader csak annyit csinál, hogy a kimenetére pakolja a verex shaderből kapott cuccot egyetlen utasításban vagy az is fixed functionra kapcsolható. Az a gyanúm, hogy a fixed function rész a régi jó DX7es kártyákhoz van, majd kipróbálom a gf4mx-en.

TESZT - (PowerMagic Radeon 8500LE 300/240)
Ma már szinte mindenhol a specular lighting is dívik a diffuse mellett ezért végig Diffuse + Specular (3 Point Lights) beállítást használtam - akinek nem világos mi a diffuse és a specular, az nézze meg Tessier cikkét a Savage Gamersen! Minden tesztet full screen 1024×768/100MHz-en csináltam, pure hardware vertex processing beállítással, screenshot ki volt kapcsolva.

Kíváncsi voltam a fixed function-VS1.1-VS2.0 közötti viszonyra, és arra milyen eltérés van a medium és high Geomerty Profile között, valamint érdekelt hogy milyen az eltérés, ha nem fixed functionra van állítva a pixel shader.
Érdekes módon VS1.1/PSff és VS1.1/PS1.4 beállítások között csak 3ezrelék volt a eltérés, míg a VS1.1/PS1.1 ezektől több mint 9%al elmaradt, holott a VS1.1/PS1.1 és VS1.1/PS1.4 módokban használt kód között csak annyi az eltérés, hogy egyikben ps_1_1-nek míg a másikban ps_1_4-nek deklarálja a shader assemblyben lévő EGYETLEN mov utasítást. Ebből arra következtetek hogy ATIék nem huzalozták be a fixed functiont hanem PS1.4el hajtatják végre talán driverből. Teljes fixed function viszont 50%al gyorsabb volt a VS1.1/PS1.4nél, erre nincs tippem miért lehet, talán ennyivel gyorsabb a beépített fényhatás ami gondolom korántsem annyira rugalmas mint a shaderes társai.
Meglepő dolog jött elő akkor is, amikor mediumra állítottam a Geometry Profile-t high-ról. Fixed functionban kb 6%ot növekedett az eredmény, VS1.1/PS1.4 és VS1.1/ff beállításokban 10% csökkenés volt és VS1.1/PS1.1 ismét növekedett 5%ot, természetesen PPSben, az FPS itt lényegtelen. Kíváncsi vagyok, hogyan alakulnak ezek az értékek más GPUknál.

Geometry tesztet - 6darab 20másodperces teszt van benne, kb. 2 perc, régebbi kártyákon nem fut le mind.

1. Geometry Profile: high - Sahder Profile: Fixed Function pipeline - dx7
2. Geometry Profile: high - Sahder Profile: VS1.1 - dx8.0
3. Geometry Profile: high - Sahder Profile: VS2.0 - dx9
4. Geometry Profile: high - Sahder Profile: VS1.1/PS1.1 - dx8.0
5. Geometry Profile: high - Sahder Profile: VS1.1/PS1.4 - dx8.1
6. Geometry Profile: high - Sahder Profile: VS2.0/2.0 - dx9

Végig Diffuse + Specular (3 Point Light), 1024×768/100MHz full screen (Akinek nem bírja a monitorja, az kapcsolja le a teszt erejéig - max 1 perc!) és screenshot disabled. Elvileg az első kettőben NVnek kellene jobbnak lenni 1,2,4,5-ben, a többiben meg az ATInak, bár ez egyáltalán nem biztos, majd meglátjuk...

Hidden surface removal

Z bufferrel kapcsolatos mechanizmusok tesztelésére hivatott. Ezek arra jók hogy a GPUt megmentség egy rakás fölösleges munkától, olyan polygonpontok lerenderelésétől (vagy csak frame-bufferbe írásuktól, ami szintén idő- és memóriasáv-igényes) amik nem látszanak a képen, takarva vannak más képpontokkal, olyanokkal, amelyeknek Z értéke (kamerától mért távolsága) kisebb (akinek nem világos a Z-buffer technika nézzen utána a VGA.nfo-n vagy Tessiernél vagy máshol). Itt hatalmas számú poligon jelenik meg, már van értelme AA és AF bekapcsolásának.

Ebben a tesztben 3 eset van:
back to front - hátulról indul el a polygonok megjelenítése, Z-buffer szempontjából a legrosszabb eset mert egyre kisebb Z értékű pontok jönnek, mindig számolni kell és módosítani a frame-buffert.
front to back - elölről indul a polygonszámolás, optimális eset a Z-bufferes módszereknek.
unsorted - általános eset, leggyakrabban ilyennel találkozik a VGA játékokban

Egy Z-buffer technika hatékonyságát az optimális eset és az átlagos eset közötti eltérés mutatja meg. Minél közelebb van egymáshoz a kettő, annál jobb (akár százalékos arányban is megadható). Shading profile opcióval lehet textúrát rákényszeríteni minden polygonra (egy 512×512es 24bites HSR.jpg), ezzel lemérhető a renderelést is megelőző korai Z-teszt hatékonysága, szóval ha látszik a textúra akkor nem működik a korai Z-teszt mert a program rákényszeríti a textúrát.

TESZT - (PowerMagic Radeon 8500LE 300/240)
A polygonok számának növelésével egyre hatékonyabbá válik a Z-teszt, persze csak amíg el nem érjük a hardver többi részének határait. Alőször azt hittem a mai vasak lazán elbírnak a high (20000) polygonnal ha működik az early-Z és ennek kikapcsolása csak érdekesség, valójában sok értelme nincs, de amikor 1024×768/100Hz/full screenbe kapcsoltam a régi jó 8500LE már nem tudott 20FPS fölött produkálni, feltehetőleg elfogy valami, mert 2000 polygonnal még vígan megy 100FPS fölött és 640×480ban még 20000el is 35FPS. Szerintem a memsávszéleség fogy el. Próbáljátok ki keményebb vasaknak milyen felbontásnál van 20000el vége (24FPS alá megy)!

A VS1.1 és 2.0 kód teljesen egyforma, megint csak a VS_1_1 és VS_2_0 deklarációban van eltérés, és ismét van fixed function. Radeon 8500on fixed function és VS1.1 között semmi eltérés nem volt, gondolom azért mert nagyon primkó a shader kód (4-5 utasítás), szerintem VS2.0ban sem lesz nagy eltérés, azért aki tudja mérje ki. Early-Z kikapcsolása nagyon megfekteti a kártyámat, harmadára-negyedére lassul..

A legrosszabb esetnek (back to front) csak jelképes, elrettentő értéke van, az átlagos és legjobb eset viszonya lényeges. 20.000 poligonnal (High) az átlagos/optimális (unsortd/front to back) arány 96% fölötti volt, 200al (low) 89% körüli, állítólag NV valamivel gyengébb, de nem sokkal.

Ezzel mérjetek és a két eredményt osszátok el egymással (kisebb/nagyobb)
1. Geometry Profile: High - Sorting Profile: unsorted - Sading Profile: Fixed Color - Sahder Profile: Vertex Sahder 2.0 vagy 1.1, kinek mi van
2. Geometry Profile: High - Sorting Profile: front to back - Sading Profile: Fixed Color - Sahder Profile: Vertex Sahder 2.0 vagy 1.1, kinek mi van
Megint 1024×768/100Hz full screen és nincs screenshot. Akinek van kedve, próbálja meg Low Geomerty Profile-val is.

Pixel filling

Ez a rész két dologra használható, ez egyik az elméleti pixel és textúra fill-rate megállapítása, a másik a filterezési eljárások vizsgálata. Adva van egy egyszerű rácsváz, amire kívánság szerint textúrát lehet húzni, vagy kitölthető egy színnel, esetleg MIP szintenként más-más színnel. A felhasznált textúra egy 512×512/24bites 10MIP szinttel rendelkező PixelFilling512.dds (Direct Draw Surface).

A VS1.1 és VS2.0 kód megint teljesen azonos az egyszerűsége miatt. A PS1.1 és PS1.4 kód csak minimálisan tér el (másképp mintavételeznek a textúrákból, mert mások az utasításaik) és VS1.1 kódot használnak. A PS2.0 kód szintén közel áll a PS1.4hez és VS2.0 kódot tartalmaz, ami egy az egyben VS1.1, szóval mindenki mérjen az általa elérhető legmagasabb shader beállítással és esetleg mérje össze a legalapabb VS1.1 kóddal.

Először nézzük a fill ratet. Itt igazából tanácstalan vagyok hogy miben merre mérjünk, mert elvileg a 0 textúra lineáris filterezés adja a pixel fill ratet, de nekem érdekes számok jöttek ki és 1250FPS :) szóval hanyagoltam és inkább megnéztem a filterezéseket, ami NAGYON tanulságos volt.

Mivel 512×512/24bites a minta textúra, azért a texture size-t 512×512re állítottam, bár lehet, hogy ma már az 1024×1024 lenne a megfelelőbb... Láthatóan a texure number is befolyásolja az FPS-t, nem sikerült rájönnöm hogyan, ezért vettem a maximális 8at és elkezdtem játszani a filterezésekkel. Sajnos az r3xx előtti ATI chipek nem tudnak egyszerre aniso és trilinear filteringet így be kellett érnem a bilinear, bilinerat+MIP-mapping, trilinear, aniso és aniso+MIP-mapping megoldásokkal. Nagyon jól látható a MIP-mapping áldásos hatása és Aniso filteringnél kijött szépen a szögfüggőség. Míg 0fokban szépen látszott a különbség 1-2-4-8-16 szoros szint között addi 60fokban a 2-4-8-16 szoros kép sajnos egyforma volt...

Shotokat csináljatok 0-45-60 fokban, szerintem mindegy melyik shaderrel, a report html alapján adjatok nekik beszédes nevet (pl. bilinAF_00fok_AF04 = bilin+AF filterezés 0fokos elforgatás 4szeres AF, így egymás után jön majd a képnézegetőbe a bilin és AF filtert használó 0fokban készített 1-2-4-8-16 szoros AFel készült kép és jól lehet látni/nemlátni az eltérést). Érdekesség kedvéért lehet csinálni színezett MIPszintekkel is pár tesztet, összemérni az NV és ATI trilinearját. A shotokra bőven elég a 640×480, mert a lényeg azokon is látszik és így is fenenagyok lesznek a képek.

Shaderteszt

Shading profile: a három legutolsó az érdekes a Procedural Texturing-es részekben márvány és tűz áltextúrát csinál a beépített HLSL márvány és tűz shaderrel egy-egy 1 dimenziós textúrából limeárisan mintavételezve, hasonlóan az elefántos példához. ADiffuse + Specular Lighting (3 Point Lights) pedig saját textúrát használ. Ha majd élőben megnézem, többet tudok mondani.
Vector Normalization: ha Normalization cubemap akkor egy előre megadott textúra alapján mornalizál bump mappingnél (rücskök magassága) ha meg Arithmetic ops akkor számol a shader.
pow() Function - hatványozás. Erre spekuláris fények kiszámolásánál van szükség. Arithmetic esetben minden egyes pixelre a shader kód futtatása közben számolja ki. LUT texture esetben először képez egy helyettesítő táblát (look up table - LUT), amiben kiszámolja a lehetséges pow() értékeket. és amikor szükség van rájuk. akkor ebből a LUT-ból a hatványozás paramétereinek megfelelően mintavételez.
sim() Function - Hasonló az előbb tárgyalt pow()-hoz, csak most a Procedural Texturing eseteknél alkalmazott szinusz mintavételező függvény értékeit tárolja le.
FP Pecisionnak csak NV cuccoknál van értelme, ATI mindig 24bitet használ.

Eltérések
A 3Dcenteres grafikonokon látható hogy az új ATI és NV megoldások máshol érzik jól magukat. Más aritmetikai/textúrázó utasítás aránynál az eltérő shader felépítés miatt és eltérően viselkednek a textúrák mennyiségétől függően a 8/1 vs 4/2 felépítés miatt. Szintén másképp kezelik a ciklusokat, az ATI kibontja őket egyetlen hosszú kódba, de éppen a RightMarkosok állítják hogy még így is gyorsabb (ha segítetek, talán kiderül).

Ebben a shader tesztben előjöhet minden, mert a több fény ciklusokban van megcsinálva és a marble/fire hatásokhoz tartozó kód más-más arányban tartalmaz aritmetikai/textúrázó utasításokat. Normalizálás aritmetikai/textúrázási aránya is változik cubenap vagy aritmetika használatától függően, és ehhez jönnek még a sin() és exp() függvényeket kiváltható LUT textúrás esetek. Jó lenne egy részletes teszt, 2×24 egyenként 20 másodperces teszt van benne, lefut durván 16 perc alatt.

Batch fileket elég kitömöríteni és megnyitni a RightMarkkal. Az eredményt mentsétek le html-be, csapjatok hozzá egy pontos konfig leírást (pl. AIAD report), csomagoljátok és küldjétek a minitesztes mailcímek egyikére, köszi!

Eltérések az újabb verzióban
Durván 2KBal hosszabb az új kód. Induláskor két NORMALIZATION_CUBEMAP változót definiál A8R8G8B8 és Q8W8V8U8 formába, továbbá iniciál egy SINUS_LUT és egy POW_LUT változót és egy rm_PI változóban 3,141592654et. Textúrák között értelemszerűen inicializálódik a két új LUT textúra a sin() és pow() függvényeknek és ezekhez két új mintavételező (PowSampler és SinSampler).Van két új függvény, egyik a sin() feltöltésére sin(x-koordináta×pi×2.0) a másik a pow() feltöltésére pow(x-koordináta, 16.0). Bumpmap függvény van A8R8G8B8 és Q8W8V8U8 formákhoz is (tipp: ebben tér el a 2.0 és a 2.a).

A spekuláris fény számolásánál használja a pow()-ot; az új verzióban ez a számolás helyettesíthető a sin((x-koordináta, 16.0) függvénnyel. A régi teszt számolással csinált pow()-ot, arithmetic-el egyezik. Marble és Fire számolásánál használja a sin() függvényt, ez váltható ki a sin(x-koordináta×pi×2.0) függvénnyel. A régi kód itt is az arithmetic-el egyezik. A pow() állításának elvileg nincs értelme a marble és fire esetében, mégis változik az eredmény, ha módosítjuk, gőzöm nincs miért...

Shading_full tesztelről
A 3 diffuse részben első 6 teszt nem változik az eredmény pow() és sin() kapcsolgatásával mivel ott nem használja egyiket sem (majd kiveszem őket a tesztből is - a 4. tesz és az 5. teszt fölösleges). ATInál 16 és 32bit között sincs eltérés, mert végig shader számolás megy ami 24bites (16bitre csak NV3x-ek miatt van szükség).
A 3 diffuse + specular részen nem ódosul az eredmény a sin() kapcsolgatásával, mivel ott nem használja a kód szóval (fölösleges a 10. teszt és a 11. teszt).
Marble és Filre esetében elvileg szükségtelen a pow() kapcsolgatása, gyakorlatban mégis van eltérés, egyelőre marad minden teszt.
Jópár Marble és Fire tesztben van eltérés 16bit és 32bit között ATI kártyákon holott ezek elvileg mindig 24biten számolnak. Az eltérés olyan jellegű hogy ugyanaz a teszt egyik R350es konfigban 16biten jobb a másikban 32biten. Lehet hogy mégis a gép van hatással a kódra, lehet hogy az eltérő driver verzió, lehet hogy én raktam össze rosszul a táblázatot (logikailag ez a legvalószínűbb, pedig már milliószor átnéztem az eredeti reportokat...)

Tesztelés

A RightMark NAGYON ÉRZÉKENY tesztprogram, ezért fontos, hogy MINDENKI UGYANAZOKAT A BEÁLLÍTÁSOKAT HASZNÁLJA! Így nagyon finom rachitektúrális eltéréseket is ki lehet mutatni, olyanokat, amiket a PR esetleg teljesen másképp fogalmaz meg :) Kérek minden kedves tesztelőt, hogy az általam létrehozott batch filehat használja mérésre és a reportokat html-be mentse le, majd tömörítse őket. NAGYON FONTOS a számítógép és a VGA PONTOS MEGJELÖLÉSE, szeretném ha a következő adatok megjelennének, a még pontosabb összehasonlítás végett.
számítógép:
Alaplap gyártója, típusa, chipkészlete (ha tudod) pl. ABIT NF7-S, nForce2
CPU típusa, FSB és szorzó, pl. AthlonXP 190×10
RAM típusa, mennyisége a méréshez használt frekvencia, pl. 2×256MB DDR 190MHz
operációs rendszer és esetleges kiegészítők, pl. WindowsXP pro + ServicePack1
egyelőre úgy látom a VGA alatt lévő vas nem sokban befolyásolja a tesztek többségét, de azért írjátok le!
FONOTS: VGA paraméterei
gyártó és típus , pl. PowerColor radeon 8500LE - R200 (a kártyán lévő chip típusa, nem fontos)
FREKVENCIÁK GPU/RAM sorrendben, pl. 300/240
DRIVERVERZIÓ, pl Catalyst 3.8
méréshez használt minőségjavítók szintje, pl. 4×AA/4×AF FONTOS!!! (sajnos le kell futtatni többször a teszteket és ne felejtsd el megjelölni milyen AA/Af mellett ment a teszt)

Summa summárum, a TÖMÖRÍTETT report tartalmazza a következőket
geom_full batch alapján készített html
hsr batch alapján készített html
shading_full alapján készített html
konfig leírását tartalmazó txt

FAQ
Q: Miért kell 32 és 16bit az ATI kártyáknál shading tesztekben, hiszen azok 24biten számolnak mindig.
A: Azért mert ugyan a shader 24biten számol de egyes shader tesztekben textúra mintavételezéssel váltják ki (LUTos és cubemapos tesztek) a számolást, aminek nem mindegy hogy 32 vagy 16bit (R350nél és RV350nél is voltak eltérések 32 és 16bit között).

Q: Miért fontos annyira a driver verzió?
A: Ha igaz hogy az nVidia Unified Compiler-e általános és nem csak egyes alkalmazásoknál működik akkor eltéréseknek kell lenni egyes teszteknél más-más driververzióval. Általában így követhető a driverek fejlesztésének hatása, majd meglátjuk...

Q: Hogyhogy független a teszt a számítógép teljesítményétől?
A: A fejlesztők igyekeztek úgy megcsinálni a modulokat, hogy csak a vizsgált hardverrészt terheljék. Én is igyekeztem úgy összeválogatni a teszteket, hogy ne forduljon elő limitáltság az CPU vagy AGP vagy bármilyen más hardver felől (nálam 20%ot változtatva a CPU frekijén maximum 4-5% változás történt a geometriai tesztben, a GPU frekijének változtatása viszont szépen visszatükröződött az eredményeken - R200 AthlonXP). Ezzel a lépéssel ugyan elrugaszkodik a teszt a valós helyzetekről, de mégis sokat megtudhat a felszín alatti dolgokról. Feltehetőleg adódnak majd így is korlátozódások (pl. túl sok polygon a lassabb kártyák számára HSRban amikor már a RAM kevés a kitöltésükhöz és nem a Z-technika "fárad el") ezekre majd figyelek.

EREDMÉNYEK - Geomerty Processing Speed


DirectX 7 (Fixed Function)
- az első és legérdekesebb, hogy az NV36-el szerelt 5700 Ultra viszi a prímet! Nagy valószínűséggel az a chip egy az egyben örökölte a nagyobb NV38 geometriai részét és a nagyobb frekvencia miatt őt is maga mögé utasítja.
- az NV35 kétszer olyan gyors mint az R350!
- a lassabbik NV35 kb. annyival lassabb mint amennyivel alacsonyabb a VPU frekenciája - 12%
- R200 durván kétszeresét tudja az azonos frekvenciára húzott RV350 eredményének.
- S3 DeltaChrome csak a leglassabb, NV31-el szerelt FX5600-akkal és az alacsonyabb frekvencián üzemelő Radeon 9600-akkal veszi fel a versenyt.
- érdekes az FX5600 Ultra gyenge szereplése, sajnos nem lehet tudni milyen driverrel készültek a mérések, mindenesetre egy hasonló frekvenciára húzott sima 5600-as sokkal jobb eredményt mutatott.
Ebben a tesztben alulteljesítettek az R3xx chipek. Ez annak "köszönhető", hogy feláldozták a fixed function T&L egységet és a feladatát shaderekkel emulálják (ez látható abból is, hogy a későbbi shaderes tesztekben közel azonos eredményeket hoznak). Az NVIDIA oldaláról jelentős fejlődést láthatunk a közepes kártyáknál

DirectX 8 (Vertex Shader 1.1, Pixel Shader 1.1)
- tovább folytatódik az NV36 szárnyalása, de már jönnek a Radeonok
- NV35 kicsivel (6%) az R350 mögött - mégsem lenne annyival jobb az nVidia DX8ban?!
- clock-for-clock még mindig gyorsabb az R200 mint az RV350, szerencsére a frekvencia alapos emelésével a 9600pro/XT már 20-40%-al elhúz a nagyöregtől
- a DeltaChrome s az NV31-esek lecsúsztak a sor végére, FX5600 Ultra tovább betegeskedik
- A lassabbik NV35 veri az RV350et, vagyis ebben az esetben jobb egy FX5900XT mint a Radeon 9600XT.

DirectX 9es tesztek (Vertex Shader 2.0, Pixel Shader 2.0)
- NVIDIA chipek elvéreznek, még a nagyobb frekvenciás közepes RV350-ek is megelőznek minden NV terméket.
- R350 és RV350 kicsivel gyorsabb DX9ben mint DX8ban (2%), annyi az eltérés hogy DX9ben Loop-olva vannak a VS kódban a fények, amúgy a DX8 és DX9 shaderkód ugyanazokon a feldolgozókon halad végig.
- a DeltaChrome is lassul DX9-be, de ez a lassulás nem olyan nagy mértékű mint a GeForce-oknál
- R350 másfélszer olyan gyors mint az RV350. Igaz az RV350 majdnem másfélszer akkora frekin megy (130%) a RAMok közel azonos sebességgel mentek (337 vs 324). Összehasonlítva a GPUfrekvencia × FPS szorzatot a két chipre: 378×22,9 : 500×15,12 - 8565:7560 arányt kapok.

Konklúzió
- Ezek számolós tesztek, csak a GPU sebessége számít (memóriáé nem). Bandit21 9800as eredményein látni hogy a PRO és XT eredmények között pontosan akkor az eltérés mint a GPU frekvenciák között, ez az arány áll az NV35ös konfigokra is.
- Ha a 9700pro 325MHz-es sebességét leosztom 275MHz-s sebességre (megtehetem, mert arányosan változik: 275×19,52/325 = 16,25) akkor az RV350 eredményeihez nagyon közeli számok jönnek ki 16,25 vs 15,23. Ez magyarázatot ad arra miért közelíti meg annyira a 9600XT sebessége (feles memóriavezérlő ellenére is) a sima 9700at Vertex Shader-igényes játékokban (pl. Splinter Cell). Ebben az esetben az elveszített tranzisztorokat jól pótolja a magasabb frekvencia (lehet örülni, de ne felejtsétek el hogy a 9700nál a lehetséges legalacsonyabb frekivel számoltam, a 275nél jóval magasabban is megy!).
- A 9800SE eredményei modder oldalról közelítve megnyugtatóak - hozza a 9700por szintjét. Tesztelői oldalról közelítve viszont idegesítő miért egyforma a 4 futószalagos és a 8 futószalagos eredmény. Eddig azt hittem ez a futószalagvágás a Vertex Shaderekre is vonatkozik (csak kettő marad meg a négyből), de úgy tűnik, azoknak a száma nem feleződött!
- Az NV35 feltehetőleg a ciklusos kód miatt vérzik el, mert a ciklusoktól eltekintve a DX8es és DX9as kód teljesen megegyezik. NVidiánál feláldozták a sebességet az intelligens ciklusvezérlés és a nagy rugalmasság oltárán. Nagy a gyanú, hogy ATi ezzel szemben favágó megoldást választott, egyszerűen kibontja a ciklusokat egyetlen hosszú kódba, ezért tudja őket DX8as sebességgel feldolgozni. Ez rövid távon hasznos, de így több memóriát és regisztert használ fel, kevesebb hely marad a többi shaderkódnak, több memóriát emészt fel.
- A másik ok az NV35 lassúságára a temp regiszteres kis száma. Sokan ezt tartják az NV35 legnagyobb nyűgének, mert a referencia DX9 kód sok ilyen regisztert igényel.

RÉSZ-Eredményhiredetés:
csúcskártyák: Radeon 9800XT dominál, csak DX7 (esetleg DX8) alkalmazásokhoz jó választás az FX5900.
középkategória: Radeon 9800SE felveszi a versenyt a csúcskategória aljával. Az RV350 alulmarad DX7-8-ban alulmarad az 5700Ultra és az 5900XT-vel szemben, de DX9-ben alaposan odaver nekik. Mivel a mai játékok többsége még DX7-8-as ezért ma (2004.04.03) még érdemesebb közepes NVIDIA kártyát venni játékra. Az DeltaChrome csak a középmezőny aljával tudja felvenni a versenyt.

Összes általam feldolgozott D3D RightMark eredmény megtalálható itt!

EREDMÉNYEK - Hidden Surface Removal


tesztgépek


rizaltsz báj lelkes PH! fórumozók (Bandit21, Divot, Drizzt és többiek) KÖSZI fiúk :D
R200, RV350, R350, NV35 volt tesztelve hasonló konfigokban

- Legnagyobb hatékonyságot az RV350nél mértem, gondolom azért, mert a terhelés növekedésével nő a hatékonyság, R200on mértem 200 polygonnal, ott csak 87%körül volt a hatékonyság.
- A 4/1es felépítés miatt megint az RV350 húzta a rövidebbet, R200 durván 80%al tud többet a kétszer annyi textúrázó (4/2) miatt. Furcsállom az RV350 mélyrepülését, hiszen jobb a memóriaátvitele 36%al és a GPU üzemfrekije 66%al magasabb mint az R200nak, közelebbre vártam őket egymáshoz (és az RV350et előbbre).
- Meglepő hogy mennyivel gyorsabb az R350 a kétszeres memóriabusszal és kétszeres futószalagszámmal.
- NV35 hatékonysága 96% fölött van, de még a gyorsabbik is 78%al lemarad az R350 mögött.
- A lassabbik NV35ös két és félszer gyorsabb az RV350nél hála a 4/2es felépítésnek a 4/1el szemben.
- Radeon 9800SE eredményei itt rendben vannak, már előjön a 4 futószalag hiánya, de valami veszettül, még az RV350 is alaposan megveri! Szerencsére 8 futószalaggal majdnem hozza a 9700pro sebességét (azért csak majdnem mert itt már számít az alacsonyabb RAM freki).
- Ez a rész láthatóan nyers erő teszt, szépen kijön az architektúrák erősorrendje: 8/1 - 4/2 - 4/1 attól tartok a kisebb NVidia megoldások a maguk 2/2jével besorakozhatnának a sor végére...

RÉSZ-Eredményhiredetés:
csúcskártyák: Radeon 9800XT dominál alaposan
középkategória: FX5900XT vezet a nagytestvértől örökölt chip-el, ATi megoldások jól lemaradnak, azért a sikeresen moddolt 9800SE odaver megint, de moddolatlanul gyászosan teljesít.

Összes általam feldolgozott D3D RightMark eredmény megtalálható itt!

EREDMÉNYEK - Pixel Shading

Ez a legérdekesebb része a tesztnek és szerintem itt még finomítani fognak ezt-azt. Elvileg pofonegyszerű kitalálni mikor mi történik, csak az a gond hogy ennek a résznek a kódja nem Shader Assembly, hanem HLSL, amit még a VGAdriver fordít le. A végleges Marble és Fire Shader kód nélkül nehéz megmondani mit mennyire vesz igénybe (ezek a kódok jó eséllyel megtalálhatóak a Render Monkey-ben vagy valahol a weben, majd utánanézek). Egyelőre a fényes rész teljesen világos számomra de a Marble és Fire részben vannak homályos foltok. Néhány tesztet kiveszek az amúgy is hatalmas shading_full batch-ből.

3 Diffuse fény - ez az eset lehet procilimitált, mindkét kártya veszettül kifutja magát

 

- RV350 eredményi nem változtak a pow() függvény kapcsolgatásával mivel nem is használja, Cubemapból normalizálva 20%al gyorsabb mint számolással.
- P4el szerelt R350es Cubemap használatánál durván 5%al gyorsabb mint számolással.
- a Bartonos R350 konfignál Cubemappal ismét 20% az eltérés - az a sejtésem hogy a P4 jobb!!! Jó lenne egy P4 + RV350 teszt...
- NV35 is gyorsabb Cubemappal, de csak minimálisan (2-4%)
- nVidiánál 15-25% eltérés van a 16 és 32bites sebesség között, aritmetikát használva 13-15%, Cubemapnál 20-25% mindkét esetben a lassabb NV35 konfignál volt nagyobb eltérés.
- full aritmetikában 16biten a gyorsabbik NV35 konfig utoléri az RV350et de 32bitben még itt is 17% körüli az eltérés - szép...
- a DheltaChrome 16bites sebessége versenyen van a gyorsabb NV35-el és Radeon 9600pro-val, de 32 biten már csak a gyengébb NVIDIA chipekkel tud versenyezni. A geometriában jeleskedő NV36-ot éri utol. Sajnos az NV36 Pixel Shader oldalon már nem kapott meg mindent a nagytesótól.
- AthlonXPs konfihban, full aritmetikában 32biten az R350 kétszer annyit tud mint az NV35.

Sajnálattal látom hogy NV 4/2es megoldása is csak itt-ott veszi fel a versenyt az ATI 4/1esével (azért segít a +10% freki), a két gyártó csúcskártyája nincs egy súlycsoportban - szomorú.

3Diffuse + Sepcular fény

 

 

 

- specular fények bekapcsolásával az RV350 sebessége a felére esik vissza, normalizálst jobban szereti textúrából, pow()-ot pedig számolásból. Érdekes módon a Cubemap/LUT textúra beállításnál a leglassabb és Cubemap/Arithmetic beállításnál a leggyorsabb, talán a textúra/aritmetikai utasítások aránya itt a legjobb (ennek pontos megállapításához kell a referencia HLSL diffuse és specular fény shader kódja).
- a két R350es konfig itt már közelebb van egymáshoz. Maximális eltérés full aritmetikai esetben van, 18%, többiben durván 3-7%.
- R350 is Cubemanp/Arithmetic esetben a leggyorsabb, P4es konfigban Cubemap/LUT-nál, Barton-nál full aritmetikánál a leglassabb, 13% és 15% eltérés.
- 3 Diffuse és 3 Diffuse+Specular teszt alapján azt tudom mondani, tényleg egyforma sebességet tudnak az ATI chipek 32 és 16biten is.
- 32biten NV35 is Cubemap/Arithmetic esetben a leggyorsabb és Cubemap/LUT-nál a leglassabb. 16biten teljesen más tendenciát mutat: full aritmetikusban a leglassabb, Cubemappal 10%ot, LUT textúrával további 20%ot gyorsul így full textúrázásnál 30%al gyorsabb mint aritmetikában, jó a mintavételezője.
- NV35 32biten harmadát, 16biten felét tudja az előző 3 Diffuse tesztekben mért eredményeknek.
- gyorsabb NV35 32biten 75-175%-al tudott kevesebbet mint 16biten, lassabbnál 81-180% az eltérés (majdnem háromszor olyan lassú!)
- 32biten még az RV350nek sem vetélytársa az NV35, még a gyorsabbik sem. 32biten már össze lehet őket mérni egymással. Full aritmetikában 10%al vezet az RV350, LUT textúrás esetben 16biten 10%al gyorsabb az NV csúcschipje az ATI középkategóriásánál - viccnek is jó, de miért nem nevetek :(
- érdekes hogy mekkora eltérés van a két RV350es konfig között, talán a driververziók miatt...
- 9800SE-nál nagyjából teljesül hogy a 8 futószalagos teszt kétszer olyan gyors mint a 4 futószalagos. A textúra mintavételezős esetekben nincs meg teljesen a kétszeresség, azért mert mind a két esetnél ugyan az a 128bites memóriavezérlő szerepel.
- érdekes a 9800SE és a 9700pro összehasonlítása. Ahol inkább számolás van ott 9800SE jobb (hiszen RV350-rokon), ahol sok amintavételezés ott 9700pro dominál a nagyobb memóriasávszélesség miatt. Ez a RAM-dominancia nem olyan nagy mint a feles memóriavezérlőtől vártam (követi a memória frekvenciáját).
- DeltaChrome a csúcs NV és a közepes ATI chipek sebességét tudja, bár clock-for-clock jobb náluk, de a többiek jóval magasabb frekin is képesek menni. Másik kellemetlen tény, hogy a DCH nem szereti a textúrázós megoldásokat, feltehetően a crossbar memóriavezérlő hiánya miatt. Ennek a ténynek akkor nő meg a súlya, ha számba vesszük, hogy a mai játékokban bevett szokás a LUT és normalizációs textúrák alkalmazása, gyakran még alternatív számolós megoldás sincs helyette.
- picike eltérés van AF és AA bakapcsolása esetén. Alig vannak használatban az egyszerű geometria és a kevés textúrázandó felület miatt.

Ez biza NV oldalról el lett hibázva :( nem számítottam semmi jóra, de ez az eredmény sajnos felülmúlta az elvárásaimat.

Még mielőtt bárki temetné az nVidiát! Ezek a sima fény tesztek távol állnak a valóságtól! Van olyan Fire és Marble teszt is amiben a gyorsabb nVidia konfig a legjobb (igaz csak hajszállal), és gyakran a lassabb NV35ös is megveri az RV350et!


Marble teszt

 

- Itt nincs használatban bump mapping és specular fények, szóval a normalizálás és pow() kapcsolásának hatástalannak kellene lennie. Ez maradéktalanul telesül az NV35nél, de az ATI chipeknél NEM! Annyira nem, hogy van, ahol 16% eltérés van ATInál 16 és 32bit között vagy 17% eltérés adódik Cubemap kapcsolásánál és van olyan teszt is ahol pow() kapcsolásával AhlonXPs konfig lassul, P4es gyorsul! Ezt csak azzal tudom magyarázni, hogy NVnél megmaradtak a régi DX7es T&L utasítások (ezért volt Fixed-Function geometriában annyira gyors), míg ATI ezeket is a Shaderekkel csináltatja (szinte azonos volt a Fixed-Function és a Shader geometria), ezért van, hogy elveszni tűnik valamennyi a teljesítményből, de akkor sem értem miért ennyire rendszertelenül...
- Megint megvan az a tendencia, hogy a lassabb NV35 konfignál nagyobb az eltérés a 32 és 16bit között, az NV35 úgy viselkedik, ahogyan egy hardvernek illik, sem Cobemapra, sem pow()-ra nem reagál.
- sin() LUT textúrát használva az NV35 egyforma gyors 32 és 16biten. Aritmetikai sin()-el, 32biten 48%al, 16biten 21%al lassabb a textúrás változattól.
- Radeon 9800SEnél megint tanácstalanság, megint megmagyarázhatatlan dolgok... volt olyan hogy 8futószalaggal 32biten, 4 futószalaggal 16biten volt jobb eredmény ugyanabban a tesztben a változások nem egyeztek nem a P4es sem az AthlonXP-s R350 tendenciával.
- Feltehetőleg az összes megmagyarázhatatlan dolog az ATI R3xx-es chipek körül (volt olyan is hogy 9800pro gyorsabb volt a 9800XT-nél) annak köszönhető, hogy nincs fixed function egység, ezért több-kevesebb shader teljesítmény elveszik
- ezekben a tesztekben is megközelíti a 9600XT a 9700pro-t!
- a DeltaChrome szárnyalni kezd a teljesen számolós esetben és a LUT textúrázás minimális memóriaigénye sem fogja meg jelentősen, tudja tartani a gyorsabb középkategóriás Radeonokat.
- a végén a LUT textúrás esetben a kisebb az NV36 is összeszedte magát, és beugrott a csúcsmezőnybe. Láthatóan az NV chipeknek nem fekszik a Pixel Shader számolás, de mintavételezni jól tudnak.

RÉSZ-Eredményhiredetés:
csúcskártyák: az NV35 a számára legkedvezőbb esetekben is csak utolérni tudja az R350et. A modernebbnek nevezhető full számolós procedural textúráknál és a kemény fényszámolásoknál csunyán lemarad az NVidia csúcskategóriás megoldása. Aki gondolja, reménykedjen a DX9.1-ben és mindenesetre egyértelműen az R350et tartom a jelenleg fellelhető leggyorsabb VGAnak.
középkategória: FX5900XTben nyugvó lassabb NV35 általában fel tudja venni a versenyt a Radeon 9600XTben dobogó RV350el. Sajnos modernebb számolós DX9 esetekben még itt is hatalmas eltérés van az ATi megoldás javára. A DeltaChrome sebessége egészen jó ha nem kell textúrákkal bíbelődni, de sajnos a valóságban ritkán van ilyen helyzet.

Összes általam feldolgozott D3D RightMark eredmény megtalálható itt!

EREDMÉNYHIRDETÉS

Hangsúlyozom, hogy most D3D RightMark teszteredményekről van szó, amik SZABVÁNYOS DirectX HLSL és alap shader assembler rutinok, architektúrális elemzéshez, optimalizálatlanok. Nekem ezek alapján az jött le, hogy ATi szépen jódiák módjára elvégezte a "DX9 kompatíbilis 3D gyorsító megvalósítása" nevű házi feladatot azzal a trükkel hogy száműzte a fixed function részt és a minimum elvárásokat vette célba. NVidia ezzel eszemben csinált valamit, ami többet tud mint a DX9 alapkövetelményei, de mégis lassabb az ATi megoldásnál. Erre a tanítónéni megveregetheti az NV buksiját hogy "jajjdemilyenkreatív, a holnaputáni házi feladatot csinálta meg" de azt is mondhatja "hát fiam ez nem lett valami fényes, nem ezt kértem, ez holnapután lesz feladva". Kérdés hogy holnapután mit csinál majd az ATI és az NVidia, ha "DX9.1 kompatíbilis 3D gyorsító megvalósítása" lesz a feladat...

Csúcskategóriában egyértelműen R350 (vagy R380 ami csak egy húzott R350, semmi más) a nyerő, egyedül az ősi DX7 megoldásokban bizonyult jobbnak az NV35.

Középkategóriában érdekesebb a dolog, mert kisebb igényű tesztekben jobban teljesít az FX5900XT (van ahol az FX5700 Ultra is) mint a közepes Radeonok. Tisztán DX9 és architektúra oldalról közelítve RV350 jobb megoldásnak látszik, de valós alkalmazásokban más lehet a helyzet! Az S3 DeltaChrome inkább érdekes, mintsem jó megoldás, fő baja az, hogy a teljesítményváltozása nem követi a konkurenciát, ezzel nem nagyon számíthat hasznos optimalizációra.

báj rudi,

ha valamilyen észrevételed vagy kérdésed van a leírtakkal kapcsolatban, írj mailt vagy keress meg a PROHARDVER! fórumán