Memóriavezérlő és SmartShader HD

A memória kezelésével kapcsolatban érdemes kitérni a sokat emlegetett crossbar vezérlőrendszerre.

Látható, hogy a 256 bites memóriabusz négy darab 64 bites egységre van osztva, mondhatni inkább négycsatornás 64 bites megoldásról van szó. Miért jó ez? A grafikus chipen belül nagyon sok egységnek van szüksége memóriára és általában nem teljes 256 bites blokkokra, hanem 32 bitesekre (32 bit színmélységű pixel). Ha egy egység bitorolná a teljes sávszélességet, akkor a többieknek várniuk kellene, míg az összes csatornát elfoglalva letölt 256 bit adatot (vagy ennek egész számú többszörösét), amelynek jelentős részét fel sem használná, mert csupán egy 32 bites pixelre van szüksége. Sokkal jobb megoldás, ha csak a csatorna negyedét kapja meg és mellette még hárman dolgozhatnak.

Természetesen a megvalósítás ennél bonyolultabb, mert a pixel futószalagok általában négyesével emésztik a pixeleket (quadokban) és a textúra-mintavételezési eljárások is egyszerre több pixelt olvasnak ki a memóriából, de az S3 DeltaChrome esete bizonyítja, hogy mennyivel gyengébb egy nem crossbar memóriakezelési rendszer. Amint sok apró 16 vagy 32 bites egységet kellett olvasni a D3D RightMark tesztekben, máris felére esett vissza az S3-chip teljesítménye, míg a crossbaros konkurensek sebessége nem csökkent.

A crossbar rendszer nem csak memóriakezelésre használható. Az NV40-nél megfigyelhetjük, hogy a pixel futószalagok és a raszterizáló egységek (ezek végzik az AA-t és a Z-tesztek egy részét) között is crossbar kapcsolat van. Ez a megoldás általánosan használható olyan helyeken, ahol párhuzamos egységcsoportokat kell egymáshoz illeszteni. Logikus a módszer alkalmazása, ha a két oldalon eltérő számú egységet kell összekapcsolni (4 memóriacsatornát a négy memóriavezérlővel és egy AGP busszal), de miért jó 16 pixel futószalag és 16 raszterizáló egység közé, miért nem teszik inkább a reszterizálókat egyenesen a pixel futószalagok végére? Az ok a változó feldolgozási idő. Ha a pixel egység mondjuk 10 ciklus alatt végez a feldolgozással és a raszterizáló három alatt, akkor a pixel futószalag végén csücsülve 7 cikluson keresztül lógatná a lábát, nem dolgozna. Crossbarra kötve a három munkaütem után lelkesen felteheti a kezét, hogy kész, és várhatja az adatot a további 15 futószalag bármelyikéről. Ennek a módszernek hatalmas kiegyensúlyozó hatása van, mert a pixel egység és a raszterizáló feldolgozási ideje is tág határok között változhat egymástól függetlenül.

Az R420 annyira a jó hagyományokra épít, hogy az általános felépítést mutató blokkdiagram sem változott sokat az R300 óta:

R420, 2004

R300, 2002

Smartshader HD

Szinte érintetlenek maradtak a vertex shader egységek is, csak a számuk nőtt négyről hatra, de a gyártó kétszeres sebességet ígér a korábbi R360-hoz képest. Egyetlen új tulajdonságuk, hogy most már tudnak egy ciklus alatt sin és cos függvényeket számolni (ilyet tudott az NV3x de az NV40-ből kivették, mert hatékonyabbam számolható előre elkészített egydimenziós textúrából mintavételezéssel – lásd D3D RightMark tesztek az S3 DeltaChrome-bemutatóban). A pixel shaderek terén már nagyobb változásokat találunk. Először is megkettőzték a számukat, most már 16 futószalag dolgozik a képpontokon. Az NVIDIA-hoz hasonlóan, az ATI-nál is felmérték, hogy sokkal több számolásra van szükség a shaderekben, mint textúrázásra, ezért két számoló és egy textúrázó egységet helyeztek minden futószalagra. A számoló egységek – akárcsak az NV40-nél – itt is egy vektor és egy skalár egységből állnak, de a textúrázó teljesen független ezektől. Az architektúra még a borzasztóan erősnek tartott NVIDIA-megoldást (6,4 Gigapixel) is lekörözi maximális 8,8 Gigapixeles fill rate-jével!

Beigazolódtak a korábbi pletykák: az R420 nem támogatja sem a Vertex Shader 3.0, sem a Pixel Shader 3.0 modelleket, csak a korábbi kettes verzió kibővítését: 1536 PS-utasítással és az NV40-nel megegyező számú (32) ideiglenes regiszterrel. Az új chip tehát nem tud Displacement Mappinget (lásd itt), ám tud valami radikálisan újat. Ez pedig egy reményteljes új textúratömörítési eljárás, a 3Dc.

A cikk még nem ért véget, kérlek, lapozz!