Elég megvizsgálni a két architektúrát és látható, hogy mi miért van. A D3D10-nek fõleg a skalár stream procik felelnek meg a legjobban. Ezek SISD Alu-k, tehát ''1 utasítás 1 adaton'' elvûek. Az AMD és az nV is ilyen Stream procikat használ, mindkét rendszerben MAD, MUL, ADD utasítás lehetséges float adattípusra (integer adattípusra pontosan nem tudom, hogy milyen mûveletett tudnak, de ez nem túl lényeges, mert mindenki float-t használ). Ezen kívül a D3D10 lehetõséget ad trigonometrikus és transzcendens utasítások elvégzésére. Ezeket az SFU (Speciel Function Unit) egységek végzik. Itt van némi változás az nV és az AMD SFU egységei közt. Az AMD SFU egysége a spec. utasításokon kívül MAD, MUL, ADD utasítást tud, így lényegében használható általános stream processzorként, míg az nV SFU-ja stream prociként MUL utasítást tud, illetve 4 órajelciklus alatt végez egy mûveletett, tehát 4x lasabb a stream procik sebességénél. A két rendszer elrendezése is eltérõ. Az AMD 4stream+1SFU alapú shader procikat használ, ezekbõl 4 darabot mûködtet egy clusterben és VLIW mintával etetik õket (a VLIW lényegében egy architektúra az a fontos, hogy a VLIW minta egy nagy memóriaszó ami leírja az egységeknek a mûködést, illetve ezeket a szavakat a fordító hozza létre). Az nV egy shader procijában 4+4darab Stream proci van egymással párhuzamosan kötve, és ezekhez a 4-es csoportokhoz kapcsolódik egy-egy SFU egység (tulajdonképpen ez totálisan a float2 adattípushoz lett tervezve, nem véletlen, hiszen jelenleg ez az adattípus dominál a shader programokban).
Ami viszont probléma, hogy nem tudjuk milyenek lesznek az új játékok. Minden D3D generáció váltás új elképzeléseket szül. Ezek akkor jók ha fokozatosan lesznek bevezetve. Ilyen volt a D3D7-D3D8 áttérés. Ellenben a Hát a D3D8-D3D9 váltást némileg akadályozta az FX karik képességei. Ez sajnos nem következetesen ment végbe. Az nv tartotta a fejlesztõket addig míg ki nem jött az új szériája és utána bumm, jött a drasztikus teljesítményesés. Persze ez csak az FX tulajokat érintette rosszul. Akkor is kivolt kövezve egy út amit az MS és a fejlesztõk elképzeltek, de csak késõbb tudták alkalmazni. Most is van biztosan elképzelés a jövõ megoldásairól, az a probléma, hogy nem tudjuk mi az. Az egyik véglet az, hogy maradnak a jelenlegi megoldások és a jelenleg mutatott teljesítmény lesz mérvadó. A másik véglet, hogy elmennek a fejlesztõk az AMD elképzeléseinek az irányába és a G8x teljesítménye drasztikusan visszaesik, mint anno az FX-nél. Remélhetõleg valamilyen köztes kompromisszumot választanak és azzal a felhasználók is jól járnak.
Az Microsoft felfogásában minden bizonnyal a Xenos-hoz közelebb álló R600 az a 3D-s gyorsító amit elképzelt az új API igényeihez. Mindenesetre a mostani játékokban az R600-ra jellemzõ irányelvekkel jelenleg ezt a teljesítményt lehet elérni (plusz optimalizált driver rutinok amik még tényleg gyerekcipõben járnak, fõleg D3D10-ben). A D3D10 minden eddiginél jobban épit a shaderekre, ezért is problémás, hogy a két gyártó elképzelései nagyon széthúznak. Mondok egy példát. Olyan Shader kódot írunk amiben trigonometrikus (például sinus) függvény van. D3D9-ben az API adotságai miatt LUT (Look-Up table) texturát használunk, hogy kikeressük a megfelelõ eredményt, ehhez szükség van textura fetch-re ami igen nagy idõveszteség a memória címzése végett. D3D10-ben lehetõség van speciális utasítások elvégzésére, mint a sinus (sin). Ezt a GPU SFU egysége hajtja végre és meg is van az eredmény. Két eltérõ megoldás és a jelenlegi D3D10-es karikkal mindkettõ kivitelezhetõ. Hol itt a probléma? A LUT texturás megoldás a magas Alu:Tex arányú kialakítás végett nem nagyon fekszik majd az R600-nak. A G80-ban viszont az SFU egység jelentõsen lassabb a Stream prociknál, így az nV üdvöskéje a számolós megoldást nem szívlelné. Mi a teendõ? Vagy kiszúrunk az egyik gyártóval, vagy leprogramozzuk mindkettõ algoritmust. Az MS a D3D10-es API-val a számlálós megoldást próbálná erõltetni, hiszen a textura fetch nélkülözése miatt jelentõsen gyorsabban van eredmény.