Direct3D 10 - et sæt API -funktioner til interaktion med et videokort; understøttet af NV GeForce 8x00, ATI Radeon 2x00 og højere videokort. Direct3D 10 (D3D10) er en API-komponent (Application Programming Interface) af DirectX 10, den 10. version af Direct3D, efterfølgeren til Direct3D 9. Direct3D 10 giver funktioner til operativsystem- og applikationsinteraktion med grafikkortdrivere. Disse funktioner er operativsystemspecifikke i Windows-linjen og er tilgængelige i Windows Vista og Windows 7 . Delvist fungerer D3D10 på videokort på Direct3D 9-niveau.
Den officielle endelige version blev udgivet den 10. november 2006 som en del af Windows Vista .
Følgende er nøglefunktioner og forskelle fra Direct3D version 9.
I Windows Vista er en helt ny drivermodel, WDDM ( Windows Display Driver Model , tidligere LDDM - Longhorn Display Driver Model), en stor ændring i videodrivermodellen siden fremkomsten af hardwareacceleration. I XDDM ( Windows XP Display Driver Model) tilføjede hvert DirectX -kald en kommandomarkør (token) til kommandobufferen i et videokort-uafhængigt format. Da DX Runtime besluttede, at bufferen var fuld nok, blev der kaldt en driverfunktion (i kernetilstand ) for at få den buffer. Derefter analyserede driveren denne buffer og overførte dataene til videokortet. Det vil sige, at der ikke var nogen driverfunktioner i brugertilstand . Udviklingen af videokort og som følge heraf komplikationen af kommandobufferen førte til, at driveren blev utænkeligt stor og i tilfælde af fejl fremkaldte BSOD . Også i XDDM har operativsystemet ingen mulighed for at sætte prioritet, administrere videohukommelse, planlægge DX-opkald, hvilket gør det vanskeligt at dele et videokort mellem flere processer - årsagen til "enhedstab".
I den nye drivermodel er der lavet en adskillelse mellem brugerdelen og kernel-mode delen af driveren. Alle DX-kald går direkte til brugerdriveren, som straks forbereder en buffer med hardware-specifikt indhold. Denne buffer overfører data til operativsystemets kerne, hvorfra de går til videokortet. Alt det hårde arbejde udføres således i brugerdelen og i kernen - kun overførslen af den indsamlede buffer til videokortet. Som et resultat, hvis en brugerdefineret driver går ned, vil der ikke ske noget dårligt - et specifikt program vil lukke, men ingen BSOD vil forekomme . Derudover bestemmer driveren nu, hvornår og hvor mange kernefunktionskald der skal foretages. DX Runtime bliver også meget tynd - der er ingen kommandobuffere, driverfunktioner kaldes direkte. Derudover er der en opgaveplanlægger mellem brugeren og kernedelen, som vælger hvilke indsamlede buffere, der skal sendes til videokortet ( GPU -opdeling i mange processer).
Nu, hvis der ikke er nok videohukommelse, overføres ressourcerne til systemet (hvorfra de kan byttes ). På grund af det faktum, at Windows Vista styrer allokeringen af videohukommelse (tidligere driveren), er det muligt at allokere det mere effektivt end POOL_MANAGED i XDDM. På dette trin fungerer dette på softwareniveau - GPU-planlæggeren, før DMA -pakken overføres til kortet, indlæser alle de nødvendige teksturer i videohukommelsen (den kan indlæse dem på forhånd, mens GPU'en er optaget med en anden og bussen er ledig). Hvis applikationen er fuldskærm, vil alt ekstra fra videohukommelsen blive overført til systemhukommelsen efter behov; hvis i vinduestilstand, så deles hukommelsen mellem de aktuelle processer. Hvis du vil garantere 100 % tilgængelighed af en ressource i videohukommelsen, skal du bruge fuldskærmstilstand og kontrollere størrelsen af allokeringer.
I tidligere versioner kunne Device Lost af forskellige årsager forekomme, hvorefter det var nødvendigt at genindlæse alle ressourcer i videohukommelsen og gendanne objekter. Med den nye drivermodel eksisterer dette problem ikke længere. En Device Removed situation er mulig, hvilket betyder, at videokortet er blevet fysisk fjernet fra systemet, eller at videodriveren er blevet opdateret. Situationen er meget sjælden.
Al funktionalitet er garanteret i DX10, det vil sige, hvis et kort understøtter DX10, så skal det understøtte den nyeste version af shaders fuldt ud, understøtte alle teksturformater, alle mulige filtreringstilstande, skabelon (stencil) og alt muligt andet. Desuden skrev de til DX10 en specifikation af rasteriseringsregler, det vil sige, at nu skal billedet på forskellige videokort, der bruger den samme kode, altid være det samme og matche referencesoftwarens rasterizer. Hvis dette ikke er tilfældet, er dette en fejl fra skærmkortproducenten. I fremtiden vil funktionaliteten blive udvidet (pakke DX10.1, DX11 osv.).
Reduceret opkaldstid for funktioner (inklusive DIP) på CPU'en. Ifølge Microsoft -præsentationer kan der observeres en 10x reduktion i tid. Dette er vigtigt, da et tungt spil kan bruge omkring 10+ millisekunder i DX-opkald. Det meste af opkaldstiden blev tidligere brugt på Runtime og Driver, men nu gør drivermodellen faktisk ingenting, men giver straks udførelse til driveren.
Tilstandsobjekter dukkede op - objekter, der kan formonteres under oprettelsen og derefter hurtigt installeres på videokortet. Tilføjet konstantbuffere, hvilket muliggør mere effektiv indstilling af skyggekonstanter.
Alle sæt*tilstande er blevet erstattet med tilstandsobjekter. Staterne er opdelt i flere grupper:
Tilstandene for hver gruppe er sat som en helhed og ikke hver for sig, som i D3D9. For hver gruppe kan du oprette et tilstandsobjekt, som, når det er oprettet, specificerer det fulde sæt af gruppetilstande, og du kan kun "indstille" det. Oprettelse af et tilstandsobjekt er en dyr og langsom operation og bør sjældent kaldes. Motivationen for denne innovation er, at en sådan API tillader driveren at generere et sæt kommandoer til videokortet på forhånd (når der oprettes State Object) og ikke generere det hver gang under gengivelsen, når Set*State kaldes.
For de vigtigste datatyper (hjørnepunkter, indekser, konstanter) er der indført en enkelt buffer - ID3D10Buffer - et sæt bytes i hukommelsen. Type sikker leveres ved at angive, når indholdet af bufferen oprettes. For ressourcer er der indført separate objekter til binding til pipeline - ressourcevisninger. Det vil sige, at vi først opretter en tekstur som et objekt i hukommelsen, og derefter dets ressourcevisning som input til shaderen eller som et rendermål, og med denne visning kalder vi PSSetShaderResources (i stedet for SetTexture) og OMSetRenderTargets (i stedet for SetRenderTarget). Det er værd at bemærke, at én ressource kan have flere ressourcevisninger.
Dette princip giver dig mulighed for at arbejde på en generaliseret måde. Der er "typeløse" (typeløse) ressourcer, det vil sige ressourcer, der ikke har en bestemt type (ikke angivet under oprettelsen) - for eksempel DXGI_FORMAT_R32G32B32_TYPELESS. Typen af sådanne ressourcer vælges under visningsoprettelse (f.eks. DXGI_FORMAT_R32G32B32_UINT eller DXGI_FORMAT_R32G32B32_FLOAT) og element/udsnitsvalg fra teksturarrayet/volumetrisk tekstur.
Set*ShaderConstant erstattes af konstante buffere - grupper af konstanter (en buffer for n konstanter), der indstilles ad gangen. Gruppen kan låses og optages som en normal buffer. Binding til shaderen udføres med start fra et bestemt slot.
Brugen af konstanter kommer således ned på at opdele dem i flere grupper efter opdateringsfrekvens (per-objekt, per-materiale, per-pass, per-scene) og skabe en konstant buffer for hver gruppe. Ud over yderligere ydeevne giver denne tilgang føreren et billede på højt niveau - flere muligheder for optimering.
VertexDeclaration erstattet med Input Layout. Det kræver, når du opretter en Shader Input Signature, det vil sige en liste over input (input) parametre for shaderen. Det oprettede objekt kan bruges som en Vertex Declaration med enhver shader, der har den samme liste over inputparametre. I D3D9 blev Vertex Declaration indstillet uafhængigt af shaderen ved rendering, og derfor måtte driverne seriøst ændre opsætningen ved ændring af vdecl. Nu er vdecl koblet til shader-indgangen, som gør det muligt for driveren at forudberegne alt på forhånd.
Shaders kan ikke længere skrives i assembler - du skal bruge HLSL. Selvom der er en assembler til shader model 4.x, og du kan se resultatet af at kompilere shaders ind i den, er det ikke længere muligt at hente shaderens binære kode fra assembler-teksten (hvad psa.exe / vsa.exe gjorde ), men du kan bruge reverse engineering- metoden til dette .
For at gøre det nemmere at portere shader-kode kan compileren kompilere ældre versioner af HLSL shaders (SM2.0, SM 3.0) til SM4.0. I den nye HLSL tilføjede vi attributter til tip til compileren - afvikling af loops og valg af dynamisk vs statisk forgrening til betingede spring.
I Shader Model 4 er der tilføjet heltalsinstruktioner og bitoperationer (du kan tælle i et rimeligt fast punkt og sende booleske flag), begrænsningen på antallet af instruktioner er blevet fjernet (men en meget lang skygge kan løbe ind i 10 sek. pakkeudførelsestidsgrænse på GPU'en)
Geometrisk skygge - en ekstra skygge mellem vertex (Vertex Shader) og pixel (Pixel Shader), som kan generere primitiver. Ved indgangen får den en primitiv med information om naboerne, ved udgangen - man kan generere flere (ikke et fast antal).
Dette er evnen til at skrive resultatet af Vertex Shader / Geometry Shader til hukommelsen. For eksempel at cache behandlingen af geometri eller generelt geometrien skabt af GS. Du kan tænke på iterative effekter som klud/vand. Det vil sige, at du nu kan transformere og skrive geometri direkte til GPU'en og ikke kun tegne pixels i Render Target. Det er også muligt at læse i shaderen fra bufferen i hukommelsen efter indeks, det vil sige at have en ret stor skrivebeskyttet delt hukommelse. NV foreslår for eksempel at gemme animationskonstanter der for eksempel.
Tekstur-arrays dukkede op, det vil sige en beholder med teksturer af samme størrelse og format, hvorfra skyggen kan vælges efter indeks (i DX10.1 er cubemap-arrays også mulige). Dette er det samme atlas, som blev gjort lige - før, hvor flere forskellige teksturer blev gemt i én tekstur, skulle du bekymre dig om mip-niveauer, efterlade et hul mellem teksturer osv. Nu behøver du ikke. Et primitivt/instans-id kommer til shaderen, afhængigt af instans-id’et kan du bruge et andet sæt teksturer/koordinater/enhver data. Den dynamiske gren i shaderen forventes at være hurtig (bedre end i DX9-hardware), så du kan videregive et materiale-id og vælge et materiale i shaderen. Det vil sige, at det i teorien er muligt at generere en stor mængde geometri med forskellige parametre, teksturer og materialer i et opkald. I praksis har den dynamiske gren ret store tidsomkostninger og en række andre problemer (beregning af gradienter af teksturkoordinater).
En af de mest nyttige innovationer, som mange har skiftet til DX10 for. Nu i skyggen kan du læse hver MSAA-prøve separat, det vil sige skrive dit eget AA-filter, prøve under behandlingen uden problemer, og endda bruge MSAA RT som en tekstur. Også AlphaToCoverage er nu officielt til stede. I D3D10.1 har dybdeteksturer også disse funktioner.
Nu kan dybdebufferen bruges som tekstur. Vi kan sige, at når du prøver, sammenligner med værdien og filtrerer naboerne, kan du få en ren dybdeværdi og stencilværdi.
Windows XP -operativsystemet understøtter ikke DX10. Årsagen er, at portering af en ny drivermodel ikke er mulig - der kræves for mange ændringer i operativsystemkernen. Men hvis kun et sæt nye DX10-funktioner overføres, så opstår der også problemer: Virtualisering og planlægning kan ikke udføres i den gamle drivermodel, overførsel af hardwarefunktioner er for meget arbejde for Microsoft og IHV .