ATI Radeon X800 Pro og XT PE (R420)

Af Thomas Christensen | 12-08-2004 | 17228 visninger | 0 kommentarer

Page 1 : ATI Radeon X800 Pro og XT PE (R420)

Så har vi endelig fået kort bygget over ATI’s nye R420 chip til test. Der er tale om Radeon X800 Pro og Radeon X800 XT PE. R420 chippen blev annonceret den 5. maj, og umiddelbart lød forventningerne til hvornår vi kunne se de 3 kort: X800 Pro, X800 XT og X800 XT PE i handlen positive, ikke mindst for Pro versionen. Nu er det over 2 måneder siden, og XT og XT PE versionerne er stadig langt fra at være på hylderne, og Pro versionen kun i meget få eksemplarer, med ekstremt lange ventetider.


R420 chippen er ATI’s våben imod nVidia’s NV40 chip, og ud fra de første udmeldinger ser det ud til at kampen er mere lige end den har været siden 3DFX var blandt spidserne indenfor 3d-grafikkort. nVidia dominerede med deres først 4 Geforce generationer, hvor ATI’s 2. generation af Radeon kort viste gode takter og ideer, men aldrig nåede at slå igennem. Med R300 og DirctX9.0 ændres det hele, med en velbalanceret chip, som nVidia’s NV3x Geforce FX serie aldrig nåede at indhente. nVidia valgte derfor at starte med en helt nyt arkitektur, imens ATI ikke så nogen grund til at starte forfra. De valgte derfor at basere deres R420 på R360 – R3xx arkitekturen. Det primære mål var ydelse og en velbalanceret chip frem for nytænkning og features. Om dette var det kloge valg kan kun fremtiden vise, og denne artikel handler om hvilke ændringer R420 bringer med sig.

Med R420 har ATI endelig produceret en high end chip bygget over 0.13 mikron produktionsteknologi. Som de fleste husker, var R9600XT (RV360) ATI’s første chip, som benyttede 0.13 mikron produktionsteknologi. Det var deres ”test” chip, og nu benytter de så den erfaring de har, til at bygge en R420, som er opbygget af over dobbelt så mange transistorer i forhold til RV360. Samme mønster er ved at gentage sig med RV410, som bliver deres første chip bygget over 0.11 mikron produktionsteknik. Først prøver de den nye teknologi på de mindre og mere overskuelige chips, og derefter benytter de den erfaring på de store og komplicerede chips.

R420 kernen benytter samme produktionsteknologi, og igen er TSMC deres partner til produktionen. Ligeledes benytter de low k og kobber interconnects. Basalt set giver det bedre elektrisk isolering, som gør det muligt at switche imellem ”on/off” hurtigere, altså mulighed for flere MHz. Skiftet fra 0.15 mikron til 0.13 mikron, betyder dog ikke en mindre kerne, der er billigere at producere end f.eks. R360 - som var bygget over 0.15 mikron produktionsteknik. Kernen er derimod blevet større, hvilket dog er ganske normalt for high end modellerne.

Dette skyldes primært skiftet fra 8 til 16 pipelines, da det udgør størstedelen af transistorerne på chippen. Ligesom ATI’s R360, er R420’s pixel pipelines inddelt i quads – en quad består af 4 pixel pipelines. Denne gang er det 4 quads, modsat 2 quads på R300. De kan arbejde uafhængigt af hinanden, og kan dermed slås fra og til. Dette giver ATI mulighed for at levere R420 kort med 4, 8, 12 eller 16 pixel pipelines. Som sagt fylder pixel pipelinen størstedelen af chippens areal, og hvis der opstår en fejl vil det ofte påvirke pipelinen. Da ATI kan slå quads fra og til, vil de kunne benytte kort, som har en defekt i en quad ved at disable den og sælge kortet som et Pro kort. Siden den er en dyr chip at producere, vil vi dog ikke se R420 i en 8 pipe version, men kun i de 3 nuværende versioner: Pro med 12 pixel pipelines og XT/XT PE med 16 pixel pipelines. ATI tester alle deres chips inden de forlader produktionsbåndet, og ud fra yields og efterspørgsel, sætter de kravene for hvad en XT PE chip skal leve op til. Som produktionen bliver mere moden, og flere chips bliver i stand til at klare XT PE krav, justeres kravene oftest i forhold til efterspørgslen. Så når vi ser Pro kort med 12 pixel pipelines, kan det være pga. en quad enten ikke fungerede eller pga. chippen ikke kunne nå det bestemte MHz mål. Det betyder dog ikke nødvendigvis, at det ikke har 16 fungerende pixel pipelines der kan fungerer ved XT/XT PE’s frekvenser, men bare at det ikke levede op til ATI’s minimums krav.

