Direct3D 10 - API -funkciók készlete a videokártyával való interakcióhoz; NV GeForce 8x00, ATI Radeon 2x00 és újabb videokártyák támogatják. A Direct3D 10 (D3D10) a Direct3D 10. verziójának, a Direct3D 10. verziójának, a Direct3D 9 utódjának, a DirectX 10 alkalmazásprogramozási felület (API) összetevője. A Direct3D 10 funkciókat biztosít az operációs rendszer és az alkalmazások videokártya-illesztőprogramokkal való interakciójához. Ezek a szolgáltatások operációs rendszer-specifikusak a Windows vonalon, és elérhetők a Windows Vista és a Windows 7 rendszerben . A D3D10 részben Direct3D 9 szintű videokártyákon működik.
A hivatalos végleges verzió 2006. november 10-én jelent meg a Windows Vista részeként .
Az alábbiak a főbb jellemzők és különbségek a Direct3D 9-es verziójához képest.
A Windows Vista rendszerben egy teljesen új illesztőprogram-modell, a WDDM ( Windows Display Driver Model , korábban LDDM – Longhorn Display Driver Model) jelentős változást jelent a videó-illesztőprogram modelljében a hardveres gyorsítás megjelenése óta. Az XDDM-ben ( Windows XP Display Driver Model) minden DirectX -hívás egy parancsmutatót (token) adott a parancspufferhez videokártya-független formátumban. Amikor a DX Runtime úgy döntött, hogy a puffer elég tele van, egy illesztőprogram-függvény ( kernel módban ) meghívásra került a puffer lekéréséhez. Ezt követően az illesztőprogram elemezte ezt a puffert, és átvitte az adatokat a videokártyára. Vagyis felhasználói módban nem voltak illesztőprogram-funkciók . A videokártyák fejlesztése és ennek eredményeként a parancspuffer bonyolultsága oda vezetett, hogy az illesztőprogram elképzelhetetlenül nagy lett, és bármilyen hiba esetén BSOD -t provokált . Az XDDM-ben sem az operációs rendszernek nincs módja prioritás beállítására, videomemória kezelésére, DX-hívások ütemezésére, ami megnehezíti a videokártya megosztását több folyamat között – ez az "eszközvesztés" oka.
Az új illesztőprogram-modellben az illesztőprogram felhasználói része és kernel módú része szétválik. Minden DX hívás közvetlenül a felhasználói meghajtóhoz megy, amely azonnal előkészít egy puffert hardver-specifikus tartalommal. Ez a puffer továbbítja az adatokat az operációs rendszer kerneléhez, ahonnan azok a videokártyára kerülnek. Így az összes kemény munka a felhasználói részben és a kernelben történik - csak az összegyűjtött puffer átvitele a videokártyára. Ennek eredményeként, ha egy egyéni illesztőprogram összeomlik, semmi rossz nem történik - egy adott alkalmazás bezárul, de nem történik BSOD . Ezen kívül az illesztőprogram most már eldönti, hogy mikor és hány kernel függvényhívást kezdeményezzen. Ezenkívül a DX Runtime nagyon vékony lesz - nincsenek parancspufferek, az illesztőprogram-funkciók közvetlenül hívódnak. Ezen kívül van egy feladatütemező a felhasználó és a kernel része között, amely kiválasztja, hogy mely összegyűjtött puffereket küldje el a videokártyára ( GPU felosztása számos folyamatra).
Most, ha nincs elég videomemória, akkor az erőforrások átkerülnek a rendszerbe (ahonnan cserélhetők ). Tekintettel arra, hogy a Windows Vista vezérli a videomemória (korábban az illesztőprogram) lefoglalását, hatékonyabban lehet lefoglalni, mint a POOL_MANAGED XDDM-ben. Ebben a szakaszban ez szoftverszinten működik - a GPU ütemező, mielőtt a DMA -csomagot a kártyára továbbítja, betölti az összes szükséges textúrát a videomemóriába (előre be tudja tölteni őket, amíg a GPU el van foglalva egy másikkal és a busszal ingyenes). Ha az alkalmazás teljes képernyős, akkor a videomemóriából minden extra szükség szerint átkerül a rendszermemóriába; ha ablakos módban van, akkor a memória meg van osztva az aktuális folyamatok között. Ha garantálni szeretné egy erőforrás 100%-os rendelkezésre állását a videomemóriában, akkor teljes képernyős módot kell használnia, és szabályoznia kell a kiosztások méretét.
A korábbi verziókban különféle okok miatt előfordulhat az eszköz elvesztése, amely után az összes erőforrást újra kellett tölteni a videomemóriába és vissza kellett állítani az objektumokat. Az új illesztőprogram-modellnél ez a probléma már nem áll fenn. Lehetséges az Eszköz eltávolítva helyzet, ami azt jelenti, hogy a videokártyát fizikailag eltávolították a rendszerből, vagy frissítették a videó illesztőprogramját. A helyzet nagyon ritka.
Minden funkcionalitás garantált a DX10-ben, vagyis ha egy kártya támogatja a DX10-et, akkor teljes mértékben támogatnia kell a shaderek legújabb verzióját , támogatnia kell az összes textúra formátumot, az összes lehetséges szűrési módot, a sablont (stencil) és minden mást. Sőt, a DX10-hez írtak egy specifikációt a raszterezési szabályokról, vagyis most a különböző, ugyanazt a kódot használó videokártyákon lévő képnek mindig azonosnak kell lennie, és meg kell egyeznie a referenciaszoftver raszterezőjével. Ha nem ez a helyzet, akkor ez a videokártya gyártójának hibája . A jövőben a funkcionalitás bővülni fog (DX10.1, DX11 stb. csomag).
A CPU funkcióinak (beleértve a DIP-t is) csökkentett hívási ideje. A Microsoft prezentációi szerint 10-szeres időcsökkenés figyelhető meg. Ez azért fontos, mert egy nehéz játék több mint 10 milliszekundumot is eltölthet DX-hívásokban. A hívási idő nagy részét korábban a Runtime and Driver töltötte, de most az illesztőprogram-modell valójában nem csinál semmit, hanem azonnal végrehajtást biztosít a meghajtónak.
Megjelentek az állapotobjektumok - olyan objektumok, amelyek a létrehozás során előre összeállíthatók, majd gyorsan telepíthetők a videokártyára. Hozzáadott állandó pufferek, amelyek lehetővé teszik a shader állandók hatékonyabb beállítását.
Az összes Set*State állapotot állapotobjektumokra cserélték. Az államok több csoportra oszthatók:
Az egyes csoportok állapotai egészként vannak beállítva, és nem mindegyik külön-külön, mint a D3D9-ben. Minden csoporthoz létrehozhat egy állapotobjektumot, amely létrehozásakor megadja a csoportállapotok teljes készletét, és csak „beállíthatja”. Az állapotobjektum létrehozása drága és lassú művelet, és ritkán kell hívni. Ennek az újításnak az a motivációja, hogy egy ilyen API lehetővé teszi az illesztőprogram számára, hogy előre (az állapotobjektum létrehozásakor) egy parancskészletet generáljon a videokártyához, és ne generálja azt minden renderelés során a Set*State hívásakor.
A fő adattípusokhoz (csúcsok, indexek, konstansok) egyetlen puffer került bevezetésre - ID3D10Buffer - egy bájtkészlet a memóriában. A típusbiztonságot a puffer tartalmának létrehozásakor adja meg. Az erőforrások esetében külön objektumok kerültek bevezetésre a folyamathoz – erőforrás nézetekhez való kötéshez. Vagyis először egy textúrát hozunk létre objektumként a memóriában, majd annak erőforrás nézetét a shader bemeneteként vagy renderelési célként, és ezzel a nézettel hívjuk a PSSetShaderResources (SetTexture helyett) és OMSetRenderTargets (a SetRenderTarget helyett). Érdemes megjegyezni, hogy egy erőforrásnak több erőforrásnézete is lehet.
Ez az elv lehetővé teszi az általánosított munkát. Vannak "típus nélküli" (típus nélküli) erőforrások, vagyis olyan erőforrások, amelyeknek nincs meghatározott típusuk (a létrehozás során nincs megadva) - például DXGI_FORMAT_R32G32B32_TYPELESS. Az ilyen erőforrások típusa a nézet létrehozása során kerül kiválasztásra (például DXGI_FORMAT_R32G32B32_UINT vagy DXGI_FORMAT_R32G32B32_FLOAT) és az elem/ szelet kiválasztása a textúratömbből/térfogati textúrából.
A Set*ShaderConstant helyébe a Constant Buffers lép – konstanscsoportok (puffer n konstanshoz), amelyek egyszerre vannak beállítva. A csoport zárolható és normál pufferként rögzíthető. A shaderhez való kötés egy bizonyos nyílástól kezdve történik.
Így az állandók használata abból adódik, hogy frissítési gyakoriság szerint (objektumonként, anyagonként, lépésenkénti, jelenetenként) több csoportra osztjuk őket, és minden csoporthoz konstans puffert hozunk létre. A további teljesítmény mellett ez a megközelítés magas szintű képet ad a vezetőnek – több lehetőséget az optimalizálásra.
A VertexDeclaration helyett a Bemeneti elrendezés. A Shader Input Signature létrehozásakor szükség van rá, vagyis a shader bemeneti (bemeneti) paramétereinek listájára. A létrehozott objektum Vertex Deklarációként használható bármely shaderrel, amelyiknek ugyanaz a bemeneti paraméterlistája. A D3D9-ben a Vertex Declaration a shadertől függetlenül lett beállítva rendereléskor, ezért a meghajtóknak komolyan módosítaniuk kellett a beállítást a vdecl megváltoztatásakor. Most a vdecl a shader bemenethez van kötve, ami lehetővé teszi az illesztőprogram számára, hogy mindent előre kiszámítson.
Shaderek már nem írhatók az assemblerben - HLSL-t kell használni. Bár a shader 4.x modellhez létezik assembler, és láthatjuk a shader-ek fordításának eredményét, az assembler szövegéből már nem lehet lekérni a shader bináris kódját (amit a psa.exe / vsa.exe csinált ), de ehhez használhatja a reverse engineering módszert is .
A shader kód portolásának megkönnyítése érdekében a fordító a HLSL shaderek régebbi verzióit (SM2.0, SM 3.0) SM4.0-ba fordíthatja. Az új HLSL-ben attribútumokat adtunk hozzá a fordítóhoz – a hurkok feloldása és a dinamikus vs. statikus elágazás kiválasztása a feltételes ugrásokhoz.
A Shader Model 4-ben egészszámú utasításokat és bitműveleteket adtak hozzá (tisztességes fix pontban lehet számolni és logikai jelzőket is átadni), megszűnt az utasítások számának korlátozása (de egy nagyon hosszú shader akár 10 mp-et is befuthat csomagvégrehajtási időkorlát a GPU-n)
Geometrikus shader – egy további shader a csúcs (Vertex Shader) és a pixel (Pixel Shader) között, amely primitíveket generálhat. A bemeneten egy primitívet adnak a szomszédok információival, a kimeneten - több generálható (nem fix szám).
Ez az a képesség, hogy a Vertex Shader / Geometry Shader eredményét a memóriába írjuk. Például a geometria feldolgozásának gyorsítótárazására vagy általában a GS által létrehozott geometriára. Gondolhat olyan iteratív effektusokra, mint a Ruha/víz. Ez azt jelenti, hogy most közvetlenül átalakíthatja és a GPU-ba írhatja a geometriát, nem csak pixeleket rajzolhat a Render Targetbe. A shaderben a memóriában lévő pufferből indexenként is lehet olvasni, vagyis elég nagy, csak olvasható osztott memóriánk van. Az NV például azt javasolja, hogy az animációs konstansokat tárolja ott példányosításhoz.
Megjelentek a textúra tömbök, vagyis egy azonos méretű és formátumú textúrák tárolója, amelyből a shader index alapján tud válogatni (DX10.1-ben cubemap tömbök is lehetségesek). Ez ugyanaz az atlaszolás, amit helyesen végeztek el – korábban, amikor több különböző textúrát tároltak egy textúrában, aggódnia kellett a mip-szintek miatt, hézagot kellett hagynia a textúrák között stb. Most már nem kell. Egy primitív/példányazonosító érkezik a shaderhez, a példányazonosítótól függően különböző textúrák/koordináták/bármilyen adatkészletet használhat. A shader dinamikus ága várhatóan gyors lesz (jobb, mint a DX9-hardvernél), így átadhat egy Material ID-t és kiválaszthat egy anyagot a shaderben. Azaz elméletileg nagy mennyiségű geometriát lehet generálni különböző paraméterekkel, textúrákkal és anyagokkal egy hívásban. A gyakorlatban a dinamikus ágnak meglehetősen nagy időköltsége és számos egyéb problémája van (textúra koordináták gradienseinek kiszámítása).
Az egyik leghasznosabb újítás, amiért sokan DX10-re váltottak. Most a shaderben minden MSAA mintát külön-külön olvashatunk, azaz saját AA szűrőt írhatunk, mintát a feldolgozás során problémamentesen, és akár textúraként is használhatjuk az MSAA RT-t. Ezenkívül az AlphaToCoverage hivatalosan is jelen van. A D3D10.1-ben a mélységi textúrák is rendelkeznek ezekkel a tulajdonságokkal.
Most a mélységi puffer használható textúraként. Elmondhatjuk, hogy mintavételkor az értékkel összehasonlítva és a szomszédokat szűrve tiszta mélységértéket és stencilértéket kaphatunk.
A Windows XP operációs rendszer nem támogatja a DX10-et. Ennek az az oka, hogy egy új illesztőprogram-modell portolása nem lehetséges – túl sok változtatásra van szükség az operációs rendszer kernelében. Ha azonban csak egy sor új DX10 szolgáltatás kerül átadásra, akkor problémák is felmerülnek: a virtualizációt és az ütemezést nem lehet elvégezni a régi illesztőprogram-modellben, a hardverfunkciók átvitele túl sok munka a Microsoft és az IHV számára .