Mejoras de DXGI 1.4
La siguiente funcionalidad se ha agregado o cambiado en Microsoft DirectX Graphics Infrastructure (DXGI) 1.4, en gran medida para admitir Direct3D 12.
Enumeración de adaptadores más barata
Para Direct3D 12, ya no es posible retroceder desde un dispositivo al IDXGIAdapter que se usó para crearlo. Tampoco es posible proporcionar D3D_DRIVER_TYPE_WARP en D3D12CreateDevice. Para facilitar el desarrollo, puede usar IDXGIFactory4 para tratar ambos. IDXGIFactory4::EnumAdapterByLuid (diseñado para emparejarse con ID3D12Device::GetAdapterLuid) permite que una aplicación recupere información sobre el adaptador donde se creó un dispositivo Direct3D 12. IDXGIFactory4::EnumWarpAdapter proporciona un adaptador que se puede proporcionar a D3D12CreateDevice para usar el representador WARP.
Seguimiento del presupuesto de memoria de vídeo
Se recomienda a los desarrolladores de aplicaciones que usen un sistema de reserva de memoria de vídeo para informar al sistema operativo de la cantidad de memoria de vídeo física que la aplicación no puede pasar sin ella.
La cantidad de memoria física disponible para un proceso se conoce como "presupuesto de memoria de vídeo". El presupuesto puede fluctuar notablemente a medida que los procesos en segundo plano se despiertan y duermen; y fluctúan drásticamente cuando el usuario cambia a otra aplicación. La aplicación se puede notificar cuando cambia el presupuesto y sondea tanto el presupuesto actual como la cantidad de memoria consumida actualmente. Si una aplicación no permanece dentro de su presupuesto, el proceso se inmovilizará intermitentemente para permitir que otras aplicaciones se ejecuten o las API de creación devolverán un error. La interfaz IDXGIAdapter3 proporciona los métodos relacionados con esta funcionalidad, en particular QueryVideoMemoryInfo y RegisterVideoMemoryBudgetChangeNotificationEvent.
Para obtener más información, consulte el tema direct3D 12 sobre residencia.
Cambios en la cadena de intercambio de Direct3D 12
Algunas de las funcionalidades existentes de la cadena de intercambio de Direct3D 11 han quedado en desuso para lograr las reducciones de sobrecarga en Direct3D 12. Mientras que otros cambios se realizaron para alinearse con los conceptos de Direct3D 12 o proporcionar una mejor compatibilidad con las características de Direct3D 12.
Identidad de búfer inversa invariable
En Direct3D 11, las aplicaciones podrían llamar a GetBuffer( 0, ... ) solo una vez. Cada llamada a Present cambió implícitamente la identidad de recurso de la interfaz devuelta. Direct3D 12 ya no admite ese cambio implícito de identidad de recursos, debido a la sobrecarga de CPU necesaria y al diseño del descriptor de recursos flexible. Como resultado, la aplicación debe llamar manualmente a GetBuffer para cada búfer creado con la cadena de intercambio. La aplicación debe representarse manualmente en el siguiente búfer de la secuencia después de llamar a Present. Se recomienda a las aplicaciones crear una memoria caché de descriptores para cada búfer, en lugar de volver a crear muchos objetos cada uno de ellos.
Compatibilidad con varios adaptadores
Cuando se crea una cadena de intercambio en un adaptador de varias GPU, todas las búferes backbuffer se crean en el nodo 1 y solo se admite una sola cola de comandos. ResizeBuffers1 permite a las aplicaciones crear búferes de retroceso en distintos nodos, lo que permite usar una cola de comandos diferente con cada una. Estas funcionalidades permiten usar técnicas alternativas de representación de fotogramas (AFR) con la cadena de intercambio. Consulte Sistemas de varios adaptadores.
Varios
- Se debe pasar un objeto de cola de comandos a los métodos CreateSwapChain en lugar del objeto de dispositivo Direct3D 12.
- Solo se admiten los dos efectos de intercambio del modelo de volteo siguientes:
- DXGI_SWAP_EFFECT_FLIP_DISCARD debe preferirse cuando las aplicaciones se representen por completo sobre el búfer de retroceso antes de presentarla o estén interesadas en admitir fácilmente escenarios de varios adaptadores.
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL deben usarse en aplicaciones que se basan en optimizaciones parciales de presentación o que se leen regularmente de los búferes de retroceso presentados anteriormente. - SetFullscreenState ya no posee exclusivamente la pantalla, por lo que los elementos del sistema operativo iniciados por el usuario pueden aparecer sin problemas delante de la salida de la aplicación. La configuración del volumen es un ejemplo de esto.