Det var samme regler der var gældende med R9500, som pga. det havde samme PCB og chip som 9700 modellerne, kunne det ofte laves om til et 9700 kort vha. modifikationer. Disse modifikationer var forholdsvis nemme, og det skadede ATI’s salg af 9700 – selvom det i det store hele kun var et fåtal der udnyttede det. Med R420 benytter de igen samme PCB pga. det er billigere at have et frem for to, og samme chip på Pro og XT/XT PE kort. Det er derfor igen muligt at lave disse modifikationer, men igen er der ingen garanti for at ens kort kan, og ifølge ATI er det blevet lidt sværere siden R300, om end stadig muligt. Hvis vi ser på det totale fravær at XT PE kort og til dels også XT kort 2 måneder efter lanceringen, kunne meget godt tyde på at de har haft svært ved at producere nok R420 med 16 fungerende pixel pipelines, som kunne opererer ved 500+ MHz.

Med R420 har ATI tilføjet to vertex shader enheder, fra 4 til 6. Sammen med en højere frekvens, har det fordoblet kortet teoretiske vertex shader ydelse i forhold til R360. Siden chippens mål har været ydelse, frem for features, er det basalt set de samme vertex shader enheder vi finder i R420 – og dermed vertex shader 2.0. De har dog tilføjet muligheder for SINCOS instruktioner i en clockcyklus. De 6 vertex shadere operer ved 32bit floating point præcision.

Ligesom vertex shaderen, er pixel shaderen basalt set den samme som i R360. Det er stadig en PS2.0 kerne, men ATI har tweaket den lidt. Først og fremmest har de øget antallet af temporary register fra 12 til 32. Modsat R360 understøtter chippen nu op til 512 instruktioner for vector, scalar og texture ALU’erne – som tidligere blev lovet via ATI’s F-buffer, men aldrig blev understøttet i driveren pga. der ikke var efterspørgsel efter det. DirectX9.0c består af 3 shader model profiler: PS2.0 (R3xx), PS2.0a (NV3x) og PS2.0b (R420). Forskellen ligger i features, registrer, antal instruktioner osv. – det har intet at gøre med hvilke effekter man kan lave.

Her er det dog vigtigt at huske, at flere instruktioner ikke nødvendigvis er hurtigere, og i mange tilfælde vil få kortere shader instruktioner være hurtigere. Selv de nyeste/kommende og mest krævende spil som Far Cry, HL2, Doom III osv. er ikke tæt på at ramme loftet. Udvidelserne i at gå fra SM2.0 profile 2.0 til 2.0b handler mere om at give udviklerne et højere loft, end noget vi reelt skal regne med bliver udnyttet på de game engines vi vil se den kommende tid. Det samme gælder for forskellen imellem PS2.x (profile 2.0b) og PS3.0, hvor PS3.0 har et langt højere loft, men hvor fordelene ligger i features og ikke i muligheden for længere shader instruktioner. Til sammenligning benytter ATI’s Ruby demo maksimalt omkring de 100, og det er en del højere end de game engines der er på markedet.

ATI’s F-buffer, som benyttes til at lagre data der skal igennem flere clock cyklusser for at blive udregnet, er også ændret. Den vil nu kun hente data der reelt har brug for flere passes, i stedet for at lede efter shaderer der bruge flere clock cyklusser i hele framen. Det gør at den bedre kan styre store dele data, hvor den før skulle dele det op i mindre dele. Her er en af grundene til at de kan hæve antallet af shader instruktioner.

ATI's velkendte Hyper Z har også fået et par tweaks. Dette er specielt i forbindelse med at den skal kunne skalerer med de forskellige quads. I stedet for at ATI måtte disable deres Z-Buffer når der er nogle quads der er disabled, som de gjorde på R9500, kan de forskellige Z-buffer agerer uafhængigt på quad niveau. Dette gør det muligt, at benytte den i højere opløsninger. Nu kan den klare helt op til 1920x1080 eller 1600x1200. Det skulle hjælpe ydelsen lidt i de høje opløsninger.

3Dc
De fleste kan sikkert huske, da bump mapping blev introduceret i DirectX7.0 – ikke mindst igennem 3DMark’s feature tests. Groft sagt var formålet at give overflader mere dybde. I stedet for et texture lag, bliver flere lag benyttet til at lave en overflade, og dermed skaber illusionen af forhøjninger og dybde. Normal maps er en videre udvikling af konceptet, som nu også benytter z aksen. Det kan f.eks. bruges til at nedsætte polygonkravet, da en udvikler kan lave en effekt med et højt antal polygoner og et med et lavt antal polygoner. Udfra de to forskellige modeller, bliver forskellen imellem de to effekter udregnet, og lavet om til et normal map. Dette normal map kan sammen med lav polygon billedet, give effekten af billedet med det høje antal polygoner. Det gode er at det giver færre polygoner, men det vil derimod kræve større textures.


