Coda di scorrimento hardware

Questo articolo descrive la funzionalità della coda di scorrimento hardware supportata a partire da Windows 11 (WDDM 3.0). Una coda di scorrimento hardware consente l'invio di più fotogrammi futuri alla coda del controller di visualizzazione. La CPU e le parti della GPU possono passare a stati di potenza inferiori mentre il controller di visualizzazione elabora più fotogrammi in coda, migliorando l'efficienza energetica degli scenari di riproduzione video su hardware in grado di supportare.

Modello di coda flip pre-WDDM 3.0

Molti controller di visualizzazione moderni supportano la possibilità di accodare più fotogrammi che devono essere visualizzati in una sequenza. A partire da WDDM 2.1, il sistema operativo supporta più richieste di sovrascrittura capovolgimento in sospeso che devono essere presentate nel VSync successivo. Il driver miniport (KMD) di visualizzazione indica questo supporto tramite il valore MaxQueuedMultiPlaneOverlayFlipVSync in DXGK_DRIVERCAPS. Questa funzionalità è utile per ridurre la latenza negli scenari di gioco a frequenza di fotogrammi elevata in cui viene eseguito il rendering sequenziale di più fotogrammi con intervallo 0, con la finalità di visualizzare solo il fotogramma più recente.

Negli scenari di riproduzione video, il contenuto di più fotogrammi futuri da visualizzare in sequenza è noto in anticipo e può essere accodato alla GPU. Questo accodamento anticipato consente alla CPU di entrare in uno stato di basso consumo mentre i fotogrammi in coda vengono elaborati, con conseguente notevole risparmio di energia. Tuttavia, prima di WDDM 3.0 non c'era alcun meccanismo per il sistema operativo per inviare più fotogrammi che devono rimanere sullo schermo per almeno un intervallo VSync senza ulteriore intervento della CPU. La sezione Basic hardware flip queue introduce una soluzione che consente alla CPU di immettere uno stato di risparmio energia e di eseguire l'offload dell'elaborazione dei fotogrammi in coda nella GPU.

Negli scenari di gioco prima di WDDM 3.0, dopo che la GPU completa il rendering della scena nel buffer back della catena di scambio, è presente un round trip sulla CPU per inviare la richiesta per presentare il contenuto del frame allo schermo. Per carichi di lavoro GPU pesanti che terminano vicino a VSync, questo round trip potrebbe causare ritardi nei fotogrammi e perdere il tempo di destinazione previsto, causando problemi di frame osservabili. La sezione Advanced hardware flip queue introduce un meccanismo per evitare questo round trip della CPU e presentare fotogrammi completati sullo schermo con bassa latenza. La coda di scorrimento hardware avanzata richiede sia la funzionalità di base della coda di scorrimento hardware sia la funzionalità di pianificazione hardware GPU fase 2.

Coda di scorrimento hardware di base

Il diagramma seguente illustra il caso di presentazione di tre fotogrammi, ognuno sullo schermo per un intervallo VSync.

Il modello di riempimento nel diagramma mostra i tempi in cui l'elaborazione della coda di scorrimento software Dxgkrnl e i thread dell'applicazione devono riattivare ed eseguire il lavoro della CPU. In ogni VSync, il controller di visualizzazione deve inviare una notifica della CPU al sistema operativo per il capovolgimento completato e il sistema operativo deve inviare la richiesta di scorrimento successiva. L'applicazione deve anche riattivarsi su ogni VSync ed eseguire query per presentare statistiche per apprendere quando viene visualizzato l'ultimo fotogramma nel batch di tre.

Le DDI della coda di scorrimento hardware che possono inviare più fotogrammi futuri alla coda del controller di visualizzazione sono disponibili a partire da WDDM 3.0. Come indicato in precedenza, questo meccanismo consente alla CPU e alle parti della GPU di passare a stati di potenza inferiori mentre il controller di visualizzazione sta elaborando più fotogrammi in coda. Questa transizione migliora l'efficienza energetica degli scenari di riproduzione video su hardware in grado di supportare.

Il diagramma seguente illustra l'architettura proposta.

