Panoramica di DXGI
Microsoft DirectX Graphics Infrastructure (DXGI) riconosce che alcune parti della grafica si evolvono più lentamente di altre. L'obiettivo principale di DXGI è gestire attività di basso livello che possono essere indipendenti dal runtime di grafica DirectX. DXGI fornisce un framework comune per i componenti grafici futuri; il primo componente che sfrutta DXGI è Microsoft Direct3D 10.
Nelle versioni precedenti di Direct3D, le attività di basso livello, come l'enumerazione dei dispositivi hardware, la presentazione di fotogrammi sottoposti a rendering in un output, il controllo della gamma e la gestione di una transizione a schermo intero sono stati inclusi nel runtime Direct3D. Queste attività sono ora implementate in DXGI.
Lo scopo di DXGI è comunicare con il driver in modalità kernel e l'hardware di sistema, come illustrato nel diagramma seguente.
Un'applicazione può accedere direttamente a DXGI o chiamare le API Direct3D in D3D11_1.h, D3D11.h, D3D10_1.h o D3D10.h, che gestisce automaticamente le comunicazioni con DXGI. È possibile usare DXGI direttamente se l'applicazione deve enumerare i dispositivi o controllare la modalità di presentazione dei dati a un output.
Questo argomento contiene le sezioni seguenti.
- Enumerare gli adattatori
-
presentazione
- Creare una catena di scambio
- cura e alimentazione della catena di scambio
- Gestione del ridimensionamento delle finestre
- Scelta dell'Output DXGI e delle dimensioni
- debug in modalità Full-Screen
- distruggere una catena di scambio
- Uso di un monitor ruotato
- Modalità di commutazione
- Full-Screen Punta di prestazione
- Considerazioni sul Multithread
- Risposte DXGI da DLLMain
- DXGI 1.1 Modifiche
- DXGI 1.2 Modifiche
- argomenti correlati
Per vedere quali formati sono supportati dall'hardware Direct3D 11:
- Supporto del formato DXGI per l'hardware Direct3D livello di funzionalità 12.1
- supporto del formato DXGI per il livello di funzionalità Direct3D 12.0 dell'hardware
- Supporto del formato DXGI per l'hardware di livello di funzionalità 11.1 di Direct3D
- Supporto del formato DXGI per l'hardware Direct3D al livello di funzionalità 11.0
- supporto hardware per formati Direct3D 10Level9
- supporto hardware per formati Direct3D 10.1
- supporto hardware per formati Direct3D 10
Enumerazione degli adattatori
Un adattatore è un'astrazione dell'hardware e della funzionalità software del computer. Nel computer sono in genere presenti molti adattatori. Alcuni dispositivi vengono implementati nell'hardware (ad esempio la scheda video) e alcuni vengono implementati nel software (ad esempio il rasterizzatore di riferimento Direct3D). Gli adattatori implementano la funzionalità usata da un'applicazione grafica. Il diagramma seguente mostra un sistema con un singolo computer, due adattatori video e tre monitor di uscita.
Durante l'enumerazione di questi componenti hardware, DXGI crea un'interfaccia IDXGIOutput1 per ogni output (o monitor) e un'interfaccia IDXGIAdapter2 per ogni scheda video (anche se è una scheda video incorporata in una scheda madre). L'enumerazione viene eseguita usando una chiamata di interfacciaIDXGIFactory, IDXGIFactory::EnumAdapters, per restituire un set di interfacce IDXGIAdapter che rappresentano l'hardware video.
DXGI 1.1 ha aggiunto l'interfacciaIDXGIFactory1. IDXGIFactory1::EnumAdapters1 restituisce un set di interfacce IDXGIAdapter1 che rappresenta l'hardware video.
Se desiderate selezionare funzionalità hardware video specifiche quando utilizzate le API Direct3D, è consigliabile chiamare iterativamente la funzione D3D11CreateDevice o la funzione D3D11CreateDeviceAndSwapChain con ogni handle di adattatore e il possibile livello delle funzionalità hardware . Questa funzione ha esito positivo se il livello di funzionalità è supportato dall'adattatore specificato.
Nuove informazioni sull'enumerazione degli adattatori per Windows 8
A partire da Windows 8, è sempre presente un adattatore denominato "Microsoft Basic Render Driver". Questo adattatore ha un VendorId di 0x1414 e un DeviceID di 0x8c. Questo adattatore dispone inoltre del valore DXGI_ADAPTER_FLAG_SOFTWARE impostato nel membro Flags della sua struttura DXGI_ADAPTER_DESC2. Questo adattatore è un dispositivo solo per il rendering senza uscite video. DXGI non restituisce mai DXGI_ERROR_DEVICE_REMOVED per questa scheda.
Se il driver di visualizzazione di un computer non funziona o è disabilitato, l'adattatore primario del computer (NULL) potrebbe essere chiamato anche "Microsoft Basic Render Driver". Tuttavia, questo adattatore ha output e non ha il valore DXGI_ADAPTER_FLAG_SOFTWARE impostato. Il sistema operativo e le app utilizzano questo adattatore per impostazione predefinita. Se un driver di visualizzazione è installato o abilitato, le app possono ricevere DXGI_ERROR_DEVICE_REMOVED per questo adattatore e quindi devono ripetere l'enumerazione degli adattatori.
Quando la scheda di visualizzazione principale di un computer è "Microsoft Basic Display Adapter" (adattatore WARP), tale computer dispone anche di una seconda scheda. Questa seconda scheda è il dispositivo di sola rendering senza output di visualizzazione e per cui DXGI non restituisce mai DXGI_ERROR_DEVICE_REMOVED.
Se si vuole usare WARP per il rendering, il calcolo o altre attività a esecuzione prolungata, consigliamo di usare il dispositivo solo render. È possibile ottenere un puntatore al dispositivo di sola rendering chiamando il metodo IDXGIFactory1::EnumAdapters1. È possibile creare il dispositivo di solo rendering quando si specifica D3D_DRIVER_TYPE_WARP nel parametro DriverType di D3D11CreateDevice perché anche il dispositivo WARP usa l'adattatore WARP di solo rendering.
Presentazione
Il processo dell'applicazione consiste nel eseguire il rendering dei fotogrammi e chiedere a DXGI di presentare tali fotogrammi all'output. Se l'applicazione dispone di due buffer disponibili, può eseguire il rendering di un buffer mentre ne presenta un altro. L'applicazione potrebbe richiedere più di due buffer a seconda del tempo necessario per eseguire il rendering di un frame o della frequenza dei fotogrammi desiderata per la presentazione. Il set di buffer creati è denominato catena di scambio, come illustrato di seguito.
- Creare una catena di scambio
- cura e alimentazione della catena di scambio
- gestione del ridimensionamento delle finestre
- Scelta dell'output e delle dimensioni DXGI
- Debug in modalità Full-Screen
- distruggere una catena di scambio
- Uso di un monitor ruotato
- Cambiamento di modalità
- Full-Screen Consiglio sulle prestazioni
- Considerazioni sul Multithreading
Una catena di scambio ha un buffer anteriore e uno o più buffer posteriori. Ogni applicazione crea una propria catena di scambio. Per ottimizzare la velocità di presentazione dei dati in un output, una catena di scambio viene quasi sempre creata nella memoria di un sottos system di visualizzazione, come illustrato nella figura seguente.
Il sotto-sistema di visualizzazione (che è spesso una scheda video, ma può essere implementato su una scheda madre) contiene una GPU, un convertitore digitale a analogico (DAC) e la memoria. La catena di scambio viene allocata all'interno di questa memoria per rendere la presentazione molto veloce. Il sottosistema di visualizzazione presenta i dati nel buffer anteriore all'output.
Una catena di scambio è configurata per consentire la visualizzazione in modalità a schermo intero o in finestra, eliminando la necessità di sapere se un output è a finestra o schermo intero. Una catena di scambio in modalità schermo intero può ottimizzare le prestazioni passando alla risoluzione dello schermo.
Creare una catena di scambio
Differenze tra Direct3D 9 e Direct3D 10: Direct3D 10 è il primo componente grafico a usare DXGI. DXGI ha alcuni diversi comportamenti della catena di scambio.
|
I buffer di una catena di scambio vengono creati a una dimensione specifica e in un formato specifico. L'applicazione specifica questi valori (oppure è possibile ereditare le dimensioni dalla finestra di destinazione) all'avvio e può quindi modificarli facoltativamente quando le dimensioni della finestra cambiano in risposta agli eventi di input o programma dell'utente.
Dopo aver creato la catena di scambio, in genere si desidera renderizzare immagini al suo interno. Ecco un frammento di codice che configura un contesto Direct3D per il rendering in una catena di scambio. Questo codice estrae un buffer dalla catena di scambio, crea una visualizzazione di destinazione di rendering da tale buffer, quindi la imposta nel dispositivo:
ID3D11Resource * pBB;
ThrowFailure( pSwapChain->GetBuffer(0, __uuidof(pBB),
reinterpret_cast<void**>(&pBB)), "Couldn't get back buffer");
ID3D11RenderTargetView * pView;
ThrowFailure( pD3D11Device->CreateRenderTargetView(pBB, NULL, &pView),
"Couldn't create view" );
pD3D11DeviceContext->OMSetRenderTargets(1, &pView, 0);
Dopo che la tua applicazione ha eseguito il rendering di un frame in un buffer della swap-chain, chiama IDXGISwapChain1::Present1. L'applicazione può quindi eseguire il rendering dell'immagine successiva.
Cura e alimentazione della catena di scambio
Dopo aver eseguito il rendering dell'immagine, chiamare IDXGISwapChain1::Present1 ed eseguire il rendering dell'immagine successiva. Questo è l'entità della vostra responsabilità.
Se in precedenza è stato chiamato IDXGIFactory::MakeWindowAssociation, l'utente può premere la combinazione di tasti Alt-Enter e DXGI transiziona l'applicazione tra la modalità finestra e a schermo intero. IDXGIFactory::MakeWindowAssociation è consigliabile, perché un meccanismo di controllo standard per l'utente è fortemente desiderato.
Anche se non è necessario scrivere altro codice di quanto sia stato descritto, alcuni semplici passaggi possono rendere l'applicazione più reattiva. La considerazione più importante è il ridimensionamento dei buffer della catena di scambio in risposta al ridimensionamento della finestra di output. Naturalmente, il percorso migliore per l'applicazione è rispondere a WM_SIZE e chiamare IDXGISwapChain::ResizeBuffers, passando le dimensioni contenute nei parametri del messaggio. Questo comportamento rende ovviamente l'applicazione rispondere bene agli utenti quando trascinano i bordi della finestra, ma è anche esattamente ciò che consente una transizione a schermo intero fluida. La tua finestra riceverà un messaggio WM_SIZE ogni volta che si verifica questa transizione, e chiamando IDXGISwapChain::ResizeBuffers permette alla catena di scambio di riallocare lo spazio di archiviazione dei buffer per una presentazione ottimale. Ecco perché l'applicazione deve rilasciare tutti i riferimenti presenti nei buffer esistenti prima di chiamare IDXGISwapChain::ResizeBuffers.
La mancata chiamata a IDXGISwapChain::ResizeBuffers in risposta al passaggio alla modalità schermo intero (più frequentemente, in risposta a WM_SIZE) può ostacolare l'ottimizzazione del flipping, in cui DXGI può semplicemente scambiare il buffer visualizzato, anziché copiare l'intera quantità di dati di uno schermo.
IDXGISwapChain1::Present1 ti informerà se la finestra di output è completamente bloccata attraverso DXGI_STATUS_OCCLUDED. In questo caso, è consigliabile che l'applicazione entri in modalità standby (chiamando IDXGISwapChain1::Present1 con DXGI_PRESENT_TEST) poiché le risorse utilizzate per il rendering del frame vengono sprecate. L'uso di DXGI_PRESENT_TEST impedirà la presentazione di dati durante l'esecuzione del controllo dell'occlusione. Quando IDXGISwapChain1::Present1 restituisce S_OK, è consigliabile uscire dalla modalità standby; non usare il codice restituito per passare alla modalità standby poiché questo potrebbe impedire alla catena di scambio di rinunciare alla modalità schermo intero.
Il runtime Direct3D 11.1, disponibile a partire da Windows 8, fornisce una catena di scambio di modelli capovolti( ovvero una catena di scambio con il valore DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL impostato nel SwapEffect membro di DXGI_SWAP_CHAIN_DESC o DXGI_SWAP_CHAIN_DESC1). Quando si presentano fotogrammi a un output con una swap chain in modalità flip, DXGI annulla l'associazione del buffer posteriore da tutte le posizioni dello stato della pipeline, come un target di rendering dell'unione output, che scrivono su buffer posteriore 0. Consigliamo quindi di chiamare ID3D11DeviceContext::OMSetRenderTargets immediatamente prima di eseguire il rendering nel buffer posteriore. Ad esempio, non chiamare OMSetRenderTargets e quindi eseguire operazioni di compute shader che alla fine non eseguono il rendering sulla risorsa. Per altre info sulle catene di scambio di modelli flip e sui relativi vantaggi, vedi DXGI Flip Model.
Nota
In Direct3D 10 e Direct3D 11 non è necessario chiamare IDXGISwapChain::GetBuffer per recuperare il buffer nascosto 0 dopo aver chiamato IDXGISwapChain1::P resent1 perché per praticità le identità dei buffer back cambiano. Questo non avviene in Direct3D 12 e l'applicazione deve invece tenere traccia manualmente degli indici del buffer back.
Gestione del ridimensionamento delle finestre
Puoi usare il metodoIDXGISwapChain::ResizeBuffersper gestire il ridimensionamento delle finestre. Prima di chiamare ResizeBuffers, è necessario rilasciare tutti i riferimenti in sospeso ai buffer della catena di scambio. L'oggetto che in genere contiene un riferimento al buffer di una catena di scambio è una vista di destinazione di rendering.
Il codice di esempio seguente illustra come chiamare ResizeBuffers dall'interno del gestore WindowProc per WM_SIZE messaggi:
case WM_SIZE:
if (g_pSwapChain)
{
g_pd3dDeviceContext->OMSetRenderTargets(0, 0, 0);
// Release all outstanding references to the swap chain's buffers.
g_pRenderTargetView->Release();
HRESULT hr;
// Preserve the existing buffer count and format.
// Automatically choose the width and height to match the client rect for HWNDs.
hr = g_pSwapChain->ResizeBuffers(0, 0, 0, DXGI_FORMAT_UNKNOWN, 0);
// Perform error handling here!
// Get buffer and create a render-target-view.
ID3D11Texture2D* pBuffer;
hr = g_pSwapChain->GetBuffer(0, __uuidof( ID3D11Texture2D),
(void**) &pBuffer );
// Perform error handling here!
hr = g_pd3dDevice->CreateRenderTargetView(pBuffer, NULL,
&g_pRenderTargetView);
// Perform error handling here!
pBuffer->Release();
g_pd3dDeviceContext->OMSetRenderTargets(1, &g_pRenderTargetView, NULL );
// Set up the viewport.
D3D11_VIEWPORT vp;
vp.Width = width;
vp.Height = height;
vp.MinDepth = 0.0f;
vp.MaxDepth = 1.0f;
vp.TopLeftX = 0;
vp.TopLeftY = 0;
g_pd3dDeviceContext->RSSetViewports( 1, &vp );
}
return 1;
Selezione dell'output DXGI e della dimensione
Per impostazione predefinita, DXGI sceglie l'output che contiene la maggior parte dell'area client della finestra. Questa è l'unica opzione disponibile per DXGI quando passa a schermo intero in risposta a alt-invio. Se l'applicazione sceglie di passare alla modalità schermo intero da sola, può chiamare IDXGISwapChain::SetFullscreenState e passare un output IDXGIOutput1 esplicito (o NULL, se l'applicazione preferisce lasciare che DXGI decida).
Per ridimensionare l'output mentre è a schermo intero o in finestra, è consigliabile chiamare IDXGISwapChain::ResizeTarget, poiché questo metodo ridimensiona anche la finestra di destinazione. Poiché la finestra di destinazione viene ridimensionata, il sistema operativo invia WM_SIZEe il codice chiamerà naturalmente IDXGISwapChain::ResizeBuffers in risposta. È quindi uno spreco di tempo ridimensionare i buffer, e poi successivamente ridimensionare il bersaglio.
Debug in modalità schermo intero
Una catena di scambio DXGI rinuncia alla modalità schermo intero solo quando assolutamente necessario. Ciò significa che è possibile eseguire il debug di un'applicazione a schermo intero usando più monitor, purché la finestra di debug non si sovrapponga alla finestra di destinazione della catena di scambio. In alternativa, è possibile impedire completamente il cambio della modalità non impostando il flag di DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH.
Se il cambio di modalità è consentito, una catena di scambio rinuncerà alla modalità schermo intero ogni volta che la finestra di output è bloccata da un'altra finestra. Il controllo dell'occlusione viene eseguito durante IDXGISwapChain1::Present1, o da un thread separato il cui scopo è controllare se l'applicazione è diventata non responsiva (e non chiama più IDXGISwapChain1::Present1). Per disabilitare la possibilità del thread separato di provocare uno switch, impostare la seguente chiave del registro di sistema su qualsiasi valore diverso da zero.
HKCU\Software\Microsoft\DXGI\DisableFullscreenWatchdog
Eliminazione di una catena di scambio
Non è possibile rilasciare una catena di scambio in modalità a schermo intero perché in questo modo è possibile creare conflitti di thread (che causeranno la generazione di un'eccezione non continuabile da parte di DXGI). Prima di rilasciare una catena di scambio, passare prima alla modalità finestra (usando IDXGISwapChain::SetFullscreenState( FALSE, NULL )) e quindi chiamare IUnknown::Release.
Uso di un monitor ruotato
Un'applicazione non deve preoccuparsi dell'orientamento del monitor, poiché DXGI ruoterà il buffer della catena di scambio durante la presentazione, se necessario. Naturalmente, questa rotazione aggiuntiva può influire sulle prestazioni. Per ottenere prestazioni ottimali, prestare attenzione alla rotazione nell'applicazione eseguendo le operazioni seguenti:
- Usare il DXGI_SWAP_CHAIN_FLAG_NONPREROTATED. Ciò notifica a DXGI che l'applicazione produrrà un'immagine ruotata (ad esempio, modificando la matrice di proiezione). Una cosa da notare, questo flag è valido solo se in modalità schermo intero.
- Allocare ogni buffer della swap-chain nella sua dimensione ruotata. Usare IDXGIOutput::GetDesc per ottenere questi valori, se necessario.
Eseguendo la rotazione nell'applicazione, DXGI eseguirà semplicemente una copia anziché una copia e una rotazione.
Il runtime Direct3D 11.1, disponibile a partire da Windows 8, fornisce una catena di scambio di modelli capovolti( ovvero una catena di scambio con il valore DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL impostato nel SwapEffect membro di DXGI_SWAP_CHAIN_DESC1). Per ottimizzare le ottimizzazioni della presentazione disponibili con una catena di scambio di modelli capovolti, è consigliabile impostare il contenuto delle applicazioni in modo che corrisponda all'output specifico in cui risiede il contenuto quando tale contenuto occupa completamente l'output. Per altre info sulle catene di scambio di modelli flip e sui relativi vantaggi, vedi DXGI Flip Model.
Cambio di modalità
La catena di scambio DXGI potrebbe modificare la modalità di visualizzazione di un output quando si effettua una transizione a schermo intero. Per abilitare la modifica della modalità di visualizzazione automatica, è necessario specificare DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH nella descrizione della catena di scambio. Se la modalità di visualizzazione cambia automaticamente, DXGI sceglierà la modalità più modesta (le dimensioni e la risoluzione non cambieranno, ma la profondità del colore potrebbe). Il ridimensionamento dei buffer della catena di scambio non causerà un cambio di modalità. La catena di scambio fa una promessa implicita che se si sceglie un buffer nascosto che corrisponde esattamente a una modalità di visualizzazione supportata dall'output di destinazione, passerà alla modalità di visualizzazione quando si immette la modalità a schermo intero su tale output. Di conseguenza, scegli una modalità di visualizzazione scegliendo le dimensioni e il formato del buffer nascosto.
Suggerimento per le prestazioni a schermo intero
Quando chiami IDXGISwapChain1::Present1 in un'applicazione a schermo intero, la catena di scambio scambia il contenuto del buffer di fondo nel buffer frontale. Ciò richiede che la catena di scambio sia stata creata usando una modalità di visualizzazione enumerata (specificata in DXGI_SWAP_CHAIN_DESC1). Se non è possibile enumerare le modalità di visualizzazione o specificare erroneamente la modalità di visualizzazione nella descrizione, la catena di scambio può eseguire invece un trasferimento bit-block (bitblt). Il bitblt causa una copia di estensione aggiuntiva, oltre a un maggiore utilizzo della memoria video ed è difficile da rilevare. Per evitare questo problema, enumerare le modalità di visualizzazione e inizializzare correttamente la descrizione della catena di scambio prima di creare la catena di scambio. Ciò garantisce prestazioni massime quando si capovolge in modalità schermo intero ed evita il sovraccarico di memoria aggiuntivo.
Considerazioni sul multithread
Quando si usa DXGI in un'applicazione con più thread, è necessario prestare attenzione per evitare di creare un deadlock, in cui due thread diversi sono in attesa l'uno sull'altro per completare. Ci sono due situazioni in cui questo può verificarsi.
- Il thread di rendering non è il thread di gestione dei messaggi.
- Il thread che esegue un'API DXGI non è lo stesso thread che ha creato la finestra.
Evita che il thread message-pump sia mai in attesa sul thread di rendering quando utilizzi catene di swap a schermo intero. Ad esempio, la chiamata di IDXGISwapChain1::P resent1 (dal thread di rendering) può causare l'attesa del thread di rendering sul thread message pump. Quando si verifica una modifica della modalità, questo scenario è possibile se Present1 chiama ::SetWindowPos() o ::SetWindowStyle() e uno di questi metodi chiama ::SendMessage(). In questo scenario, se il thread della message pump ha una sezione critica a proteggerlo o se il thread di rendering è bloccato, si verificherà un deadlock tra i due thread.
Per altre info sull'uso di DXGI con più thread, vedi multithreading e DXGI.
Risposte di DXGI da DLLMain
Poiché una funzione DllMain non può garantire l'ordine in cui carica e scarica le DLL, è consigliabile che la funzione DllMain dell'app non chiami funzioni o metodi Direct3D o DXGI, incluse funzioni o metodi che creano o rilasciano oggetti. Se la funzione DllMain dell'app chiama un determinato componente, quel componente potrebbe chiamare un'altra DLL non presente nel sistema operativo, causando l'arresto anomalo del sistema operativo. Direct3D e DXGI potrebbero caricare un set di DLL, in genere un set di driver, che differisce dal computer al computer. Pertanto, anche se l'app non si arresta in modo anomalo nei computer di sviluppo e test quando la relativa DllMain funzione chiama funzioni o metodi Direct3D o DXGI, potrebbe arrestarsi in modo anomalo quando viene eseguita su un altro computer.
Per impedire la creazione di un'app che potrebbe causare l'arresto anomalo del sistema operativo, DXGI fornisce le risposte seguenti nelle situazioni specificate:
- Se la funzione DllMain dell'app rilascia l'ultimo riferimento a una fabbrica DXGI, DXGI genera un'eccezione.
- Se la funzione DllMain dell'app crea una factory DXGI, DXGI restituisce un codice di errore.
Modifiche a DXGI 1.1
In DXGI 1.1 sono state aggiunte le funzionalità seguenti.
Supporto delle superfici condivise sincronizzate
Le superfici condivise sincronizzate per Direct3D 10.1 e Direct3D 11 consentono una condivisione efficiente della superficie di lettura e scrittura tra più dispositivi Direct3D (la condivisione tra dispositivi Direct3D 10 e Direct3D 11 è possibile). Vedere IDXGIKeyedMutex::AcquireSync e IDXGIKeyedMutex::ReleaseSync.
Supporto per colori elevati
Supporta il formato DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM.
IDXGIDevice1::SetMaximumFrameLatency e IDXGIDevice1::GetMaximumFrameLatency
IDXGIFactory1::EnumAdapters1 enumera schede locali senza monitoraggi o output collegati, nonché schede con output collegati. Il primo adattatore restituito sarà l'adattatore locale su cui viene visualizzato il Desktop principale.
Supporto del formato BGRA
DXGI_FORMAT_B8G8R8A8_UNORM e DXGI_FORMAT_B8G8R8A8_UNORM_SRGB, consultare IDXGISurface1::GetDC e IDXGISurface1::ReleaseDC.
Modifiche a DXGI 1.2
In DXGI 1.2 sono state aggiunte le funzionalità seguenti.
- Catena di scambio stereo
- Catena di scambio modello Flip
- Presentazione ottimizzata (scorrimento, rettangoli sporchi e rotazione)
- Miglioramento delle risorse condivise e della sincronizzazione
- duplicazione desktop
- Uso ottimizzato della memoria video
- Supporto per formati a 16 bit per pixel (bpp) (DXGI_FORMAT_B5G6R5_UNORM, DXGI_FORMAT_B5G5R5A1_UNORM, DXGI_FORMAT_B4G4R4A4_UNORM)
- Debugging delle API
Per altre info su DXGI 1.2, vedi DXGI 1.2 Improvements.
Argomenti correlati
Guida alla programmazione di per dxgi