Direct3D 10 - en uppsättning API -funktioner för interaktion med ett grafikkort; stöds av NV GeForce 8x00, ATI Radeon 2x00 och högre grafikkort. Direct3D 10 (D3D10) är en API-komponent (Application Programming Interface) i DirectX 10, den tionde versionen av Direct3D, efterföljaren till Direct3D 9. Direct3D 10 tillhandahåller funktioner för operativsystem och applikationsinteraktion med grafikkortsdrivrutiner. Dessa funktioner är operativsystemspecifika i Windows-serien och är tillgängliga i Windows Vista och Windows 7 . Delvis fungerar D3D10 på grafikkort på Direct3D 9-nivån.
Den officiella slutliga versionen släpptes den 10 november 2006 som en del av Windows Vista .
Följande är viktiga funktioner och skillnader från Direct3D version 9.
I Windows Vista är en helt ny drivrutinsmodell, WDDM ( Windows Display Driver Model , tidigare LDDM - Longhorn Display Driver Model), en stor förändring i videodrivrutinsmodellen sedan tillkomsten av hårdvaruacceleration. I XDDM ( Windows XP Display Driver Model) lade varje DirectX -anrop till en kommandopekare (token) till kommandobufferten i ett grafikkortsoberoende format. När DX Runtime bestämde att bufferten var tillräckligt full anropades en drivrutinsfunktion (i kärnläge ) för att få den bufferten. Därefter analyserade föraren denna buffert och överförde data till grafikkortet. Det vill säga, det fanns inga drivrutinsfunktioner i användarläge . Utvecklingen av grafikkort och, som ett resultat, komplikationen av kommandobufferten ledde till att drivrutinen blev otänkbart stor och, i händelse av något fel, provocerade BSOD . Också i XDDM har operativsystemet inget sätt att ställa in prioritet, hantera videominne, schemalägga DX-samtal, vilket gör det svårt att dela ett grafikkort mellan flera processer - orsaken till "enhetsförlust".
I den nya drivrutinsmodellen görs en separation mellan användardelen och kärnlägesdelen av drivrutinen. Alla DX-anrop går direkt till användardrivrutinen, som omedelbart förbereder en buffert med hårdvaruspecifikt innehåll. Denna buffert överför data till operativsystemets kärna, varifrån de går till grafikkortet. Allt hårt arbete görs alltså i användardelen och i kärnan - bara överföringen av den insamlade bufferten till grafikkortet. Som ett resultat, om en anpassad drivrutin kraschar, kommer inget dåligt att hända - en specifik applikation kommer att stängas, men ingen BSOD kommer att inträffa . Dessutom bestämmer drivrutinen nu när och hur många kärnfunktionsanrop som ska göras. Dessutom blir DX Runtime väldigt tunn - det finns inga kommandobuffertar, drivrutinsfunktioner anropas direkt. Dessutom finns det en uppgiftsschemaläggare mellan användaren och kärndelen, som väljer vilka insamlade buffertar som ska skickas till grafikkortet ( GPU -uppdelning i många processer).
Nu, om det inte finns tillräckligt med videominne, överförs resurserna till systemet (därifrån de kan bytas ). På grund av det faktum att Windows Vista styr allokeringen av videominne (tidigare drivrutinen), är det möjligt att allokera det mer effektivt än POOL_MANAGED i XDDM. I det här skedet fungerar detta på mjukvarunivå - GPU-schemaläggaren, innan DMA -paketet överförs till kortet, laddar alla nödvändiga texturer i videominnet (den kan ladda dem i förväg medan GPU:n är upptagen med en annan och bussen är gratis). Om applikationen är i helskärm kommer allt extra från videominnet att överföras till systemminnet efter behov; om i fönsterläge delas minnet mellan de aktuella processerna. Om du vill garantera 100 % tillgänglighet av en resurs i videominnet måste du använda helskärmsläge och kontroll över tilldelningarnas storlek.
I tidigare versioner, av olika anledningar, kunde Device Lost inträffa, varefter det var nödvändigt att ladda om alla resurser till videominnet och återställa objekt. Med den nya drivrutinsmodellen finns detta problem inte längre. En Device Removed-situation är möjlig, vilket innebär att grafikkortet fysiskt har tagits bort från systemet eller att grafikdrivrutinen har uppdaterats. Situationen är mycket sällsynt.
All funktionalitet är garanterad i DX10, det vill säga om ett kort stöder DX10 måste det stödja den senaste versionen av shaders fullt ut, stödja alla texturformat, alla möjliga filtreringslägen, mall (stencil) och allt annat. Dessutom skrev de för DX10 en specifikation av rastreringsregler, det vill säga nu ska bilden på olika grafikkort som använder samma kod alltid vara densamma och matcha referensmjukvarans rastrering. Om så inte är fallet är detta ett fel från grafikkortstillverkaren. I framtiden kommer funktionaliteten att utökas (paket DX10.1, DX11, etc.).
Minskad samtalstid för funktioner (inklusive DIP) på CPU. Enligt Microsofts presentationer kan en 10x tidsminskning observeras. Detta är viktigt eftersom ett tungt spel kan spendera cirka 10+ millisekunder i DX-samtal. Det mesta av samtalstiden ägnades tidigare åt Runtime och Driver, men nu gör förarmodellen faktiskt ingenting, utan ger omedelbart exekvering till föraren.
State Objects dök upp - objekt som kan förmonteras under skapandet och sedan snabbt installeras på grafikkortet. Lade till konstanta buffertar, vilket möjliggör effektivare inställning av skuggkonstanter.
Alla Set*States har ersatts med State Objects. Staterna är indelade i flera grupper:
Tillstånden för varje grupp är satta som en helhet, och inte var och en separat, som i D3D9. För varje grupp kan du skapa ett tillståndsobjekt, som, när det skapas, specificerar hela uppsättningen av grupptillstånd, och du kan bara "ställa in" det. Att skapa ett tillståndsobjekt är en dyr och långsam operation och bör anropas sällan. Motivationen för denna innovation är att ett sådant API tillåter föraren att generera en uppsättning kommandon för grafikkortet i förväg (när man skapar State Object) och inte generera det varje gång under renderingen när Set*State anropas.
För huvuddatatyperna (hörn, index, konstanter) har en enda buffert införts - ID3D10Buffer - en uppsättning byte i minnet. Typ säker tillhandahålls genom att specificera när innehållet i bufferten skapas. För resurser har separata objekt införts för bindning till pipeline - resursvyer. Det vill säga, först skapar vi en textur som ett objekt i minnet, och sedan dess resursvy som input för skuggningen eller som ett rendermål, och med denna vy kallar vi PSSetShaderResources (istället för SetTexture) och OMSetRenderTargets (istället för SetRenderTarget). Det är värt att notera att en resurs kan ha flera resursvyer.
Denna princip låter dig arbeta på ett generaliserat sätt. Det finns "typlösa" (typlösa) resurser, det vill säga resurser som inte har en specifik typ (inte specificerad under skapandet) - till exempel DXGI_FORMAT_R32G32B32_TYPELESS. Typen av sådana resurser väljs när vyn skapas (till exempel DXGI_FORMAT_R32G32B32_UINT eller DXGI_FORMAT_R32G32B32_FLOAT) och val av element/ segment från texturmatrisen/volymetrisk textur.
Set*ShaderConstant ersätts av konstanta buffertar - grupper av konstanter (en buffert för n konstanter) som sätts åt gången. Gruppen kan låsas och spelas in som en normal buffert. Bindning till shadern utförs med början från en viss plats.
Användningen av konstanter handlar alltså om att dela in dem i flera grupper efter uppdateringsfrekvens (per objekt, per material, per pass, per scen) och skapa en konstant buffert för varje grupp. Förutom ytterligare prestanda ger detta tillvägagångssätt föraren en bild på hög nivå - fler möjligheter till optimering.
VertexDeclaration ersatt med Input Layout. Det kräver när du skapar en Shader Input Signature, det vill säga en lista över inmatningsparametrar (indata) för shadern. Det skapade objektet kan användas som en vertexdeklaration med valfri skuggning som har samma lista med inmatningsparametrar. I D3D9 ställdes Vertex-deklarationen in oberoende av skuggningen vid rendering, och därför var drivrutinerna tvungna att allvarligt ändra inställningen när de ändrade vdecl. Nu är vdecl ansluten till shaderingången, vilket gör att föraren kan förberäkna allt i förväg.
Shaders kan inte längre skrivas i assembler - du måste använda HLSL. Även om det finns en assembler för shader modell 4.x och du kan se resultatet av att kompilera shaders i den, är det inte längre möjligt att hämta den binära koden för shadern från assembler-texten (vad psa.exe / vsa.exe gjorde ), men du kan använda omvänd teknik för detta .
För att göra det enklare att porta shader-kod kan kompilatorn kompilera äldre versioner av HLSL shaders (SM2.0, SM 3.0) till SM4.0. I den nya HLSL har vi lagt till attribut för tips till kompilatorn - avveckla loopar och välja dynamisk kontra statisk förgrening för villkorliga hopp.
I Shader Model 4 har heltalsinstruktioner och bitoperationer lagts till (du kan räkna i en rättvis fast punkt och skicka booleska flaggor), begränsningen av antalet instruktioner har tagits bort (men en mycket lång skuggning kan köras in i 10 sek. tidsgräns för paketkörning på GPU)
Geometrisk shader - en extra shader mellan vertex (Vertex Shader) och pixel (Pixel Shader), som kan generera primitiver. Vid ingången ges den en primitiv med information om grannarna, vid utgången - du kan generera flera (inte ett fast antal).
Detta är förmågan att skriva resultatet av Vertex Shader / Geometry Shader till minnet. Till exempel för att cachelagra bearbetningen av geometri eller i allmänhet den geometri som skapats av GS. Du kan tänka på iterativa effekter som tyg/vatten. Det vill säga, nu kan du direkt transformera och skriva geometri till GPU:n, och inte bara rita pixlar i Render Target. Det är också möjligt att läsa i skuggningen från bufferten i minnet efter index, det vill säga att ha ett ganska stort skrivskyddat delat minne. NV föreslår till exempel att du lagrar animationskonstanter där för exempel.
Texturmatriser dök upp, det vill säga en behållare med texturer av samma storlek och format, från vilka skuggningen kan väljas efter index (i DX10.1 är cubemap-arrayer också möjliga). Det här är samma atlas som gjordes rätt - innan, när flera olika texturer lagrades i en textur, var du tvungen att oroa dig för mip-nivåer, lämna ett gap mellan texturer, etc. Nu behöver du inte göra det. Ett primitivt/instans-id kommer till skuggningen, beroende på instans-ID kan du använda en annan uppsättning texturer/koordinater/valfri data. Den dynamiska grenen i shadern förväntas vara snabb (bättre än i DX9-hårdvara), så du kan skicka ett material-ID och välja ett material i shadern. Det vill säga, i teorin är det möjligt att generera en stor mängd geometri med olika parametrar, texturer och material i ett anrop. I praktiken har den dynamiska grenen en ganska stor tidskostnad och ett antal andra problem (beräkna gradienter av texturkoordinater).
En av de mest användbara innovationerna som många har bytt till DX10 för. Nu i skuggan kan du läsa varje MSAA-prov separat, det vill säga skriva ditt eget AA-filter, prova under bearbetningen utan problem och till och med använda MSAA RT som en textur. Dessutom är AlphaToCoverage nu officiellt närvarande. I D3D10.1 har djuptexturer också dessa funktioner.
Nu kan djupbufferten användas som textur. Vi kan säga att vid provtagning, jämför med värdet och filtrera grannarna kan du få ett rent djupvärde och stencilvärde.
Operativsystemet Windows XP stöder inte DX10. Anledningen är att det inte är möjligt att porta en ny drivrutinsmodell - det krävs för många ändringar i operativsystemets kärna. Men om bara en uppsättning nya DX10-funktioner överförs, uppstår också problem: virtualisering och schemaläggning kan inte göras i den gamla drivrutinsmodellen, att överföra hårdvarufunktioner är för mycket arbete för Microsoft och IHV .