L2-es cache a memóriából?

Filterelés

Amikor a 3DLabs azt mondja, hogy programozható, úgy is gondolja. A P10 a renderelés utolsó fázisában sem fix funkcionalitású, ugyanis a különböző filterek és antialiasing (FSAA) módok is programozhatóak, ellentétben a mai GPU-kal. Gyakorlatilag bármilyen AA-ra képes a P10, beleértve az vonalmenti élsimítást (Edge AA) és a super- és multisampling alapú teljes képernyős élsimítást (FSAA). Új feature a 8X-os FSAA.

A P10-zel lehetővé válik a 64 bites színmélységben renderelés, és a 8 helyett 10 bites DAC használata, azaz színkomponensenként (R, G, B) 256 helyett már 1024 színátmenet lehetséges. Ez a digitális fotózás, illetve általában, a képminőség javításának hatékony módja. Ugye emlékszünk még, hogy ez a Longhorn követelményeinek egyike?

RAM szervezés, avagy az L2-es cache

A P10 nemes egyszerűséggel átértelmezi a videokártyán található memória szerepét. Amíg az összes eddigi videokártya a frame buffert tárolta a saját memóriájában, és csak akkor folyamodott az AGP textúrázáshoz, ha mindez nem fért bele, addig a P10 ezt egész másként teszi. A "hagyományos" megoldásnak hátránya, hogy az AGP buszon keresztüli textúrázás nagyságrendekkel lassabb, mint ha azt a kártya saját memóriájából teszi. Abban a pillanatban tehát, amikor a kártya memóriája elfogy, a teljesítmény elfogadhatatlan szinte esik vissza, még 8X-os AGP busz mellett is. Magyarán a játékírók kénytelenek odafigyelni arra, hogy NE használjanak nagyobb textúrákat, mint a játék megjelenésekor standardnak mondható videokártyán található memóriamennyiség. Jelen esetben ez jóindulattal is csak 64 MB.

Csak az kerül be, amit éppen számolunk...

A P10 egyet csavar a dolgon, és azt mondja, hogy a videokártya memóriáját egyfajta L2-es cache-ként értelmezi. Az kerül tehát oda, amin ÉPPEN dolgozik a VPU, minden mást pedig a számítógépünk rendszermemóriájában tárol. Az adatok beolvasása természetesen az AGP buszon keresztül történik. A megoldás azért üdvözölt gyakorlatilag minden nagy név által (például John Carmack és Tim Sweeny, de ide tartozik Bill Gates is :)), mert lehetőség nyílik a 64/128 MB-os textúrák helyett az akár 16 GB-osak (!) használata. A cikk elején említettük, hogy a Longhorn operációs rendszer milyen mennyiségű memóriát igényel majd a gyártók részéről, és erre ez az elegáns megoldás. Mindenképpen van ugyanis egy felső memóriakorlát, amit valahogyan meg kell oldani. Hasonló ez, mint a virtuális memória, ahol a merevlemez kapacitását használjuk arra, hogy az éppen nem szükséges adatokat kiírjuk, és a rendszermemóriában csak azt tároljuk, amivel éppen dolgozunk. Mára a virtuális memória teljesen elfogadottá vált minden operációs rendszernél (nem pálya ugyanis egy "ehhez a programhoz több RAM kell, neked nincs, vegyél még!" hibaüzenet és valóban áthághatatlan felső korlát...).

Talán pont ezért is hívja VMS-nek, avagy Virtual Memory Systemnek a 3DLabs a memóriaszervezését. A feature megint csak a Longhornnál nyer értelmet, ami a nem-profi felhasználást jelenti. Profi 3D-s alkalmazásoknál ugyanis eddig is gond volt a hatalmas számításokhoz rendelkezésre álló szűk memória (128 MB is lehet szűk...), ott tehát biztosan tárt karokkal várják a P10-est.

256 bit

A cikket azzal indítottuk, hogy milyen nagyszerű újítás a 256 bites DDR memóriabusz, és ezt továbbra is mondhatjuk. Fontos azonban látni, hogy a 256 bit miatt még fontosabb a szerepe egy crossbar jellegű vezérlőnek, amely képest a memóriával a 256 bitnél kisebb egységekben is kommunikálni. Tudható ugyanis, hogy a legtöbb adat nem lesz ilyen nagy, ha pedig crossbar szervezés híján egy 32 bites adatokból álló tömböt akarunk a video RAM-ba mozgatni, azt ugyanolyan lassan tudjuk csak megtenni, mintha ugyanezen adatok 256 bitesek lennének (azaz ciklusonként egy adat megy át, akármekkora is az). Ha azonban -- mondjuk 64 bites egységeket feltételezve -- ezt egymástól független egységekkel tudjuk elvégezni, akkor már egyszerre több, jelen példában négy adatot tudunk mozgatni.

A GeForce3 és GeForce4 Ti jelenleg 4 x 32 bites, a GeForce4 MX és a Radeon 8500 pedig 2 x 64 bites vezérlővel rendelkezik, tehát a minimum, ami elvárható a P10-től, az a 4 x 64 bites hozzáférés, ideális esetben pedig 8 x 32 bites -- ha az nem jelent túl komplex megvalósítást. Ellenkező esetben a 256 bites busz olyan, mintha ott sem lenne.

"Röviden" ennyit szerettünk volna mondani a 3DLabs P10-ről a rendelkezésre álló információk alapján. Most pedig lássuk, hogy mire, mikor és kitől számíthatunk!

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