Con l'approccio alla coda di scorrimento hardware, sia l'applicazione che i componenti CPU Dxgkrnl sono completamente inattive per due intervalli VSync tra le ore v2 e v4, consentendo alla CPU di entrare in uno stato di basso consumo. La CPU viene notificata solo quando il frame N+2 indica che l'applicazione ha richiesto il completamento di un'attesa.

Coda di scorrimento hardware avanzata

Negli scenari di gioco prima di WDDM 3.0, dopo che la GPU completa il rendering della scena nel buffer back della catena di scambio, è presente un round trip sulla CPU per inviare la richiesta per presentare il contenuto del frame allo schermo. Il diagramma seguente illustra questo scenario.

Il costo di questo round trip può causare la mancata destinazione dei fotogrammi se il rendering è finito troppo vicino a VSync, come illustrato nel diagramma seguente.

Alcuni controller di visualizzazione supportano in modo nativo le condizioni di attesa che consentono alla visualizzazione di inviare la richiesta di scorrimento dopo che la GPU ha eseguito il rendering del fotogramma senza il round trip della CPU. Poiché la coda di scorrimento hardware può inviare il frame completato N alla visualizzazione senza un round trip della CPU, potrebbe evitare fotogrammi mancanti, come illustrato nel diagramma seguente.

Nella parte restante di questo articolo viene descritta la funzionalità di base della coda di scorrimento hardware.

Supporto DDI

Sono state aggiunte le DDI seguenti per supportare la funzionalità di capovolgimento hardware.

Verifica della disponibilità delle funzionalità

La coda di scorrimento hardware richiede l'abilitazione/disabilitazione della negoziazione del sistema operativo. Un KMD che supporta la coda di capovolgimento hardware deve prima chiamare DXGKCB_QUERYFEATURESUPPORT durante l'ora di avvio del dispositivo con un FeatureId di DXGK_FEATURE_HWFLIPQUEUE per determinare se il sistema operativo consente l'abilitazione della coda di scorrimento hardware.

La coda di scorrimento hardware può essere usata solo se il callback ha esito positivo e Enable è impostato su TRUE.

Un KMD può usare il codice di esempio seguente durante le fasi iniziali e sperimentali della coda di scorrimento hardware.

DXGKARGCB_QUERYFEATURESUPPORT HwFlipQueueEnabledArgs = {};
HwFlipQueueEnabledArgs.DeviceHandle = DeviceHandle;
HwFlipQueueEnabledArgs.FeatureId = DXGK_FEATURE_HWFLIPQUEUE;
HwFlipQueueEnabledArgs.DriverSupportState = DXGK_FEATURE_SUPPORT_EXPERIMENTAL;

if (!NT_SUCCESS(pDxgkInterface->DxgkCbQueryFeatureSupport(&HwFlipQueueEnabledArgs)) ||
    !HwFlipQueueEnabledArgs.Enabled)
{
    // Disable hardware flip queue because the OS didn't allow it.           
}
else
{
    // Enable hardware flip queue because the OS allowed it.
}

Durante la visualizzazione del driver, anche se è possibile abilitare la coda di scorrimento hardware senza abilitare la pianificazione hardware GPU, questa combinazione non è ufficialmente supportata. Windows richiede attualmente l'abilitazione della pianificazione hardware GPU per consentire l'abilitazione della coda di scorrimento hardware di base nei driver rilasciati ufficialmente.

Indicazione delle funzionalità di accodamento hardware

MaxHwQueuedFlips è stato aggiunto a DXGK_DRIVERCAPS per indicare il supporto della coda di capovolgimento hardware. Se il supporto della coda di scorrimento hardware consentito dal sistema operativo come descritto in precedenza, un KMD che supporta una coda di scorrimento hardware deve impostare MaxHwQueuedFlips su un valore maggiore di 1. Quando MaxHwQueuedFlips è maggiore di 1, kmd indica che l'hardware di visualizzazione supporta fino a maxHwQueuedFlips futuri frame che possono essere accodati per un determinato VidPnSource sulla GPU. Il sistema operativo rispetta le restrizioni fornite dai driver sul tipo di capovolgimenti che possono essere accodati in anticipo.

