Perché l'applicazione Direct3D funziona meglio in modalità schermo intero?
-
08-07-2019 - |
Domanda
Le prestazioni di un'applicazione Direct3D sembrano essere significativamente migliori in modalità schermo intero rispetto alla modalità finestra. Quali sono le ragioni tecniche alla base di questo?
Suppongo che abbia a che fare con il fatto che un'applicazione a schermo intero può ottenere il controllo esclusivo per il display. Ma perché l'applicazione non può ottenere il controllo esclusivo per parte dello schermo (ovvero finestra) e avere gli stessi vantaggi in termini di prestazioni?
Soluzione
Ecco le note sulla scogliera su come funzionano le cose sotto.
Lo schermo monitor deve sempre essere associato alla cosiddetta superficie primaria per poter visualizzare qualsiasi cosa, ovvero la videocard può scansionare solo da una superficie nella memoria video.
Quando l'applicazione è a schermo intero (e tutto è stato impostato correttamente per abilitare il flip), la superficie primaria è solo uno dei backbuffer dell'applicazione e passa a un altro backbuffer ogni frame. È il modo più efficiente di presentare sullo schermo, ma richiede l'applicazione per possedere l'intera area del monitor (cioè l'intera superficie primaria).
Quando non esiste un'applicazione a schermo intero e DWM è disattivato, la superficie primaria è di proprietà del sistema operativo e ogni applicazione con finestre esegue un blit dal backbuffer dell'applicazione a una superficie primaria. Questo blit richiede del tempo per la GPU per il completamento (così come i blits delle altre applicazioni visibili sullo schermo), quindi non è efficiente come la presentazione a schermo intero. XP ha funzionato in questo modo.
Quando DWM sta componendo lo schermo, le cose diventano ancora più complicate. Qui, DWM possiede la superficie primaria e deve disegnare lì le finestre dell'applicazione. Per renderlo possibile, ogni finestra ha una superficie associata che ne tiene il contenuto, chiamata superficie di reindirizzamento (che consente a DWM di abilitare il ghosting della finestra, gli effetti di vetro e tutto il resto). Ogni volta che l'applicazione D3D emette un frame, aggiunge un tocco a una superficie di reindirizzamento. In questo modo, è necessario che si verifichino diversi blit: blit su una superficie di reindirizzamento da parte dell'app, blit da una superficie di reindirizzamento a quella primaria tramite DWM, che è, ancora una volta, un overhead rispetto allo schermo intero.
Nota che tutto quel lavoro aggiuntivo è sulla GPU, quindi non influisce sulle prestazioni della CPU.
Materiale da leggere oltre:
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
Altri suggerimenti
C'è un po ' su MSDN che dice che la modalità a schermo intero utilizza il buffer flipping, se impostato correttamente, invece di blitting. Ha senso.
Naturalmente puoi (e in un certo senso, fare) dare un controllo esclusivo per parte dello schermo a un'applicazione, ma cosa succede al resto dello schermo? Devi ancora fare la cacca, fare il controllo dell'occlusione, ecc. Sul resto delle finestre, e penso che sia questo ciò che causa il colpo alle prestazioni.
Ad esempio, se hai un video riprodotto in Windows Media Player in una finestra, quindi avvia Civilization in un'altra, quando Civ inizia a fare la sua grafica accattivante, dovrà condividere lo spazio dello schermo con tutto il resto (come il video.
Considerando che se l'app DirectX ha lo schermo intero, tutto il resto potrebbe essere "aggiornato". o " giocando " ;, ma non in fase di elaborazione.
Fondamentalmente, l'hardware video è completamente dedicato all'applicazione in modalità esclusiva.
Non c'è contesa per le risorse video (pipeline, memoria delle trame, ecc ...)
In particolare, il caricamento delle texture può essere un grosso collo di bottiglia. Meno devi farlo (perché hai tutto), meglio è.