Hidtil har udviklerne brugt DXT5 (DXTC og S3TC fra henholdsvis Direct3D og OpenGL) til at komprimere textures og på det seneste også normal maps. Der har dog været problemer med at benytte DXT5 til at komprimere normal maps, da de har problemer med at gemme alle data korrekt. Når de ikke får komprimeret dem alle helt korrekt, bliver data beregnet forkert, og giver ikke helt så skarpe textures/normal maps. Jo større normal maps, jo mere synlige bliver disse småfejl. Det har i høj grad hæmmet udbredelsen af normal maps i game engines, da det koster for meget ydelse uden komprimering, og ved komprimering opstår der fejl. Det er de primisser 3Dc prøver at ændre, så normal maps kan komprimeres uden disse fejl, og dermed gøre det muligt at benytte normal maps i langt større grad end tidligere.

Ideen er derfor langtfra ny, og det er reelt set en videre udvikling af DXT5 (DXTC og S3TC fra henholdsvis Direct3D og OpenGL). Det skal dog lige siges, at 3Dc ikke kun hjælper ved normal maps, men normal maps er primær fokus for 3Dc – i det mindste i starten, da normal maps er i brug i mange eksisterende game engines, og dermed forholdsvis nemt kan opdateres, så de bliver komprimeret via 3Dc. ATI har udviklet et tool, så udviklerne kan komprimere deres normal maps, så det fylder mindre og RAM kravet bliver mindre. I game engines der i forvejen benytter normal maps, vil det dermed være forholdsvis nemt at implementere. Desværre er normal maps ikke så udbredte pga. de eksisterende komprimeringsteknikker har problemer med normal maps, og udviklerne har dermed været meget selektive med hvor normal maps er blevet benyttet.


- Dette billede prøver at vise forskellen imellem at komprimere med 3Dc og DXTC, hvor sidstnævnte giver et mere firkantet og upræcist billede end 3Dc.
3Dc er udviklet til at komprimere data med 2 komponenter (x og y), hvor normal maps består af 3 komponenter (x, y og z). Dette giver en ny problemstilling, da z værdien ikke kan gemmes sammen med x og y værdierne vha. 3Dc. Inden X og y værdierne bliver komprimeret vha. 3Dc, bliver z værdien derfor gemt og derefter skal der bruges et par clock cyklusser af kortets shader enhed, for at udregne den. Det kræver altså 1(+) clock cyklusser for at beregne denne værdi, og dermed have de 3 værdier for normal map'n. Basalt set handler det om at spare på RAM båndbredden, ved at ofre lidt shader arbejde, da grafikkortet hungrer efter RAM båndbrede og samtidig har en kæmpe fill rate og shader ydelse til rådighed.

Umiddelbart bliver det markedsført som en 4:1 komprimering, men det krævede som sagt 1(+) clock cyklus af shader delen, for at have den dertilhørende z værdi. Det er denne 4:1 komprimering der vil blive brugt i forbindelse med normal maps, men som sagt kan 3Dc bruges til andet end normal maps, og her vil der blive brugt en 2:1 komprimering. Modsat normal maps 4:1 komprimering, vil 3Dc kunne komprimere alle slags 2 komponents data, og uden at bruge en ekstra clock cyklus – da z værdien selvsagt ikke er nødvendig når vi snakker data der kun indeholder x og z værdier. Af konkrete eksempler nævner ATI at benytte den til skinnende, brydninger af lys, gennemsigtige overflader, ru overflader osv.

3Dc giver dog i sig selv ikke bedre grafik, som ATI’s billeder ellers kunne antyde, men i stedet mulighed for at lave en komprimering med mere detaljerede normal maps uden fejl – derigennem mulighed for bedre grafik eller ydelse (jo mere data du kan komprimere, jo flere detaljer er der plads til). Udviklerne slipper af med den uskarpe grafik DXT5 forudsagede, når den blev brugt til at komprimere normal maps, og giver det dem mulighed for at bruge normal maps til langt flere overflader end før.

Det skulle desuden være forholdsvis nemt at benytte sig af normal maps komprimering via 3Dc, og ATI nævnte bl.a. at Croteam (folkene bag Serious Sam serien) på ganske få dage havde udnyttet denne teknologi, og lavet en demo i deres Serious Engine v2.0 (den de benytter til Serious Sam 2). Det er også billeder derfra ATI benytter i deres materiale – sjovt som alle nævner Serious Sam 2 i denne forbindelse. At det ikke er en helt ny måde at tænke på, men bare en videreudvikling af eksisterende teknik, har helt sikkert hjulpet folkene på Croteam, som tidligere har benyttet S3TC i deres Serious Engine.

