Informatika és tudomány

  • Abu85
    #1443
    Szerinted az nV nem tudna önmagától DX10.1-es VGAt tervezni?

    Elég rossz dolog, hogy nem használjuk a DX10 és DX10.1-es eljárásokat. De ennek oka van. Az nV-nek az a jó, ha Crysis-t ostromló gépigények vannak a játékoknál.
    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 GT200 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 a szögfüggő 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 GT200 igazából egyetlen dolgot épít be, a GPGPU-nál hasznos double-precision-t amit a GT200 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ázná a GT200-akat. 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.