HwQueuedFlipCaps è stato aggiunto anche a DXGK_DRIVERCAPS. Questo membro è attualmente riservato per l'uso del sistema; i driver non dovrebbero usarlo.

Capovolgi ora di destinazione e formato timestamp di destinazione

Quando il sistema operativo invia una richiesta flip alla coda di scorrimento hardware, invia anche il tempo di capovolgimento di destinazione. L'inversione può essere resa visibile all'utente dopo il raggiungimento del tempo di capovolgimento di destinazione.

Il sistema operativo usa le unità del contatore dell'orologio della CPU, ottenute da KeQueryPerformanceCounter, per passare il tempo dell'intervallo di destinazione e interpretare l'intervallo di tempo effettivo.

Invio di capovolgimenti in coda

La struttura DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3, passata alla funzione di callback DxgkDdiSetVidSourceAddressWithMultiPlaneOverlay3, è stata modificata come segue per abilitare l'invio di capovolgimenti in coda:

• I tre membri seguenti sono stati aggiunti alla struttura di DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS di OutputFlags. Per informazioni dettagliate su questi membri, vedere DxgkDdiSetVidSourceAddressWithMultiPlaneOverlay3 retry and failure cases (Casi di ripetizione e errori di DxgkDdiSetVidSourceAddressWithMultiPlaneOverlay3).

  • HwFlipQueueDrainNeeded
  • HwFlipQueueDrainAllPlanes
  • HwFlipQueueDrainAllSources

• È stato aggiunto un membro TargetFlipTime . TargetFlipTime descrive il tempo di capovolgimento di destinazione nelle unità QPC. Quando l'orologio raggiunge questo valore, il frame può essere inviato allo schermo rispettando i flag VSync e di strappo. In presenza di capovolgimenti in sospeso precedentemente accodati, il sistema operativo garantisce che per ogni piano MPO a cui fa riferimento la richiesta di inversione, TargetFlipTime è maggiore o uguale a uno qualsiasi dei tempi di destinazione capovolgimento in sospeso per questo piano. In altre parole, può esserci una sequenza di capovolgimenti con gli stessi timestamp o aumentando, ma non può esserci una sequenza che torna indietro nel tempo.

Casi di ripetizione e errore dxgkDdiSetVidSourceAddressWithMultiPlaneOverlay3

Mancata accodamento della richiesta all'hardware a causa di capovolgimenti in sospeso

Esistono diversi casi speciali che potrebbero impedire al KMD di accodare una richiesta di scorrimento mentre altre richieste di inversione sono in sospeso. In questi casi, kmd deve restituire STATUS_RETRY da DxgkDdiSetVidSourceAddressWithMultiPlaneOverlay3 e impostare HwFlipQueueDrainNeed uguale a 1. Il sistema operativo tenterà di inviare di nuovo la richiesta di scorrimento dopo che tutti i capovolgimenti in sospeso sui piani interessati dal capovolgimento vengono completati e una volta raggiunto il tempo di destinazione.

In alcuni casi, l'hardware di visualizzazione potrebbe richiedere il completamento di capovolgimenti in sospeso su tutti i piani, non solo quelli a cui fa riferimento la richiesta di inversione in ingresso. In questo caso, entrambi i flag HwFlipQueueDrainNeeded e HwFlipQueueDrainAllPlanes devono essere impostati su 1 e kmD deve restituire STATUS_RETRY.

Analogamente, l'hardware di visualizzazione potrebbe richiedere il completamento di capovolgimenti in sospeso su tutte le origini VidPn per riallocare le risorse interne, nel qual caso HwFlipQueueDrainAllSources e HwFlipQueueDrainNeededed flag devono essere impostati e il KMD deve restituire STATUS_RETRY.

