Elég rossz dolog, hogy nem használjuk a DX10 és DX10.1-es eljárásokat. Alapvetõen Crysis-t ostromló gépigényekre lehet így számítani. Az a baj, hogy egy helyben toporgunk, és hasonló eljárásokat használunk most is, mint 2 éve. Ezen a jelenlegi G80 alapú és feltételezhetõen a G200 architektúra elve sem fog változtatni. Azért alakítják ki a DX10 és fõleg a DX10.1-ben az új eljárásokat, hogy alkalmazkodjanak a grafika fejlõdésének írányához. Ezt úgy kell értelmezni, hogy a háromdimenziós grafika fejlõdése meglehetõsen kötött. Alapvetõen ismertek azok a technikák amik a közeljövõben és a távolabbi jövõben használni fognak, de az alkalmazott eljárások addig megváltozhatnak, mert lehet, hogy valaki talált gyorsabb algoritmust ugyanarra a feladatra.
Mondok egy példát, hátha úgy egyszerûbb megérteni. Manapság vagy a nagyon közeli jövõben elterjedt lesz a Parallax Occlusion Mapping (ilyen van a Crysis-ba, az új 3Dmark Vantage-ban) alapú technikák. Alapvetõen a technika leképzésére már a DX9 is kínált megoldást, de az akkori karik lassúak voltak hozzá. Ugyan még a mostani VGA-ak sem szerepelnek valami fényesen ennél az effektnél, de már érdemes erõltetni a POM leképzéséhez, így terjed a technika (SLI, CF tulajok örülnek). A csavar ott jön be, hogy a DX10.1 tálal a POM leképzésére egy, az eddigieknél, jóval gyorsabb megvalósítást a LOD utasítások segítségével. Ha az nV támogatná a DX10.1-et akkor a POM vélhetõleg mindenhol LOD utasításokkal lenne létrehozva a jövõben. Ezzel jól járnának a fejlesztõk, mert a LOD utasításokkal egyénileg definiált szûréseket lehet alkotni, így a POM nem akasztja majd össze a bajszát az AF szûrésekkel, jó lenne a felhasználóknak, mert a látvány gyakorlatilag ugyanaz, de a sebesség az ésszerû és átgondolt algoritmusnak hála gyorsabb.
Hogy ne csak egy példa legyen ott van még a leképzési fázisok esete. Például a Quake 3-nél úgy volt a renderelés, hogy volt egy fényszámítási fázis, majd egy árnyaló és utána még egy fényszámítási. Nem meglepõ a dolog, hogy ez eléggé erõforráspazarló, hiszen kétszer végzünk minden modellen fényszámítást. Ez a példa a Quake 3 utáni években még bonyolultabb lett. Ám a Shader modell segítségével van megoldás a problémára: Deferred Rendering, ez is elterjedt lesz nagyon. A lényege egyszerû, üssük ki a felesleges munkavégzést. Le kell számolni a képet megvilágítás és árnyalás nélkül, majd a kimaradt munkát utólagosan feldolozni több Render Target-be. A Shader Modell elég komplex ahhoz, hogy jó eredményeket lehessen elérni. A probléma az AA-val és a Deferred Rendering fázisokkal van. Az AA már sokszor volt tárgyalva ez az MS sara bele kellett volna tenni a megoldást a DX10-be. A Deferred fázisoknál viszont továbbra is gáz, hogy a GPU nem dolgozhat rajtuk párhuzamosan. A DX10.1-ben ezt emgoldották, így a Deferred Rendering technika leképzéséhez redukálva lett a fázis igények száma, így nõtt a sebesség. Megint jó a fejlesztõnek és a felhasználónak a dolog, mert a programozónak egyszerûbb dolga lesz az optimalizálással és az AA gondok megoldásával, míg a felhasználó örülhet, hogy gyorsabba megkapja ugyanazt az eredményt.
Persze az elméletet folytathatnánk tovább a Cube Map tömbökre is. Egész érdekes dolgokat lehet a technikával leképezni. Természetesen itt is elõnyt élvez a DX10.1-es megvalósítás, mert a DX10-ben minden Cube MAP tömböt külön fázisban keleltt számolni, mí a DX10.1-ben párhuzamosan is elvégezhetõ a feladat a GPU erõforrás kapacítására optimalizálva. Az eredmény ugye megint jó a fejlesztõnek és a felhasználónak, az okok hasonlóak a fentiekhez.
Az, hogy az nV nem támogatja a DX10.1-et és akadályozza az új algoritmusok terjedését csak rossz a fejlesztõknek és a felhasználóknak is. A fejlesztõ továbbra is eszeveszetten fog optimalizálni... De minek ugye? Ki jön a program (Crysis) és mindenki leszarozza, hogy egy optimalizálatlan szutyok, a kor szégyene. Pedig jól van optimalizálva, mert amit ki lehetet, kihozták belõle. A felhasználó extra rosszul jár, mert minden évben VGA-t kell vennie.
Egy valaki jár jól, az nV. El tudja adni az új cuccait, az egyre gyengébb PC-s játékipart látva is.
A DX10.1 támogatásra az nv-tõl nem számíthatunk soha. Egy korszerû DX10.1-es megvalósítás gyökeresen más elvû architektúrát igényelne (kb. olyat, mint az R600-ra építkezõ rendszerek). Persze nem korszerûen is meg lehet oldani, ezesetben az nV TPC féle felépítése is jó. Alapvetõen szükség lenne a Gather 4 támogatásra, ehhez a chipben elõforduló mintavételezõk számát meg kellene négyszerezni (ez elég sok plusz tranyó). Kisebb változások kellenének a ROP blokk-ok terén, a Blending hatékonyabb hassználatához. Plusz a Multisample Buffer használata mellett nem árt egy optimalizált vezérlés a hatékony AA-hoz.
A G200 igazából egyetlen dolgot épít be, a GPGPU-nál hasznos double-precision-t amit a G200 elméletben 1/8-ad sebességgel végez. Ez tulajdonképpen elég lassú, mert az RV670 1/2-ed sebeséggel csinálja ami jóval hatékonyabb. Itt jön ki az a tervezési irány ami az RV670 alapú chipeket nagyon magas precizítású számításnál iszonyat hatékonnyá teszi.
Üzletileg sem érné meg a DX10.1 támogatás az nV-nek. Egyrészt nem egy esetben olyan face-to-face összehasonlítást eredményezne az új API támogatása a HD Radeonokkal ami kihozná a GF architektúrák gyengeségeit. Nagy adatmennyiséggel dolgozó GS feladatok esetén még az HD3650 is szépen elpicsázzná a régi G80/G92-re épülõ chipeket. Másrészt a DX10.1 számtalan helyen egyszerûbb és gyorsabb algoritmusokra ad lehetõséget a fejlesztõknek. Nyilván ezzel a módszerrel csökkenne a játékok gépigénye és az nem tesz jót a jelenleg jól tejelõ üzletnek.
Azt már régebben megmondtam, hogy a GF architektúrája nem tudja hosszú távon tartani a lépést a HD Radeonnal. Most jönnek azok a programok ahol magasabb ALU:Tex arányt használnak a fejlesztõk, mert a memóriasávszélesség nem elég a Fill-Rate értékek kielégítésére, így elmennek az ALU teljesítmény használata felé. Ezek után lesznek használva masszívan a PipeGS eljárások ahol az nV technikája le van maradva. Bár a G200 ezen sokat javult, nyilván látta az nV is, hogy pár fejlesztõt nem hat meg a G80/G92 képessége, így meg kellett növelni a teljesítményt, még akkor is ha az eléggé pazarló a chip tranzisztorszámára nézve. Jelenleg Emil Persson GI demójában alig teljesít 5 FPS-t a teljes GF8-9 paletta, míg a HD Radeonokból még a 2600 széria is hozza a 20-25FPS-t. Látható, hogy a Frostbite engine-ben is mérföldekkel van lemaradva a 8800GT és a 9600GT a HD3870 mögött a PipeGS teljesítményben. A G200 ezen a területen nagyon sokat javult, a GI demóban 35-40FPS-re képes, ami már R600 szint.