Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Ett av de viktigaste designbesluten bakom DirectX12-bindningen är att separera den från andra hanteringsuppgifter. Detta ställer vissa krav på appen för att hantera vissa potentiella faror.
Den största fördelen med D3D12-bindningsmodellen är att den gör det möjligt för appar att ändra texturbindningar ofta, utan en enorm processorprestandakostnad. Andra fördelar är att shaders har åtkomst till ett mycket stort antal resurser, shaders behöver inte veta i förväg hur många resurser som kommer att bindas, och att en enhetlig resursbindningsmodell kan användas oavsett maskinvara eller apparnas innehållsflöde.
För att förbättra prestandan kräver inte bindningsmodellen att systemet håller reda på vilka bindningar en app har begärt att GPU:n ska använda, och det finns en ren integrering mellan bindnings- och flertrådade kommandolistor.
I följande avsnitt visas några av ändringarna i resursbindningsmodellen sedan D3D11.
- Minnesresidenthantering separerad från bindning
- objektlivslängdshantering separerad från bindning
- Resurstillståndsspårning för drivrutiner separerad från bindning
- Synkronisering av CPU och GPU-mappat minne separerad från bindning
- Relaterade ämnen
Minnesplaceringshantering separerad från bindning
Applikationer har explicit kontroll över vilka ytor som behöver vara tillgängliga för att GPU:n ska kunna använda dem direkt (kallas att vara "residens"). Omvänt kan de tillämpa andra tillstånd på resurser, till exempel att uttryckligen göra dem inte bosatta, eller låta operativsystemet välja för vissa klasser av program som kräver ett minimalt minnesfotavtryck. Det viktiga här är att applikationens hantering av inneboende komponenter är helt frikopplad från hur den ger åtkomst till resurser för shaders.
Avkopplingen av hanteringen av datorsessioner från mekanismen för att ge shaders åtkomst till resurser minskar system-/maskinvarukostnaden för rendering eftersom operativsystemet inte ständigt behöver inspektera det lokala bindningstillståndet för att veta vad som ska bli resident. Dessutom behöver shaders inte längre veta vilka exakta ytor de kan behöva referera till, så länge hela uppsättningen av resurser som möjligen kan vara tillgängliga har gjorts tillgänglig i förväg.
Objektlivslängdshantering separerad från bindning
Till skillnad från tidigare API:er spårar systemet inte längre bindningar av resurser till pipelinen. Detta används för att göra det möjligt för systemet att hålla liv i resurser som programmet har släppt eftersom de fortfarande refereras av enastående GPU-arbete.
Innan du frigör en resurs, till exempel en struktur, måste program nu se till att GPU:n har slutfört referensen. Det innebär att innan ett program på ett säkert sätt kan frigöra en resurs måste GPU:n ha slutfört körningen av kommandolistan som refererar till resursen.
Övervakning av drivrutinsresurstilstånd separerad från bindning
Systemet inspekterar inte längre resursbindningar för att förstå när resursövergångar har inträffat, vilket kräver ytterligare drivrutin eller GPU-arbete. Ett vanligt exempel för många GPU:er och drivrutiner är att behöva veta när en yta övergår från att användas som en RTV (Render Target View) till Shader Resource View (SRV). Själva programmen måste nu identifiera när eventuella resursövergångar som systemet kan bry sig om sker via dedikerade API:er.
CPU GPU Kartlagd minnessynkronisering separerad från bindning
Systemet inspekterar inte längre resursbindningar för att förstå om återgivningen behöver fördröjas eftersom den är beroende av en resurs som har mappats för CPU-åtkomst men inte har avmappats ännu. Program har nu ansvaret för att synkronisera processor- och GPU-minnesåtkomster. För att hjälpa till med detta tillhandahåller systemet mekanismer för programmet att begära viloläge för en CPU-tråd tills arbetet har slutförts. Avsökning kan också göras, men kan vara mindre effektivt.
Relaterade ämnen