Inoltre, kmd può indicare al sistema operativo se la reinviazione deve essere eseguita nel dispositivo IRQL (PrePresentNeeded impostato su 0) o se il sistema operativo deve eseguire questa chiamata a PASSIVE_LEVEL (PrePresentNeeded impostato su 1). Se kmd restituisce ancora STATUS_RETRY anche se non sono presenti più capovolgimenti in sospeso su vidPnSourceId, questa condizione viene considerata come un errore di parametro non valido.

È importante che il valore di MaxHwQueuedFlips rifletta comunque il numero massimo di modifiche semplici di modifica solo indirizzo che possono essere accodate a un piano MPO. Il meccanismo di STATUS_RETRY deve essere usato per richieste di scorrimento più complesse che non possono essere accodate in modo approfondito, ad esempio le modifiche alla configurazione del piano.

Errore di parametro non valido

Nel modello di coda di scorrimento hardware, la gestione del sistema operativo delle richieste di inversione non riuscite è stata rielaborata per consentire una migliore debugbilità. Quando kmd non è in grado di elaborare una richiesta flip, deve restituire STATUS_INVALID_PARAMETER da DxgkDdiSetVidSourceAddressWithMultiPlaneOverlay3. A seconda delle impostazioni del sistema operativo, il sistema operativo esegue una delle azioni seguenti:

• Interruzione del debugger del kernel e controllo dei bug: questo comportamento viene spesso abilitato nelle build di sviluppo/versione preliminare per migliorare il debug quando si verifica la condizione di errore.
• Live Kernel Dump seguito da un TDR: comportamento dell'utente finale al dettaglio.

Specifica del comportamento di interrupt VSync

Per ottenere un risparmio di energia negli scenari di capovolgimento in coda, il sistema operativo sospende spesso gli interrupt VSync regolari per mantenere la CPU in uno stato di basso consumo. Tuttavia, alcuni capovolgimenti sono contrassegnati come la richiesta di generazione di un interrupt per consentire all'applicazione di osservare il batch di regali completati e di accodare ulteriori operazioni. Esistono anche casi in cui le applicazioni richiedono di riattivarsi in ogni interrupt VSync indipendentemente dal fatto che siano presenti richieste di inversione in sospeso. Viceversa, in un sistema completamente inattiva, gli interrupt VSync vengono sospesi fino a quando non compaiono nuove attività di presentazione o listener VSync.

Per gestire tutti questi casi, sono stati introdotti il callback del driver e la struttura di callback seguenti:

• DXGKDDI_SETINTERRUPTTARGETPRESENTID
• DXGKARG_SETINTERRUPTTARGETPRESENTID

KmD fornisce un puntatore alla funzione DxgkDdiSetInterruptTargetPresentId in DRIVER_INITIALIZATION_DATA

Il sistema operativo chiama DxgkDdiSetInterruptTargetPresentId per specificare il PresentId di destinazione che dovrebbe generare un interrupt VSync generato al termine dell'inversione corrispondente. Questa funzione viene chiamata a livello di interrupt del dispositivo (DIRQL) per la sincronizzazione con DxgkDdiSetVidSourceAddress e l'interrupt VSync.

Interazione con DxgkDdiControlInterrupt

Quando gli interrupt VSync vengono disabilitati interamente tramite DxgkDdiControlInterrupt/DxgkDdiControlInterrupt2/DxgkDdiControlInterrupt3, rimangono disabilitati indipendentemente dal valore PresentId di destinazione interrupt. Il kmD è necessario per archiviare l'ID corrente della destinazione di interrupt più recente in modo che possa essere rispettato una volta che VSync è nuovamente abilitato.

Quando gli interrupt VSync vengono abilitati tramite DxgkDdiControlInterruptXxx, l'ID corrente della destinazione interrupt (pSetInterruptTargetPresentId) fornisce un controllo più granulare come indicato di seguito:

• Quando l'ID presente di destinazione è impostato su UINT64_MAX, non è necessario interrompere VSync fino a quando l'ID presente di destinazione non viene modificato di nuovo. Gli interrupt VSync sono disabilitati, ma il kmD è necessario per implementare DXGK_VSYNC_DISABLE_KEEP_PHASE comportamento per riattivare gli interrupt.

• Quando l'ID presente di destinazione è impostato su 0, gli interrupt sono necessari per ogni VSync.

