Por que o aplicativo Direct3D tem um desempenho melhor no modo de tela inteira?

Question

O desempenho de um aplicativo Direct3D parece ser significativamente melhor no modo de tela inteira em comparação com o modo de janela. Quais são as razões técnicas por trás disso?

Eu acho que tem algo a ver com o fato de que um aplicativo de tela cheia pode obter controle exclusivo para a tela. Mas por que o aplicativo não pode obter controle exclusivo para papel da tela (ou seja, janela) e tem os mesmos benefícios de desempenho?

Answer 1

Aqui estão as notas do penhasco sobre como as coisas funcionam por baixo.

A tela do monitor sempre precisa ser associada à chamada superfície primária para poder exibir qualquer coisa, ou seja, o VideoCard só pode escanear uma superfície na memória de vídeo.

Quando a aplicação está em tela cheia (e tudo foi configurado corretamente para ativar o inversão), a superfície primária é apenas um dos backbuffers do aplicativo e virou para outro backbuffer em cada quadro. É a maneira mais eficiente de apresentar na tela, mas exige que a aplicação possua toda a área do monitor (ou seja, a superfície primária inteira).

Quando não há aplicativo de tela cheia e o DWM está desligado, a superfície primária é de propriedade do SO e todo aplicativo em janela executa um blit do aplicativo BackBuffer para uma superfície primária. Esse blit leva algum tempo para a GPU para concluir (bem como blits dos outros aplicativos visíveis na tela), portanto não é tão eficiente quanto a apresentação em tela cheia. XP funcionou dessa maneira.

Quando o DWM está compondo a tela, as coisas ficam ainda mais complicadas. Aqui, o DWM possui a superfície primária e precisa desenhar janelas de aplicativos lá. Para tornar isso possível, toda janela possui uma superfície associada que mantém seu conteúdo, chamado superfície de redirecionamento (que permite que o DWM habilite fantasmas de janela, efeitos de vidro e todas essas coisas boas). Toda vez que o aplicativo D3D emite um quadro, ele adiciona um blit a uma superfície de redirecionamento. Dessa forma, vários blits precisam acontecer: Blit até uma superfície de redirecionamento pelo aplicativo, Blit de uma superfície de redirecionamento para a primária pelo DWM, que é, novamente, algumas notas em comparação com a tela cheia.

Observe que todo esse trabalho adicional está na GPU, por isso não afeta o desempenho da CPU.

Coisas para ler mais:

http://blogs.msdn.com/greg_schechter/archive/2006/03/19/555087.aspx

http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx

http://blogs.msdn.com/greg_schechter/archive/2006/03/05/544314.aspx

Answer 2

Há um pouco No MSDN, que diz que o modo de tela inteira usa o buffer de buffer, se configurado corretamente, em vez de Blitting. Faz sentido.

É claro que você pode (e, de certa forma, fazer) fornecer controle exclusivo para parte da tela para um aplicativo, mas o que acontece com o restante da tela? Você ainda precisa esclarecer, fazer a verificação de oclusão etc. no restante das janelas, e acho que é isso que causa o desempenho do desempenho.

Answer 3

Vou adicionar a @AIBResposta de que o restante da tela está sendo gerenciado pelo sistema operacional. Portanto, se algo mais precisar ser desenhado/trabalhado simultaneamente, deve haver um sucesso de desempenho.

Por exemplo, se você tiver um vídeo reproduzido no Windows Media Player em uma janela, inicie a civilização em outra, quando o Civ começar a fazer seus gráficos sofisticados, ele precisará compartilhar espaço na tela com todo o resto (como o vídeo.

Considerando que, se o aplicativo DirectX tiver a tela cheia, tudo pode estar "atualizando" ou "tocando", mas não sendo desenhado.

Answer 4

Basicamente, o hardware de vídeo é completamente dedicado ao aplicativo de modo exclusivo.

Não há disposição para recursos de vídeo (pipeline, memória de textura, etc ...)

Em particular, o upload de textura pode ser um grande gargalo. Quanto menos você tiver que fazer isso (porque você tem tudo), melhor.