UMA-optimeringar: CPU-tillgängliga texturer och Standard Swizzle

GPU:er (Unified Memory Architecture) erbjuder vissa effektivitetsfördelar jämfört med diskreta GPU:er, särskilt när du optimerar för mobila enheter. Om du ger resurser CPU-åtkomst när GPU:n är UMA kan du minska mängden kopiering som sker mellan CPU och GPU. Även om vi inte rekommenderar att program blindt ger CPU-åtkomst till alla resurser i UMA-design, finns det möjligheter att förbättra effektiviteten genom att ge rätt resurser CPU-åtkomst. Till skillnad från diskreta GPU:er kan processorn tekniskt sett ha en pekare till alla resurser som GPU:n kan komma åt.

Översikt över tillgängliga strukturer för PROCESSOR

Processortillgängliga texturer i grafikpipelinen är en funktion i UMA-arkitekturen, vilket ger processorer läs- och skrivåtkomst till texturer. På de vanligare diskreta GPU:erna har processorn inte åtkomst till texturer i grafikpipelinen.

Den allmänna bästa praxisen för texturer är att hantera diskreta GPU:er, vilket vanligtvis innebär att följa processerna i ladda upp texturdata via buffertar, sammanfattat som:

  • Har inte någon CPU-åtkomst för de flesta texturer.
  • Ange texturlayouten till D3D12_TEXTURE_LAYOUT_UNKNOWN.
  • Ladda upp texturerna till GPU:n med CopyTextureRegion.

I vissa fall kan dock processorn och GPU:n interagera så ofta på samma data att mappning av texturer blir användbart för att spara ström eller för att påskynda en viss design på vissa kort eller arkitekturer. Program bör identifiera dessa fall och optimera onödiga kopior. I det här fallet bör du tänka på följande för bästa prestanda:

  • Börja bara underhålla bättre prestanda för att mappa texturer när D3D12_FEATURE_DATA_ARCHITECTURE::UMA är SANT. Var sedan uppmärksam på CacheCoherentUMA- om du bestämmer vilka CPU-cacheegenskaper som ska väljas på heapen.

  • Att utnyttja CPU-åtkomst för texturer är mer komplicerat än för buffertar. De mest effektiva texturlayouterna för GPU:er är sällan row_major. Faktum är att vissa GPU:er bara kan stödja row_major texturer när du kopierar texturdata runt.

  • UMA-GPU:er bör dra nytta av en enkel optimering för att minska belastningstiderna. När du har känt igen UMA kan programmet optimera den inledande CopyTextureRegion för att fylla i texturer som GPU:n inte ändrar. I stället för att skapa strukturen i en heap med D3D12_HEAP_TYPE_DEFAULT och samla in texturdata kan programmet använda WriteToSubresource- för att undvika att förstå den faktiska texturlayouten.

  • I D3D12 är texturer som skapats med D3D12_TEXTURE_LAYOUT_UNKNOWN och ingen CPU-åtkomst mest effektiva för frekvent GPU-rendering och sampling. Vid prestandatestning bör dessa strukturer jämföras med D3D12_TEXTURE_LAYOUT_UNKNOWN med CPU-åtkomst och D3D12_TEXTURE_LAYOUT_STANDARD_SWIZZLE med CPU-åtkomst och D3D12_TEXTURE_LAYOUT_ROW_MAJOR för stöd för flera kort.

  • Med hjälp av D3D12_TEXTURE_LAYOUT_UNKNOWN med CPU-åtkomst kan metoderna WriteToSubresource, ReadFromSubresource, Map (precluding application access to pointer) och Unmap; men kan offra effektiviteten i GPU-åtkomst.

  • Med D3D12_TEXTURE_LAYOUT_STANDARD_SWIZZLE med CPU-åtkomst kan WriteToSubresource, ReadFromSubresource, Map (som returnerar en giltig pekare till programmet) och Unmap. Det kan också offra effektiviteten i GPU-åtkomst mer än D3D12_TEXTURE_LAYOUT_UNKNOWN med CPU-åtkomst.

Översikt över Standard Swizzle

D3D12 (och D3D11.3) introducerar en flerdimensionell standardlayout för data. Detta görs för att göra det möjligt för flera bearbetningsenheter att arbeta med samma data utan att kopiera data eller växla data mellan flera layouter. En standardiserad layout möjliggör effektivitetsvinster genom nätverkseffekter och gör det möjligt för algoritmer att göra genvägar med ett visst mönster.

En detaljerad beskrivning av texturlayouterna finns i D3D12_TEXTURE_LAYOUT.

Observera dock att denna standard swizzle är en maskinvarufunktion och kanske inte stöds av alla GPU:er.

Bakgrundsinformation om swizzling finns i Z-orderkurva.

Api

Till skillnad från D3D11.3 stöder D3D12 texturmappning som standard, så det finns inget behov av att fråga D3D12_FEATURE_DATA_D3D12_OPTIONS. D3D12 stöder dock inte alltid standard swizzle – den här funktionen måste efterfrågas med ett anrop till CheckFeatureSupport och kontrollera StandardSwizzle64KBSupported fältet i D3D12_FEATURE_DATA_D3D12_OPTIONS.

Följande API:er refererar till strukturmappning:

Uppräkningar

  • D3D12_TEXTURE_LAYOUT : styr swizzle-mönstret för standardstrukturer och aktiverar kartstöd för cpu-tillgängliga texturer.

Strukturer

Metoder

Resurser och överordnade heaps har anpassningskrav:

  • D3D12_DEFAULT_MSAA_RESOURCE_PLACEMENT_ALIGNMENT (4MB) för texturer med flera urval.
  • D3D12_DEFAULT_RESOURCE_PLACEMENT_ALIGNMENT (64 KB) för enkla exempelstrukturer och buffertar.
  • Linjär kopiering av underresurser måste justeras till D3D12_TEXTURE_DATA_PLACEMENT_ALIGNMENT (512 byte), där radhöjden justeras till D3D12_TEXTURE_DATA_PITCH_ALIGNMENT (256 byte).
  • Konstanta buffertvyer måste justeras till D3D12_CONSTANT_BUFFER_DATA_PLACEMENT_ALIGNMENT (256 byte).

Strukturer som är mindre än 64 KB bör bearbetas via CreateCommittedResource.

Med dynamiska texturer (texturer som ändrar varje bildruta) skriver processorn linjärt till uppladdnings-heapen, följt av en GPU-kopieringsåtgärd.

Vanligtvis skapar du dynamiska resurser en stor buffert i en uppladdningshög (se underallokering i buffertar). Skapa mellanlagringsresurser genom att skapa en stor buffert i en återläsnings-heap. Skapa statiska standardresurser genom att skapa intilliggande resurser i en standard-heap. Skapa standardaliasresurser genom att skapa överlappande resurser i en standard-heap.

WriteToSubresource och ReadFromSubresource ordna om texturdata mellan en rad-större layout och en odefinierad resurslayout. Åtgärden är synkron, så programmet bör ha cpu-schemaläggning i åtanke. Programmet kan alltid dela upp kopieringen i mindre regioner eller schemalägga den här åtgärden i en annan aktivitet. MSAA-resurser och djupstencilresurser med ogenomskinliga resurslayouter stöds inte av dessa CPU-kopieringsåtgärder och orsakar ett fel. Format som inte har en power-of-two-elementstorlek stöds inte heller och orsakar också ett fel. Slut på minnesreturkoder kan inträffa.

Kärnkonstanter

ID3D12Heap

resursbindning