• Per qualsiasi altro valore ID presente, gli interrupt vengono generati se l'oggetto PresentId >attualmente analizzato = InterruptTargetPresentId.

Quando sono disponibili più piani MPO, l'interrupt VSync deve essere generato se uno dei piani lo richiede.

Disabilitare VSync a 2 fasi con DxgkDdiSetInterruptTargetPresentId

Se la chiamata del sistema operativo a DxgkDdiSetInterruptTargetPresentId imposta un InterruptTargetPresentId su un piano che porterebbe a disabilitare completamente VSync in questo VidPnSource (ovvero questo piano era l'ultimo piano che ha mantenuto VSync abilitato e ora questo piano sta disabilitando anche VSync), KMD deve disabilitare gli interrupt VSync ma mantenere abilitata la fase VSync nell'hardware (DXGK_VSYNC_DISABLE_KEEP_PHASE). Dopo un determinato periodo di tempo (in genere equivalente a due periodi VSync), il sistema operativo seguirà una chiamata a DxgkDdiControlInterruptXxx con DXGK_VSYNC_DISABLE_NO_PHASE. Questa chiamata garantisce che kmd ottenga la possibilità di disabilitare la fase VSync e gli orologi VSync per risparmiare potenza massima e mantenere la parità delle prestazioni con i sistemi di scorrimento non partizioni.

Annullamento capovolgimento in coda

In casi come transizioni di stato a schermo intero o uscite dall'applicazione, potrebbe essere necessario annullare i futuri capovolgimenti in coda. Per gestire questi casi, sono stati introdotti il callback del driver e le strutture correlate seguenti:

• DXGKDDI_CANCELFLIPS
• DXGKARG_CANCELFLIPS
• DXGK_CANCELFLIPS_PLANE

KMD fornisce un puntatore alla funzione DxgkDdiCancelFlips in DRIVER_INITIALIZATION_DATA.

Il sistema operativo specifica l'intervallo di capovolgimenti in coda da annullare quando chiama DxgkDdiCancelFlips e kmD riporta al sistema operativo l'intervallo di capovolgimenti che è stato in grado di annullare in modo sincrono.

Nell'esempio seguente vengono illustrati i meccanismi e il caso sincrono di annullamento dello scorrimento su un singolo piano. Il sistema operativo non supporta l'annullamento asincrono in Windows 11 versione 22H2. Si supponga che i seguenti capovolgimenti vengano accodati alla coda di scorrimento hardware:

• PresentId N
• time t0 PresentId N+1
• time t1 PresentId N+2
• time t2 PresentId N+3
• time t3 PresentId N+4
• time t4

Il sistema operativo decide quindi di annullare l'inversione N+2, N+3 e N+4, quindi chiama DxgkDdiCancelFlips con PresentIdCancelRequested impostato su N+2.

Quando kmd controlla lo stato della coda di scorrimento hardware, determina che:

• Flip N+2 viene già inviato all'hardware di visualizzazione e non può essere annullato al momento della chiamata.
• I capovolgi N+3 e N+4 possono essere rimossi in modo sincrono dalla coda di scorrimento hardware senza effetti collaterali.

Di conseguenza, kmd imposta PresentIdCancelled suN+3 e completa N+2 come di consueto.

Il sistema operativo contrassegna N+3 e N+4 come annullato e considera N, N+1, N+2 come in anteprima. Quando vengono generati gli interrupt VSync successivi, il log della coda di scorrimento indicherà i timestamp per N, N+1, N+2 come di consueto.

L'intervallo di capovolgimenti annullati in modo sincrono deve essere continuo e, quando non zero, si presuppone che includa l'ultimo ID presente inviato al KMD. In altre parole, non possono esistere lacune all'interno di entrambi gli intervalli di capovolgimento annullati sincroni.

Annullamento di capovolgimenti interlock su più piani

Un flip interlocked viene inviato chiamando DxgkDdiSetVidSourceAddress con più piani e PresentIds. Il contratto tra il sistema operativo e il KMD segue:

• Il set di piani deve essere reso visibile sullo stesso VSync.
• L'hardware di visualizzazione non è autorizzato a visualizzare solo un subset di questi piani su un VSync e il resto sul VSync successivo.

Nel modello di coda di scorrimento hardware, tali capovolgimenti interlock vengono annullati passando più piani e PresentId nella chiamata a DxgkDdiCancelFlips. Il set di piani passati in questi casi deve corrispondere a una richiesta di capovolgimento interlock in sospeso e la decisione del KmD relativa a tutti i PresentId interlocked deve essere la stessa:

• Non annullare o
• Annullare in modo sincrono

DxgkDdiCancelFlips viene chiamato a livello di interrupt del dispositivo (DIRQL) per la sincronizzazione con DxgkDdiSetVidSourceAddress e interrupt VSync.

Recupero delle statistiche presenti per i capovolgimenti in coda

Poiché l'approccio alla coda di scorrimento hardware consiste nell'evitare di svegliare la CPU in ogni VSync, è necessario un meccanismo per mantenere i tempi di visualizzazione dei fotogrammi per gli ultimi capovolgimenti in coda.

I driver grafici che supportano la coda di scorrimento hardware devono scrivere informazioni nel buffer di log delle code flip fornito dal sistema operativo per ogni capovolgimento completato o annullato per un determinato piano MPO per ogni VidPnSource attivo.

Il sistema operativo garantisce di fornire il puntatore del log della coda di scorrimento (in una chiamata a DxgkDdiSetFlipQueueLogBuffer) prima della prima chiamata DxgkDdiSetVidSourceAddress per un determinato piano MPO per ogni VidPnSource attivo. Il sistema operativo può eliminare definitivamente il buffer del log della coda di scorrimento quando la coda flip non ha richieste in sospeso. In questo caso, fornirà un nuovo puntatore di log prima della successiva chiamata DxgkDdiSetVidSourceAddress . Il log della coda di scorrimento è circolare. Dopo aver scritto la voce [NumberOfEntries-1], la voce di log successiva è [0].

Al termine di un batch di capovolgimenti in coda, kmd deve garantire che il log delle code di scorrimento per i capovolgimenti completati venga aggiornato al più presto di questi due punti nel tempo:

• Gestore interrupt VSync per un capovolgimento che richiede la generazione di un interrupt.
• In risposta a una richiesta DxgkDdiUpdateFlipQueueLog esplicita dal sistema operativo.

Capovolgere le DDI del log della coda

Sono stati aggiunti i callback correlati al log delle code capovolti seguenti e le strutture associate:

• DXGKDDI_SETFLIPQUEUELOGBUFFER

• DXGKARG_SETFLIPQUEUELOGBUFFER

• DXGK_FLIPQUEUE_LOG_ENTRY

• DXGKDDI_UPDATEFLIPQUEUELOG

• DXGKARG_UPDATEFLIPQUEUELOG

KmD fornisce un puntatore alle relative funzioni in DRIVER_INITIALIZATION_DATA.

Aggiornamenti della struttura degli interrupt VSync

Sono state apportate le modifiche seguenti alla struttura DXGKARGCB_NOTIFY_INTERRUPT_DATA per implementare gli interrupt VSync per il modello di coda di scorrimento hardware:

• Il valore di enumerazione DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 è stato aggiunto come InterruptType.
• La struttura CrtcVSyncWithMultiPlaneOverlay3 è stata aggiunta all'unione. La semantica di CrtcVSyncWithMultiPlaneOverlay3 è simile alla struttura CrtcVSyncWithMultiPlaneOverlay2 , ad eccezione del fatto che anziché un singolo PresentId completato per ogni piano, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo punta all'intervallo di PresentId non segnalati in precedenza dal log delle code flip.
• La struttura DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 è stata aggiunta per il membro pMultiPlaneOverlay3 di CrtcVSyncSyncWithMultiPlaneOverlayVSyncInfo.

Usando di nuovo il diagramma di esempio della coda di scorrimento hardware di base:

Si supponga che FirstFreeFlipQueueLogEntryIndex sia stato impostato su 40 al momento dell'invio di N e quindi N, N+1, N+2 regali sono stati completati.

Al termine della configurazione di un singolo piano sono stati completati tre Oggetti PresentIdS N, N+1 e N+2 rispettivamente v2, v3, v4, KMD ha scritto tre nuove voci nel buffer dei log delle code capovolte con indici 40, 41 e 42. KMD segnala un valore FirstFreeFlipQueueLogEntryIndex pari a 43 nella struttura CrtcVSyncWithMultiPlaneOverlay3. Il sistema operativo osserva che FirstFreeFlipQueueLogEntryIndex è cambiato da 40 a 43 e legge dalle voci di log 40, 41 e 42. Il servizio di gestione delle chiavi deve impostare i valori seguenti del buffer del log della coda di scorrimento come indicato di seguito:

• VidPnTargetId: stesso significato di in CrtcVSyncWithMultiPlaneOverlay2

• PhysicalAdapterMask: lo stesso significato di in CrtcVSyncWithMultiPlaneOverlay2

• MultiPlaneOverlayVSyncInfoCount = 1

• pMultiPlaneOverlayVSyncInfo[0].LayerIndex = 0

• pMultiPlaneOverlayVSyncInfo[0].FirstFreeFlipQueueLogEntryIndex = 43

• LogBufferAddressForPlane0[40].PresentId = N

• LogBufferAddressForPlane0[40].PresentTimestamp = v2

• LogBufferAddressForPlane0[41].PresentId = N+1

• LogBufferAddressForPlane0[41].PresentTimestamp = v3

• LogBufferAddressForPlane0[42].PresentId = N+2

• LogBufferAddressForPlane0[42].PresentTimestamp = v4

Richiesta esplicita di aggiornamento del log delle code di scorrimento

Esistono casi in cui il sistema operativo deve ottenere informazioni sull'ultimo batch completato di capovolgimenti senza dover attendere l'interrupt VSync. In questi casi, il sistema operativo effettua una chiamata esplicita a DxgkDdiUpdateFlipQueueLog per richiedere che kmD legga dalla struttura dei dati hardware di visualizzazione proprietaria e scriva le informazioni precedenti sullo scorrimento nel log delle code di scorrimento. La semantica del log è identica a quella descritta in precedenza; l'unica modifica è che FirstFreeFlipQueueLogEntryIndex viene restituito al sistema operativo all'esterno dell'interrupt VSync.

DxgkDdiUpdateFlipQueueLog viene chiamato a livello di interrupt del dispositivo (DIRQL) e si trova nella stessa classe di sincronizzazione di DxgkDdiSetVidSourceAddressWithMultiPlaneOverlay3 DDI.

Modifiche alla modalità di visualizzazione e transizioni di alimentazione in presenza di un capovolgimento in coda nell'hardware

Dxgkrnl garantisce che i capovolgimenti già in coda nella coda di capovolgimento hardware vengano completati o annullati prima di avviare una modifica della modalità o spegnere il monitor.

Mapping delle richieste presenti ai timestamp della coda di scorrimento hardware

Quando la coda di scorrimento hardware è abilitata in un adattatore specifico, un timestamp accompagna tutte le chiamate capovolte. In altre parole, kmd non deve gestire una combinazione di semantica DxgkDdiSetVidSourceAddress precedente e nuova.

Il sistema operativo converte automaticamente le richieste dell'API Present basate su intervalli esistenti in chiamate flip basate su timestamp a KMD. Le sezioni seguenti illustrano diversi casi e come vengono mappati a una combinazione di flag, durata e timestamp ricevuti dal KmD.

Semantica di capovolgimento e non di scorrimento

La semantica dei capovolgimenti di strappo è concettualmente identica quando è abilitata la coda di scorrimento hardware. Una volta raggiunto TargetFlipTime, il KMD deve inviare lo scorrimento per la visualizzazione mentre rispetta ancora i flag come FlipImmediate, FlipImmediateNoTearing e FlipOnNextVSync. In altre parole, kmd dovrebbe comportarsi come se il sistema operativo ha inviato lo scorrimento esattamente a TargetFlipTime con gli stessi flag e parametri flip.

Ad esempio, se FlipOnNextVSync è impostato su 1 e TargetFlipTime si trova al centro del fotogramma, lo scorrimento deve essere visualizzato solo sulla VSync successiva.

Supporto di FlipOverwrite e coda di scorrimento hardware

La coda di scorrimento hardware è un superset rigoroso della funzionalità di sovrascrittura capovolgimento controllata dal valore MaxQueuedMultiPlaneOverlayFlipVSync in DXGK_DRIVERCAPS.

Pertanto, il sistema operativo ignora il valore MaxQueuedMultiPlaneOverlayFlipVSync se il driver opta per la coda di scorrimento hardware impostando MaxHwQueuedFlips su un valore maggiore di 1.

Più capovolgimenti con un TargetFlipTime scaduto

Quando sono presenti più capovolgimenti in coda con un TargetFlipTime scaduto per un determinato piano MPO, la coda di visualizzazione hardware deve selezionare il capovolgimento scaduto più recente in coda e inviarlo per la visualizzazione. Il resto dei capovolgimenti scaduti deve essere considerato annullato e le voci corrispondenti del log delle code di scorrimento devono contenere DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED come valori PresentTimestamp .

Interazione tra Durata e TargetFlipTime

Il parametro Duration nella struttura DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 deve essere applicato quando viene visualizzato lo scorrimento specificato in questa struttura sullo schermo. Specifica il nuovo comportamento di frequenza di aggiornamento dello schermo desiderato per l'output specificato da VidPnSourceId in tutti i piani. Nelle versioni WDDM 3.1 e Windows Server 2022, per semplificare l'implementazione del driver per l'hardware che non supporta le modifiche della durata personalizzata in coda, il sistema operativo invia solo richieste flip con un nuovo parametro Duration dopo il completamento delle richieste di capovolgimento precedenti.

Mapping degli intervalli presenti a TargetFlipTime

Intervalli di mapping quando la frequenza di aggiornamento è fissa

Per mantenere la semantica dell'intervallo presente esistente, il sistema operativo deve calcolare il tempo di capovolgimento di destinazione usando l'intervallo corrente e la frequenza di aggiornamento. Tuttavia, impostando l'ora di capovolgimento di destinazione esattamente sull'ora VSync desiderata in corrispondenza della quale il capovolgimento dovrebbe colpire lo schermo genera frequenti errori. Questi glitch sono dovuti alla mancata sincronizzazione VSync quando la tempistica effettiva di VSync deriva un po'. Per proteggersi dagli errori, il sistema operativo sottrae metà dell'intervallo VSync dal tempo di capovolgimento della destinazione calcolata.

Ecco una formula semplificata per eseguire il mapping dell'intervallo corrente al tempo di capovolgimento di destinazione:

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FixedRefreshRate / 2)

Intervalli di mapping quando è presente la funzionalità WDDM 2.9 della frequenza di aggiornamento virtuale

La funzionalità di frequenza di aggiornamento virtuale potrebbe aumentare temporaneamente la frequenza di aggiornamento dello schermo a un multiplo intero della frequenza di aggiornamento corrente (ovvero, 24 Hz può essere incrementata a 144 Hz o 192 Hz). Per i dispositivi in grado di supportare questo boost, la formula nella sezione precedente viene modificata per usare il multiplo più veloce della frequenza di aggiornamento corrente:

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FastestRefreshRate / 2)

Intervalli di mapping quando la frequenza di aggiornamento viene modificata in una nonmultiple

Quando la frequenza di aggiornamento viene modificata in un nonmultiple di una frequenza di aggiornamento corrente (ad esempio, da 24 Hz a 60 Hz), il sistema operativo deve controllare le capovolgimenti della coda per verificare se il tempo di destinazione calcolato è ancora valido per la nuova frequenza di aggiornamento. Se è necessario modificare il tempo di capovolgimento di destinazione, il sistema operativo annulla i capovolgimenti in coda e li accoda con i tempi di capovolgimento di destinazione appena calcolati.