Melhorias no DXGI 1.4
A funcionalidade a seguir foi adicionada ou alterada no Microsoft DirectX Graphics Infrastructure (DXGI) 1.4, em grande parte para oferecer suporte ao Direct3D 12.
Enumeração de adaptador mais barata
Para o Direct3D 12, não é mais possível retroceder de um dispositivo para o IDXGIAdapter que foi usado para criá-lo. Também não é mais possível fornecer D3D_DRIVER_TYPE_WARP para D3D12CreateDevice. Para facilitar o desenvolvimento, você pode usar IDXGIFactory4 para lidar com ambos. IDXGIFactory4::EnumAdapterByLuid (projetado para ser emparelhado com ID3D12Device::GetAdapterLuid) permite que um aplicativo recupere informações sobre o adaptador onde um dispositivo Direct3D 12 foi criado. IDXGIFactory4::EnumWarpAdapter fornece um adaptador que pode ser fornecido para D3D12CreateDevice usar o renderizador WARP.
Rastreamento de orçamento de memória de vídeo
Os desenvolvedores de aplicativos são encorajados a usar um sistema de reserva de memória de vídeo, para informar o sistema operacional da quantidade de memória de vídeo física que o aplicativo não pode prescindir.
A quantidade de memória física disponível para um processo é conhecida como "orçamento de memória de vídeo". O orçamento pode flutuar visivelmente à medida que os processos de fundo acordam e dormem; e flutuam drasticamente quando o usuário muda para outro aplicativo. O aplicativo pode ser notificado quando o orçamento é alterado e sondar o orçamento atual e a quantidade de memória consumida atualmente. Se um aplicativo não permanecer dentro de seu orçamento, o processo será intermitentemente congelado para permitir que outros aplicativos sejam executados e/ou as APIs de criação retornarão falha. A interfaceIDXGIAdapter3 dofornece os métodos pertencentes a essa funcionalidade, em particular QueryVideoMemoryInfo e RegisterVideoMemoryBudgetChangeNotificationEvent.
Para obter mais informações, consulte o tópico Direct3D 12 em Residency.
Alterações na cadeia de permuta do Direct3D 12
Algumas das funcionalidades existentes da cadeia de permuta do Direct3D 11 foram preteridas para obter as reduções de sobrecarga no Direct3D 12. Enquanto outras alterações foram feitas para alinhar aos conceitos do Direct3D 12 ou fornecer melhor suporte para os recursos do Direct3D 12.
de identidade de backbuffer invariante
No Direct3D 11, os aplicativos podiam chamar GetBuffer( 0, ... ) apenas uma vez. Cada chamada para Presente implicitamente alterava a identidade do recurso da interface retornada. O Direct3D 12 não suporta mais essa alteração implícita de identidade de recurso, devido à sobrecarga de CPU necessária e ao design flexível do descritor de recursos. Como resultado, o aplicativo deve chamar manualmente GetBuffer para cada buffer criado com a cadeia de permuta. O aplicativo deve renderizar manualmente para o próximo buffer na sequência depois de chamar Present. Os aplicativos são incentivados a criar um cache de descritores para cada buffer, em vez de recriar muitos objetos cada Present.
Suporte a vários adaptadores
Quando uma cadeia de permuta é criada em um adaptador multi-GPU, os backbuffers são todos criados no nó 1 e apenas uma única fila de comandos é suportada. ResizeBuffers1 permite que os aplicativos criem backbuffers em nós diferentes, permitindo que uma fila de comandos diferente seja usada com cada um. Esses recursos permitem que técnicas de AFR (Alternate Frame Rendering) sejam usadas com a cadeia de permuta. Consulte Sistemas multiadaptador.
Diversos
- Um objeto de fila de comandos deve ser passado para métodos de CreateSwapChain em vez do objeto de dispositivo Direct3D 12.
- Apenas os seguintes dois efeitos de troca de modelo flip são suportados:
- DXGI_SWAP_EFFECT_FLIP_DISCARD deve ser preferido quando os aplicativos são totalmente renderizados sobre o backbuffer antes de apresentá-lo ou estão interessados em suportar cenários de vários adaptadores facilmente.
DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL deve ser usado por aplicativos que dependem de otimizações parciais de apresentação ou leitura regular de backbuffers apresentados anteriormente. - SetFullscreenState não é mais o proprietário exclusivo da tela, de modo que os elementos do sistema operacional iniciados pelo usuário podem aparecer perfeitamente na frente da saída do aplicativo. As configurações de volume são um exemplo disso.