Udviklerne har dermed mulighederne for enten at lave tilsvarende effekter hurtigere, eller lave bedre effekter ved samme ydelse. Da det altid handler om at benytte ydelsen de rigtige steder, dvs. der hvor man med mindst krav kan hæve mest, vil det ikke være tale om en enten ydelse eller billedkvalitets situation, men en blanding – hvilket også er tilfældet med med Far Cry og shader model 3.0 patchen.

I kampen om forbrugernes opmærksomhed, er 3Dc ATI’s modsvar til nVidia’s NV40 shader model 3.0 understøttelse. Begge løsninger giver ikke automatisk bedre grafik eller mulighed for at lave nye effekter, men i stedet giver det udviklerne mere fleksibilitet til at lave nogle effekter lidt hurtigere (eller bedre ved at benyttede den sparede ydelse). Det er heller ikke features, som vi som bruger kan benyttes i game engines vi har på markedet pt., og begge kræver DirectX9.0c. Indtil videre har shader model 3.0 vundet kampen om mindshare. Nu vi er ved mindshare, så er 3Dc også en del af deres HD (high definition) buzz word kampagne, og helt præcist kalder de det HD gaming.

3Dc er en åben standard, som alle kan benytte – dvs. nVidia, XGI osv. kan tage 3Dc til sig uden at skulle give et kæmpe beløb til ATI. Hvorfor udvikler ATI så teknologi og giver den videre til nVidia osv.? Vi har ikke det endelig svar, og ATI gør det jo selvsagt ikke uden at kunne se fordele i at det er en åben standard, så vi har kun spekulationer. ATI lærte ved R200/Radeon 8500 serien, at spiludviklerne kun vil understøtte en given feature, hvis markedet tager den til sig (PS1.4 specielt). For spiludviklerne vil det være langt dyrere at lave forskellige tilpasninger til forskellig hardware, og hvis en given feature vinder udbredelse hos både ATI og nVidia, vil de også have mere ud af at benytte den i deres spil. Så for at få spil udviklerne til hurtigere at adoptere 3Dc bliver ATI nød til at overbevise alle om at det er en god teknologi, og dermed at nVidia kan benytte den. Da nVidia ikke sådan lige kan benytte 3Dc, vil ATI alligevel stå som eneste spiller med 3Dc teknologi på kort sigt, på trods af at det er en åben teknologi. Derudover giver det også ATI muligheden for at skabe en standard, som passer til deres teknologi, i stedet for at skulle lave en standard som nVidia har medbestemmelse på. Dermed kan det formodes at have hjulpet ATI med at få det ind i DirectX som en standard. Microsoft har en stor interesse i at det ikke bliver en specifik ATI feature. Det er da også en del af DirectX9.0c opdateringen (samt OpenGL via producent specifikke extensions). Det er samme opdatering, som giver mulighed for shader model 3.0 på nVidia's NV40, og spil patches vil følge i kølvandet. ATI har også markedsført sig selv som "brugernes ven" ved at promovere afprøvede standarder og ikke mindst åbne standarder, frem for at lave "deres egne" løsninger - f.eks. GDDR3, AXIOM og den mere inddirekte fokusering på Direct3D/Microsoft.

Spil som Serious Sam 2, Half-Life 2, Sid Meier’s Pirates, Tribes Vengeance, darkSector, Far Cry samt mange flere vil udnytte 3Dc. Ifølge ATI vil det være en standard feature i slutningen af året. Vi så desværre ikke en Half-Life 2 3Dc demo, men måtte nøjes med Ruby og Serious Sam 2. Og lad os da se et par PR billeder fra Ruby demoen og Serious Sam 2 med 3Dc:


- Du kan hente 7 billeder fra Ruby demoen her (en .zip fil der fylder ca. 7.2MB)


- Du kan hente et lidt større billede med lidt bedre nuancer her
Igen er det vigtigt at pointere, at 3Dc ikke øger detaljerne, men kan spare RAM båndbrede og reducere fejlene ved DXTC og S3TC. På billederne har de brugt den sparede RAM båndbrede til at hæve kvaliteten (og evt. udnyttet at det nu er muligt at bruge normal maps i langt større grad uden fejl), og derfor ser vi en visuel forskel på billederne, og ikke pga. 3Dc i sig selv forbedrer billedkvaliteten – ligesom det er tilfældet med Shader model 3.0 og NV40. Det bliver spændende, at se hvordan udviklerne vælger at benytte 3Dc, først og fremmest til normal maps kontra andre overfladeteknikker, og ikke mindst ydelsesforskellen. Dernæst hvordan de benytter den sparede RAM båndbrede; hurtigere ydelse, flere detaljer i det komprimerede eller om de benytter den sparede RAM båndbrede på andet end de komprimerede data.