struttura D3D12_FEATURE_DATA_ARCHITECTURE1 (d3d12.h)
Fornisce informazioni dettagliate sui dettagli dell'architettura di ogni adattatore, in modo che l'applicazione possa ottimizzare meglio per determinate proprietà dell'adattatore.
Sintassi
typedef struct D3D12_FEATURE_DATA_ARCHITECTURE1 {
UINT NodeIndex;
BOOL TileBasedRenderer;
BOOL UMA;
BOOL CacheCoherentUMA;
BOOL IsolatedMMU;
} D3D12_FEATURE_DATA_ARCHITECTURE1;
Membri
NodeIndex
Nell'operazione a più schede indica quale scheda fisica del dispositivo è rilevante. Vedere sistemi a più schede. nodeIndex viene compilato dall'applicazione prima di chiamare CheckFeatureSupport, perché l'applicazione può recuperare i dettagli sull'architettura di ogni scheda.
TileBasedRenderer
Specifica se l'hardware e il driver supportano un renderer basato su riquadri. Il runtime imposta questo membro su TRUE se l'hardware e il driver supportano un renderer basato su riquadri.
UMA
Specifica se l'hardware e il driver supportano UMA. Il runtime imposta questo membro su TRUE se l'hardware e il driver supportano UMA.
CacheCoherentUMA
Specifica se l'hardware e il driver supportano l'UMA coerente con la cache. Il runtime imposta questo membro su TRUE se l'hardware e il driver supportano l'UMA coerente con la cache.
IsolatedMMU
SAL: Out
Specifica se l'hardware e il driver supportano mmu (Memory Management Unit) isolati. Il runtime imposta questo membro su TRUE se la GPU rispetta le proprietà della tabella di pagine della CPU come MEM_WRITE_WATCH (per altre informazioni, vedere VirtualAlloc) e PAGE_READONLY (per altre informazioni, vedere costanti di protezione della memoria ).
Se TRUE, l'applicazione deve prestare attenzione a non usare la memoria con queste proprietà della tabella di pagina con la GPU, perché la GPU potrebbe attivare queste proprietà della tabella di pagina in modi imprevisti. Ad esempio, le operazioni di scrittura GPU potrebbero essere più grossolane di quelle previste dall'applicazione, in particolare le scritture dall'interno degli shader. Alcune pagine di controllo di scrittura potrebbero apparire sporche, anche quando non è ovvio come le scritture GPU potrebbero averle interessate. Le operazioni GPU associate agli scenari di utilizzo dell'heap di caricamento e readback funzionano bene con le pagine di controllo di scrittura, ma possono talvolta generare falsi positivi che possono essere ignorati in modo sicuro.
Osservazioni
Come usare UMA e CacheCoherentUMA
Le app D3D12 devono preoccuparsi della gestione della residenza della memoria e della fornitura delle proprietà dell'heap ottimali. Le app D3D12 possono rimanere semplificate ed eseguite ragionevolmente bene in molte architetture GPU gestendo solo la residenza per le risorse in D3D12_HEAP_TYPE_DEFAULT heap. Queste app devono solo chiamare IDXGIAdapter3::QueryVideoMemoryInfo per DXGI_MEMORY_SEGMENT_GROUP_LOCAL e devono essere tolleranti che D3D12_HEAP_TYPE_UPLOAD e D3D12_HEAP_TYPE_READBACK provengono dallo stesso gruppo di segmenti di memoria.Tuttavia, una progettazione così semplice è troppo vincolante per le applicazioni che spingono i limiti. Quindi, D3D12_FEATURE_DATA_ARCHITECTURE consente alle applicazioni di ottimizzare meglio le proprietà dell'adattatore sottostante.
Alcune applicazioni potrebbero voler ottimizzare meglio le schede discrete e affrontare la complessità aggiuntiva della gestione dei budget di memoria video e memoria video. Se le dimensioni degli heap di caricamento sono rivali rispetto alle dimensioni delle trame predefinite, è disponibile un quasi raddoppio dell'utilizzo della memoria. Quando si supportano tali ottimizzazioni, un'applicazione può rilevare due budget di residenza o riconoscere UMA è false.
Alcune applicazioni potrebbero voler ottimizzare meglio le schede integrate/UMA, in particolare quelle interessate a estendere la durata della batteria nel dispositivo mobile. Le applicazioni D3D12 semplici vengono forzate a copiare dati tra heap con attribuzioni diverse, quando non è sempre necessario in UMA. Tuttavia, la proprietà UMA, da sola, comprende un'area grigia ragionevolmente vaga delle progettazioni GPU. Non presupporre che UMA significa che tutta la memoria accessibile dalla GPU può essere resa accessibile liberamente dalla CPU, perché non lo è. Esiste una proprietà che si allinea più strettamente a quel tipo di pensiero: CacheCoherentUMA.
Quando cacheCoherentUMA è false, è disponibile un singolo budget di residenza, ma la progettazione UMA beneficia comunemente delle tre attribuzioni di heap. Esistono opportunità per rimuovere la copia delle risorse tramite un uso saggio delle risorse di caricamento e readback e degli heap, che forniscono l'accesso alla CPU alla memoria. Tali opportunità non sono però chiare. Quindi, le applicazioni dovrebbero essere caute; e la sperimentazione in un'ampia gamma di sistemi "UMA" è consigliabile, in quanto è consigliabile ricorrere all'abilitazione o alla precludazione di determinati ID dispositivo. È consigliabile comprendere l'architettura della memoria GPU e il modo in cui i tipi heap traducono nelle proprietà della cache. La fattibilità del successo dipende probabilmente dalla frequenza con cui ogni processore legge o scrive i dati, le dimensioni e la località degli accessi ai dati e così via. Per gli sviluppatori avanzati: quando UMA è true e cacheCoherentUMA è false, la caratteristica più unica per questi adattatori è che gli heap di caricamento sono ancora combinati in scrittura. Tuttavia, alcune schede UMA traggono vantaggio dalle proprietà no-CPU-access e write-combine degli heap predefiniti e di caricamento. Per altri dettagli, vedere GetCustomHeapProperties.
Quando cachecoherentUMA è vera, le applicazioni possono intrattenere in modo più forte l'abbandono dell'attribuzione degli heap e l'uso dell'equivalente heap personalizzato degli heap di caricamento ovunque. Le ottimizzazioni UMA di copia zero, ad esempio quelle offerte da WriteToSubresource sono più generalmente incoraggiate perché più scenari trarranno vantaggio solo dall'utilizzo condiviso. Il modello di memoria è molto favorevole a più scenari e a un'adozione più ampia. Alcuni casi d'angolo possono ancora esistere in cui i benefici non sono facilmente ottenuti, ma dovrebbero essere molto più rari e meno dannosi di altre opzioni. Per sviluppatori avanzati: cacheCoherentUMA significa che una quantità significativa di cache nella gerarchia di memoria è anche unificata o integrata tra CPU e GPU. La caratteristica osservabile più unica è che gli heap di caricamento sono effettivamente writeback in CacheCoherentUMA. Per queste architetture, l'utilizzo di heap di combinazione di scrittura negli heap di caricamento è in genere un danno.
I dettagli di basso livello devono essere ignorati dalla maggior parte delle applicazioni a scheda singola. Come di consueto, le applicazioni a adattatore singolo possono semplificare il panorama e garantire che le scritture della CPU per caricare heap usino modelli compatibili con la combinazione di scrittura. I dettagli di livello inferiore consentono di rafforzare i concetti per le applicazioni con più adattatori. È probabile che le applicazioni con più adattatori debbano comprendere bene le proprietà dell'architettura degli adattatori per scegliere le proprietà dell'heap personalizzate ottimali per spostare in modo efficiente i dati tra schede.
Fabbisogno
| Requisito | Valore |
|---|---|
| intestazione |
d3d12.h |