DirectX10 támogatással rendelkező videókártyák...
-
Abu85 #153 Elég sokat tanulmányoztam a két architektúrát és a D3D10-es újdonágokban komoly a HD2900XT előnye. Az MS féle GI prezentációban, a HD2900XT 55FPS-t megy, míg a 8800Ultra 2-3FPS-t. Ez nem éppen következetes teljesítmény.
Másik topic-ban már beírtam:
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.