Hardware-Flip-Warteschlange

In diesem Artikel wird die Hardware-Flip-Warteschlangenfunktion beschrieben, das ab Windows 11 (WDDM 3.0) unterstützt wird. Eine Hardware-Flip-Warteschlange ermöglicht die Übermittlung mehrerer zukünftiger Frames an die Anzeigecontrollerwarteschlange. Die CPU und Teile der GPU können in einen niedrigeren Energiesparmodus wechseln, während der Anzeigecontroller mehrere in die Warteschlange gestellte Frames verarbeitet. Dies verbessert die Energieeffizienz bei der Videowiedergabe auf entsprechender Hardware.

Vorab-WDDM 3.0 Flip-Warteschlangenmodell

Viele moderne Anzeigecontroller unterstützen die Möglichkeit, mehrere Frames in die Warteschlange zu stellen, die in einer Sequenz angezeigt werden sollen. Ab WDDM 2.1 unterstützt das Betriebssystem mehrere ausstehende Flip-Overwrite-Anfragen, die beim nächsten VSync angezeigt werden sollen. Der Miniporttreiber (Display Miniport Driver, KMD) gibt diese Unterstützung über den MaxQueuedMultiPlaneOverlayFlipVSync-Wert in DXGK_DRIVERCAPS an. Diese Funktion ist nützlich, um die Latenz in Gaming-Szenarien mit hoher Bildfrequenz zu reduzieren, in denen mehrere Frames nacheinander mit dem Intervall 0 gerendert werden, mit der Absicht, nur das aktuellste Frame anzuzeigen.

In Videowiedergabeszenarien ist der Inhalt mehrerer zukünftiger Frames, die sequenziell angezeigt werden sollen, im Voraus bekannt und kann an die GPU in die Warteschlange gestellt werden. Durch diese erweiterte Warteschlange kann die CPU in einen Energiesparzustand wechseln, während die in die Warteschlange gestellten Frames verarbeitet werden, was zu erheblichen Energieeinsparungen führt. Vor WDDM 3.0 gab es jedoch keinen Mechanismus für das Betriebssystem, mehr als einen Frame zu übermitteln, der für mindestens ein VSync-Intervall auf dem Bildschirm bleiben muss, ohne weitere CPU-Interventionen zu benötigen. Im Abschnitt Grundlegende Hardware-Flip-Warteschlange stellt eine Lösung vor, die es der CPU ermöglicht, in einen Energiesparzustand zu wechseln und die Verarbeitung in der Warteschlange stehender Frames auf die GPU zu verlagern.

In Gaming-Szenarien vor WDDM 3.0 erfolgt, bevor die GPU mit dem Rendern der Szene in den Swapchain-Hintergrundpuffer fertig ist, ein Roundtrip zur CPU, um die Anforderung zur Darstellung des Frame-Inhalts auf dem Bildschirm zu übermitteln. Bei schweren GPU-Workloads, die nahe der VSync enden, kann dieser Roundtrip dazu führen, dass Frames verzögert werden und die beabsichtigte Zielzeit verpasst wird, was zu observierbaren Framestörungen führt. Der Abschnitt "Erweiterte Hardware flip queue " führt einen Mechanismus ein, um dieses CPU-Roundtrip zu vermeiden und abgeschlossene Frames mit geringer Latenz auf dem Bildschirm darzustellen. Die erweiterte Hardware-Flip-Warteschlange erfordert sowohl die grundlegende Hardware Flip-Warteschlange als auch die GPU-Hardwareplanungsphase 2, um vorhanden zu sein.

Grundlegende Hardware-Flip-Warteschlange

Das folgende Diagramm veranschaulicht die Darstellung von drei Frames, die jeweils für ein VSync-Intervall auf dem Bildschirm angezeigt werden.

Das Füllmuster im Diagramm zeigt die Zeiten, zu denen die Software-Flip-Queue-Verarbeitung und die Anwendungs-Threads von dxgkrnl aktiviert werden und CPU-Arbeit verrichten müssen. Auf jedem VSync muss der Anzeigecontroller eine CPU-Benachrichtigung an das Betriebssystem für den abgeschlossenen Flip ausgeben, und das Betriebssystem muss die nächste Flip-Anforderung übermitteln. Die Anwendung muss außerdem bei jedem VSync aktiviert werden und aktuelle Statistiken abfragen, um schließlich zu erfahren, wann das letzte Frame im Dreier-Batch angezeigt wird.

Hardware-Flip-Warteschlangen-DDIs, die mehrere zukünftige Frames an die Warteschlange des Anzeigecontrollers senden können, sind ab WDDM 3.0 verfügbar. Wie bereits erwähnt, ermöglicht dieser Mechanismus der CPU und Teile der GPU den Übergang zu niedrigeren Leistungszuständen, während der Anzeigecontroller mehrere in die Warteschlange eingereihte Frames verarbeitet. Dieser Übergang verbessert die Energieeffizienz von Videowiedergabeszenarien auf fähiger Hardware.

Das folgende Diagramm veranschaulicht die vorgeschlagene Architektur.

Beim Hardware-Flip-Queue-Ansatz sind sowohl die Anwendung als auch die Dxgkrnl -CPU-Komponenten für zwei VSync-Intervalle zwischen den Zeitpunkten v2 und v4 vollständig im Leerlauf, wodurch die CPU in einen Energiesparzustand wechseln kann. Die CPU wird erst benachrichtigt, wenn der Frame N+2, auf den die Anwendung gewartet haben möchte, abgeschlossen ist.

Erweiterte Hardware-Flip-Warteschlange

In Gaming-Szenarien vor WDDM 3.0 erfolgt, bevor die GPU mit dem Rendern der Szene in den Swapchain-Hintergrundpuffer fertig ist, ein Roundtrip zur CPU, um die Anforderung zur Darstellung des Frame-Inhalts auf dem Bildschirm zu übermitteln. Im folgenden Diagramm wird dieses Szenario veranschaulicht.

Die Kosten dieses Roundtrips können dazu führen, dass Frames ihr Ziel verpassen, wenn das Rendern zu nah an der VSync erfolgt ist, wie im folgenden Diagramm dargestellt.

Einige Anzeigecontroller unterstützen systemeigene Wartezeiten, mit denen die Anzeige die Flip-Anforderung übermitteln kann, sobald die GPU das Rendern des Frames ohne CPU-Roundtrip durchgeführt hat. Da die Hardware-Flip-Warteschlange den abgeschlossenen Frame N ohne CPU-Roundtrip an die Anzeige übermitteln kann, kann es verpasste Frames vermeiden, wie im folgenden Diagramm dargestellt.

Der Rest dieses Artikels befasst sich mit der grundlegenden Hardware-Flip-Warteschlangenfunktion.

DDI-Support

Die folgenden DDIs wurden hinzugefügt, um die Hardware-Flip-Warteschlangenfunktion zu unterstützen.

Überprüfen der Verfügbarkeit von Funktionen

Für die Hardware-Flip-Warteschlange ist eine Aktivierungs-/Deaktivierungsaushandlung durch das Betriebssystem erforderlich. Ein KMD, das die Hardware-Flip-Warteschlange unterstützt, muss beim Gerätestart zunächst DXGKCB_QUERYFEATURESUPPORT mit einer FeatureId von DXGK_FEATURE_HWFLIPQUEUE aufrufen, um zu ermitteln, ob das Betriebssystem die Aktivierung der Hardware-Flip-Warteschlange zulässt.

Die Hardware-Flip-Warteschlange kann nur verwendet werden, wenn der Rückruf erfolgreich ist und Enable auf TRUE gesetzt ist.

Ein KMD kann den folgenden Beispielcode während der Aktivierungs- und Experimentierphase der Hardware-Flip-Warteschlange verwenden.

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.
}

Obwohl es beim Hochfahren des Treibers möglich ist, die Hardware-Flip-Warteschlange zu aktivieren, ohne die GPU-Hardwareplanung zu aktivieren, wird diese Kombination nicht offiziell unterstützt. Windows erfordert derzeit, dass die GPU-Hardwareplanung aktiviert wird, damit grundlegende Hardware-Flip-Warteschlange auf offiziell veröffentlichten Treibern aktiviert werden kann.

Angeben von Hardwarewarteschlangenfähigkeiten

MaxHwQueuedFlips wurde DXGK_DRIVERCAPS hinzugefügt, um die Hardware-Flip-Warteschlangenunterstützung anzugeben. Wenn das Betriebssystem die Unterstützung der Hardware-Flip-Warteschlange wie zuvor beschrieben zugelassen hat, sollte eine KMD, die eine Hardware-Flip-Warteschlange unterstützt, MaxHwQueuedFlips auf einen Wert größer als 1 festlegen. Wenn MaxHwQueuedFlips größer als 1 ist, gibt KMD an, dass die Anzeigehardware bis zu MaxHwQueuedFlips zukünftige Frames unterstützt, die für eine bestimmte VidPnSource auf der GPU in die Warteschlange gestellt werden können. Das Betriebssystem berücksichtigt vom Treiber bereitgestellte Einschränkungen für die Art der Flips, die im Voraus in die Warteschlange gestellt werden können.

HwQueuedFlipCaps wurde auch zu DXGK_DRIVERCAPS hinzugefügt. Dieses Mitglied ist zurzeit für die Systemverwendung reserviert; Treiber sollten sie nicht verwenden.

Ziel-Zeit- und Zielzeitstempelformat flippen

Wenn das Betriebssystem eine Flip-Anforderung an die Hardware-Flip-Warteschlange sendet, sendet es auch die Ziel-Flip-Zeit. Der Flip kann für den Benutzer sichtbar gemacht werden, nachdem die Ziel-Flip-Zeit erreicht wurde.

Das Betriebssystem verwendet die CPU-Taktzählereinheiten, die von KeQueryPerformanceCounter abgerufen werden, um die Zielframezeit zu übergeben und die tatsächliche Framezeit zu interpretieren.

Übermitteln von in die Warteschlange gestellten Flips

Die Struktur DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3, die an die Rückruffunktion DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 von KMD übergeben wird, wurde wie folgt geändert, um die Übermittlung von in die Warteschlange gestellten Flips zu ermöglichen:

• Die folgenden drei Elemente wurden der OutputFlags-Struktur von DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS hinzugefügt. Details zu diesen Mitgliedern finden Sie unter DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3-Wiederholungs- und Fehlerfälle .

  • HwFlipQueueDrainNeeded
  • HwFlipQueueDrainAllPlanes
  • HwFlipQueueDrainAllSources

• Ein TargetFlipTime-Mitglied wurde hinzugefügt. TargetFlipTime beschreibt die Ziel-Flip-Zeit in QPC-Einheiten. Wenn die Uhr diesen Wert erreicht, kann der Frame an die Anzeige gesendet werden, während VSync und zerreißende Flags berücksichtigt werden. Bei Vorhandensein von zuvor in die Warteschlange gestellten ausstehenden Flips garantiert das Betriebssystem, dass für jede von der Flip-Anforderung referenzierte MPO-Ebene TargetFlipTime größer oder gleich einer der ausstehenden Flip-Ziel-Zeiten für diese Ebene ist. Mit anderen Worten, es kann eine Sequenz von Flips mit demselben oder zunehmenden Zeitstempel geben, aber es kann keine Sequenz geben, die in der Zeit zurückgeht.

DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 Wiederholungs- und Fehlerfälle

Fehler, die Anforderung an die Hardware in die Warteschlange zu stelle aufgrund ausstehender Flips

Es gibt mehrere Spezielle Fälle, die verhindern können, dass KMD eine Flip-Anforderung in die Warteschlange stellt, während andere Flip-Anforderungen ausstehen. In solchen Fällen sollte KMD STATUS_RETRY von DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 zurückgeben und HwFlipQueueDrainNeeded auf 1 festlegen. Das Betriebssystem versucht erneut, die Flip-Anforderung zu übermitteln, nachdem alle ausstehenden Flips auf Flugzeugen, die von der Flip betroffen sind, abgeschlossen sind und sobald die Zielzeit erreicht ist.

In einigen Fällen erfordert die Anzeigehardware möglicherweise den Abschluss ausstehender Flips auf allen Ebenen, nicht nur die, auf die von der eingehenden Flip-Anforderung verwiesen wird. In diesem Fall sollten sowohl die HwFlipQueueDrainNeededed - als auch die HwFlipQueueDrainAllPlanes-Flags auf 1 festgelegt werden, und KMD sollte STATUS_RETRY zurückgeben.

Entsprechend erfordert die Anzeigehardware möglicherweise den Abschluss ausstehender Flips auf allen VidPn-Quellen, um interne Ressourcen neu zuzuordnen, in diesem Fall müssen die HwFlipQueueDrainAllSources und HwFlipQueueDrainNeeded-Flags festgelegt werden, und KMD sollte STATUS_RETRY zurückgeben.

Darüber hinaus kann KMD für das Betriebssystem angeben, ob die erneute Bereitstellung an der IRQL des Geräts (PrePresentNeededed auf 0 festgelegt) erfolgen soll, oder ob das Betriebssystem diesen Aufruf bei PASSIVE_LEVEL ausführen soll (PrePresentNeeded auf 1 festgelegt). Wenn KMD weiterhin STATUS_RETRY zurückgibt, obwohl keine flips mehr auf dieser VidPnSourceId vorhanden sind, wird diese Bedingung als ungültiger Parameterfehler behandelt.

Es ist wichtig, dass der Wert von MaxHwQueuedFlips immer noch die maximale Anzahl einfacher Adressänderungsänderungen widerspiegelt, die in eine MPO-Ebene in die Warteschlange gestellt werden können. Der STATUS_RETRY Mechanismus sollte für komplexere Flip-Anforderungen verwendet werden, die nicht tief in die Warteschlange gestellt werden können, z. B. Ebenenkonfigurationsänderungen.

Ungültiger Parameterfehler

Im Hardware-Flip-Warteschlangenmodell wurde die Behandlung fehlgeschlagener Flip-Anforderungen des Betriebssystems überarbeitet, um eine bessere Debugbarkeit zu ermöglichen. Wenn KMD eine Flip-Anforderung nicht verarbeiten kann, sollte sie STATUS_INVALID_PARAMETER von DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 zurückgeben. Je nach Betriebssystemeinstellungen führt das Betriebssystem eine der folgenden Aktionen aus:

• Kerneldebuggerunterbrechung und Fehlerüberprüfung: Dieses Verhalten wird häufig für die Entwicklung /Vorabversion von Builds aktiviert, um die Debugbarkeit zu verbessern, wenn die Fehlerbedingung auftritt.
• Live Kernel Dump gefolgt von einem TDR: Das Verhalten des Endbenutzers für den Einzelhandel.

Angeben des VSync-Unterbrechungsverhaltens

Um Leistungseinsparungen in Szenarien mit in der Warteschlange ausgeführten Flip-Szenarien zu erzielen, hält das Betriebssystem häufig normale VSync-Unterbrechungen an, um die CPU im Energiesparmodus zu halten. Einige Flips sind jedoch so gekennzeichnet, dass eine Unterbrechung ausgelöst werden muss, damit die Anwendung die Menge der abgeschlossenen Präsentierten beobachten und weitere Arbeiten in die Warteschlange stellen kann. Es gibt auch Fälle, in denen Anwendungen anfordern, bei jedem VSync-Interrupt zu reaktivieren, unabhängig davon, ob ausstehende Flip-Anforderungen vorhanden sind. Umgekehrt werden VSync-Unterbrechungen auf einem vollständig im Leerlauf befindlichen System angehalten, bis neue Präsentationsaktivitäten oder VSync-Listener angezeigt werden.

Um all diese Fälle zu behandeln, wurden die folgenden Treiberrückruf- und Rückrufstruktur eingeführt:

• DXGKDDI_SETINTERRUPTTARGETPRESENTID
• DXGKARG_SETINTERRUPTTARGETPRESENTID

KMD stellt einen Zeiger auf die DxgkDdiSetInterruptTargetPresentId-Funktion in DRIVER_INITIALIZATION_DATA

Das Betriebssystem ruft DxgkDdiSetInterruptTargetPresentId auf, um die Ziel-PresentId anzugeben, die dazu führen soll, dass ein VSync-Interrupt ausgelöst wird, wenn der entsprechende Flip abgeschlossen ist. Diese Funktion wird auf Geräteunterbruchebene (DIRQL) aufgerufen, um mit DxgkDdiSetVidPnSourceAddress und dem VSync-Interrupt zu synchronisieren.

Interaktion mit DxgkDdiControlInterrupt

Wenn VSync-Interrupts vollständig über DxgkDdiControlInterrupt/DxgkDdiControlInterrupt2/DxgkDdiControlInterrupt3 deaktiviert werden, bleiben sie unabhängig vom PresentId-Wert des Interrupt-Ziels deaktiviert. KMD ist erforderlich, um die aktuelle Interruptziel-Present-ID zu speichern, damit sie berücksichtigt werden kann, sobald VSync erneut aktiviert ist.

Wenn VSync-Interrupts über DxgkDdiControlInterruptXxx aktiviert werden, ermöglicht die aktuelle Interrupt-Ziel-ID (pSetInterruptTargetPresentId) eine feinere Steuerung wie folgt:

• Wenn die Aktuelle Ziel-ID auf UINT64_MAX festgelegt ist, ist in Zukunft kein VSync-Interrupt erforderlich, bis die Ziel-ID erneut geändert wird. VSync-Interrupts sind deaktiviert, aber KMD muss das Verhalten DXGK_VSYNC_DISABLE_KEEP_PHASE implementieren, um Interrupts wieder zu aktivieren.

• Wenn die Aktuelle Ziel-ID auf 0 festgelegt ist, sind Unterbrechungen für jede VSync erforderlich.

• Für alle anderen aktuellen ID-Werte werden Unterbrechungen ausgelöst, wenn die aktuell gescannte PresentId >= InterruptTargetPresentId.

Wenn mehrere MPO-Ebenen verfügbar sind, sollte der VSync-Interrupt ausgelöst werden, wenn eines der Ebenen dies erfordert.

2-Phasen-VSync mit DxgkDdiSetInterruptTargetPresentId deaktivieren

Wenn der Os-Aufruf von DxgkDdiSetInterruptTargetPresentId eine InterruptTargetPresentId auf einer Ebene festlegt, die dazu führen würde, VSync vollständig auf dieser VidPnSource zu deaktivieren (d. h., diese Ebene war die letzte Ebene, die VSync aktiviert hat, und jetzt deaktiviert diese Ebene auch VSync deaktiviert), sollte KMD VSync-Unterbrechungen deaktivieren, aber die VSync-Phase in der Hardware aktiviert halten (DXGK_VSYNC_DISABLE_KEEP_PHASE). Nach einem bestimmten Zeitraum (in der Regel entspricht zwei VSync-Zeiträumen) folgt das Betriebssystem einem Aufruf von DxgkDdiControlInterruptXxx mit DXGK_VSYNC_DISABLE_NO_PHASE. Dieser Aufruf stellt sicher, dass KMD die Möglichkeit erhält, die VSync-Phase und die VSync-Takte zu deaktivieren, um maximale Leistung zu sparen und die Leistungsparität mit nichthardware Flip-Warteschlangensystemen aufrechtzuerhalten.

In die Warteschlange eingereihter Flip-Abbruch

In Fällen wie Vollbildzustandsübergängen oder Anwendungsausgängen müssen zukünftige Flips in der Warteschlange möglicherweise abgebrochen werden. Um diese Fälle zu behandeln, wurden der folgende Treiberrückruf und zugehörige Strukturen eingeführt:

• DXGKDDI_CANCELFLIPS
• DXGKARG_CANCELFLIPS
• DXGK_CANCELFLIPS_PLANE

KMD stellt einen Zeiger auf die DxgkDdiCancelFlips-Funktion in DRIVER_INITIALIZATION_DATA.

Das Betriebssystem gibt den Bereich der in der Warteschlange befindlichen Flips an, die abgebrochen werden sollen, wenn es DxgkDdiCancelFlips aufruft, und KMD meldet dem Betriebssystem den Bereich der Flips zurück, den es synchron abbrechen konnte.

Das folgende Beispiel veranschaulicht die Mechanik und synchrone Groß-/Kleinschreibung des Flip-Abbruchs auf einer einzelnen Ebene. (Das Betriebssystem unterstützt keinen asynchronen Abbruch in Windows 11, Version 22H2.) Stellen Sie sich vor, dass die folgenden Flips in die Hardware-Flip-Warteschlange eingereiht werden:

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

Das Betriebssystem beschließt dann, die Flips N+2, N+3 und N+4 abzubrechen also ruft es DxgkDdiCancelFlips auf, wobei PresentIdCancelRequested auf N+2 gesetzt ist.

Wenn KMD den Zustand der Hardware-Flip-Warteschlange überprüft, bestimmt er Folgendes:

• Flip N+2 wird bereits an die Anzeigehardware gesendet und kann zum Zeitpunkt des Anrufs nicht abgebrochen werden.
• Flips N+3 und N+4 können synchron aus der Hardware Flip-Warteschlange ohne Nebeneffekte entfernt werden.

Daher legt KMD PresentIdCancelled auf N+3 fest und schließt N+2 wie gewohnt ab.

Das Betriebssystem kennzeichnet N+3 und N+4 als abgebrochen, und es behandelt N, N+1, N+2 als Test-Flight.The OS marks N+3 and N+4 as canceled, and it treats N+1, N+2 as being in flight. Wenn die nächsten VSync-Unterbrechungen ausgelöst werden, zeigt das Flip-Warteschlangenprotokoll die Zeitstempel für N, N+1, N+2 wie gewohnt an.

Der Bereich der synchron abgebrochenen Flips muss kontinuierlich sein und wird, wenn er nicht Null ist, als die letzte aktuelle ID, die an KMD übermittelt wurde, eingeschlossen angesehen. Mit anderen Worten, es können keine Lücken innerhalb der synchronen abgebrochenen Flip-Bereiche vorhanden sein.

Abbrechen von verriegelten Flips auf mehreren Ebenen

Ein verriegelter Flip wird durch Aufrufen von DxgkDdiSetVidPnSourceAddress mit mehreren Ebenen und PresentIds übermittelt. Der Vertrag zwischen Betriebssystem und KMD folgt:

• Die Gruppe von Ebenen muss auf demselben VSync sichtbar gemacht werden.
• Die Anzeigehardware darf nicht nur eine Teilmenge dieser Ebenen auf einem VSync anzeigen, und der Rest auf der nächsten VSync.

Im Hardware-Flip-Warteschlangenmodell werden solche ineinandergreifenden Flips abgebrochen, indem im Aufruf von DxgkDdiCancelFlips mehrere Ebenen übergeben werden. Die in solchen Fällen übergebene Gruppe von Ebenen muss einer ausstehenden Anforderung für einen ineinandergreifenden Flip entsprechen, und die Entscheidung von KMD bezüglich aller ineinandergreifenden PresentIds muss dieselbe sein:

• Nicht abbrechen oder
• Synchrones Abbrechen

DxgkDdiCancelFlips wird auf geräteunterbrecherischer Ebene (DIRQL) aufgerufen, um mit DxgkDdiSetVidPnSourceAddress und VSync-Interrupt zu synchronisieren.

Abrufen vorhandener Statistiken für in die Warteschlange eingereihte Flips

Da der Ansatz der Hardware-Flip-Warteschlange das Aufwachen der CPU auf jedem VSync vermeiden soll, muss es einen Mechanismus geben, um Frameanzeigezeiten für die letzten in die Warteschlange eingereihten Flips beizubehalten.

Grafiktreiber, die die Hardware-Flip-Warteschlange unterstützen, müssen Informationen in den vom Betriebssystem bereitgestellten Flip-Warteschlangenprotokollpuffer für jeden abgeschlossenen oder abgebrochenen Flip für eine bestimmte MPO-Ebene für jede aktive VidPnSource schreiben.

Das Betriebssystem garantiert, dass der Zeiger des Flip-Warteschlangenprotokolls (in einem Aufruf von DxgkDdiSetFlipQueueLogBuffer) vor dem ersten DxgkDdiSetVidPnSourceAddress-Aufruf für eine bestimmte MPO-Ebene für jede aktive VidPnSource bereitgestellt wird. Das Betriebssystem darf den Puffer des Flip-Warteschlangenprotokolls zerstören, wenn die Flip-Warteschlange keine ausstehenden Anforderungen enthält. In diesem Fall wird ein neuer Protokollzeiger vor dem nächsten DxgkDdiSetVidPnSourceAddress-Aufruf bereitgestellt. Das Flip-Warteschlangenprotokoll ist zirkelförmig. Nachdem der [NumberOfEntries-1]-Eintrag geschrieben wurde, lautet der nächste Protokolleintrag [0].

Nachdem eine Reihe von in die Warteschlange gestellten Flips abgeschlossen wurde, muss KMD sicherstellen, dass das Flip-Warteschlangenprotokoll für die abgeschlossenen Flips frühestens zu diesen beiden Zeitpunkten aktualisiert wird:

• Ein VSync-Interrupthandler für einen Flip, für den ein Interrupt ausgelöst werden muss.
• Als Reaktion auf eine explizite DxgkDdiUpdateFlipQueueLog-Anforderung vom Betriebssystem.

Flip-Warteschlangenprotokoll-DDIs

Die folgenden auf das Flip-Queue-Protokoll bezogenen Rückrufe und zugehörigen Strukturen wurden hinzugefügt:

• DXGKDDI_SETFLIPQUEUELOGBUFFER

• DXGKARG_SETFLIPQUEUELOGBUFFER

• DXGK_FLIPQUEUE_LOG_ENTRY

• DXGKDDI_UPDATEFLIPQUEUELOG

• DXGKARG_UPDATEFLIPQUEUELOG

KMD stellt einen Zeiger auf seine Funktionen in DRIVER_INITIALIZATION_DATA bereit.

Aktualisierungen der VSync-Unterbrechungsstruktur

Die folgenden Änderungen wurden an der DXGKARGCB_NOTIFY_INTERRUPT_DATA Struktur vorgenommen, um VSync-Interrupts für das Hardware Flip Queue-Modell zu implementieren:

• Der DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 Enumerationswert wurde als InterruptType hinzugefügt.
• Die CrtcVSyncWithMultiPlaneOverlay3-Struktur wurde der Union hinzugefügt. CrtcVSyncWithMultiPlaneOverlay3's semantics are similar to the existing CrtcVSyncWithMultiPlaneOverlay2 structure, except that instead of a single last completed PresentId for each plane, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo points to the range of previously unreported PresentIds from the flip queue log.
• Die Struktur DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 wurde für das Mitglied CrtcVSyncWithMultiPlaneOverlay3's pMultiPlaneOverlayVSyncInfo hinzugefügt.

Verwenden sie erneut das Beispieldiagramm für die Einfache Hardware-Flip-Warteschlange :

Angenommen FirstFreeFlipQueueLogEntryIndex war auf 40 gesetzt, als Flip N übermittelt wurde und dann N, N+1, N+2 Presents abgeschlossen wurden.

Nach Abschluss einer konfiguration mit einer einzelnen Ebene wurden drei PresentIds N, N+1 und N+2 zu den jeweiligen Zeiten v2, v3, v4, KMD drei neue Einträge im Puffer für Flip-Warteschlangenprotokoll mit den Indizes 40, 41 und 42 geschrieben. KMD meldet einen FirstFreeFlipQueueLogEntryIndex-Wert von 43 in der CrtcVSyncWithMultiPlaneOverlay3-Struktur . Das Betriebssystem stellt fest, dass FirstFreeFlipQueueLogEntryIndex von 40 auf 43 geändert wurde und aus Protokolleinträgen 40, 41 und 42 liest. KMD muss die folgenden Pufferwerte für Flip-Warteschlangenprotokoll wie folgt festlegen:

• VidPnTargetId: die gleiche Bedeutung wie in CrtcVSyncWithMultiPlaneOverlay2

• PhysicalAdapterMask: die gleiche Bedeutung wie in CrtcVSyncWithMultiPlaneOverlay2

• MultiPlaneOverlayVSyncInfoCount = 1

• pMultiPlaneOverlayVSyncInfo[0].LayerIndex = 0

• pMultiPlaneOverlayVSyncInfo[0].FirstFreeFlipQueueLogEntryIndex = 43

• LogBufferAddressForPlane0[40].PresentId = N

• LogBufferAddressForPlane0[40].PresentTimestamp = v2

• LogBufferAddressForPlane0[46].PresentId = N+1

• LogBufferAddressForPlane0[41].PresentTimestamp = v3

• LogBufferAddressForPlane0[42].PresentId = N+2

• LogBufferAddressForPlane0[42].PresentTimestamp = v4

Explizite Aktualisierungsanforderung für Flip-Warteschlangenprotokolle

Es gibt Fälle, in denen das Betriebssystem Informationen über den letzten abgeschlossenen Batch von Flips abrufen muss, ohne auf den VSync-Interrupt warten zu müssen. In solchen Fällen ruft das Betriebssystem DxgkDdiUpdateFlipQueueLog explizit auf, um KMD aufzufordern, aus seiner proprietären Anzeigehardware-Datenstruktur zu lesen und vergangene Flip-Informationen in das Flip-Warteschlangenprotokoll zu schreiben. Die Semantik des Protokolls ist identisch mit der zuvor beschriebenen; Die einzige Änderung besteht darin, dass FirstFreeFlipQueueLogEntryIndex außerhalb des VSync-Interrupts an das Betriebssystem zurückgegeben wird.

DxgkDdiUpdateFlipQueueLog wird auf Geräteunterbruchebene (DIRQL) aufgerufen und befindet sich in derselben Synchronisierungsklasse wie DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 DDI.

Anzeigemodusänderungen und Energieübergänge im Vorhandensein eines in die Warteschlange eingereihten Flips in der Hardware-Flip-Warteschlange

Dxgkrnl stellt sicher, dass bereits in die Warteschlange eingereihte Flips in der Hardware flip-Warteschlange abgeschlossen oder abgebrochen werden, bevor ein Moduswechsel oder Einschalten des Monitors initiiert wird.

Zuordnen vorhandener Anforderungen zu Hardware-Flip-Warteschlangen-Zeitstempeln

Wenn die Hardware-Flip-Warteschlange auf einem bestimmten Adapter aktiviert ist, begleitet ein Zeitstempel alle Flip-Anrufe. Mit anderen Worten: KMD muss keine Mischung aus alter und neuer DxgkDdiSetVidPnSourceAddress-Semantik verarbeiten.

Das Betriebssystem konvertiert automatisch vorhandene intervallbasierte Present-API-Anforderungen in zeitstempelbasierte Flip-Aufrufe in KMD. In den folgenden Abschnitten werden verschiedene Fälle und deren Zuordnung zu einer Kombination aus Flags, Dauer und Zeitstempeln erläutert, die von KMD empfangen werden.

Reißende und nicht verzehnte Flipsemantik

Die Semantik von reißenden Flips ist konzeptionell identisch, wenn die Hardware-Flip-Warteschlange aktiviert ist. Sobald die TargetFlipTime erreicht ist, sollte KMD das Flip übermitteln, um die Anzeige anzuzeigen, während weiterhin Flags wie FlipImmediate, FlipImmediateNoTearing und FlipOnNextVSync berücksichtigt werden. Mit anderen Worten, KMD sollte sich so verhalten, als ob das Betriebssystem den Flip an die ZielflipTime mit denselben Flip-Flags und -Parametern übermittelt hat.

Wenn FlipOnNextVSync beispielsweise auf "1" festgelegt ist und sich "TargetFlipTime" in der Mitte des Frames befindet, sollte der Flip nur auf dem nächsten VSync angezeigt werden.

FlipOverwrite-Unterstützung und Hardware-Flip-Warteschlange

Die Hardware-Flip-Warteschlange ist eine strikte Obermenge der Flip-Overwrite-Funktion, die durch den Wert MaxQueuedMultiPlaneOverlayFlipVSync in DXGK_DRIVERCAPS gesteuert wird.

Daher ignoriert das Betriebssystem den Wert "MaxQueuedMultiPlaneOverlayFlipVSync ", wenn sich der Treiber in der Hardware Flip-Warteschlange anmeldet, indem er MaxHwQueuedFlips auf einen Wert größer als 1 festlegt.

Mehrere Flips mit einem abgelaufenen TargetFlipTime

Wenn mehrere in die Warteschlange eingereihte Flips mit einem abgelaufenen TargetFlipTime-Element für eine bestimmte MPO-Ebene vorhanden sind, muss die Hardwareanzeigewarteschlange den zuletzt in die Warteschlange eingereihten abgelaufenen Flip auswählen und zur Anzeige übermitteln. Die restlichen abgelaufenen Flips sollten als abgebrochen behandelt werden, und die entsprechenden Einträge im Flip-Warteschlangenprotokoll sollten DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED als PresentTimestamp-Werte enthalten.

Interaktion zwischen Dauer und TargetFlipTime

Der Parameter Duration in der DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3-Struktur sollte wirksam werden, wenn der in dieser Struktur angegebene Flip auf dem Bildschirm angezeigt wird. Es gibt das neue gewünschte Aktualisierungsverhalten der Anzeige für die Ausgabe an, die von VidPnSourceId in allen Ebenen angegeben wird. In den Versionen WDDM 3.1 und Windows Server 2022, um die Treiberimplementierung für Hardware zu vereinfachen, die keine benutzerdefinierten Änderungen der Warteschlange unterstützt, sendet das Betriebssystem nur Flip-Anforderungen mit einem neuen Duration-Parameter , nachdem vorherige Flip-Anforderungen abgeschlossen wurden.

Zuordnen von Present-Intervallen zu TargetFlipTime

Zuordnungsintervalle, wenn die Aktualisierungsrate festgelegt ist

Um vorhandene vorhandene Intervallsemantik beizubehalten, muss das Betriebssystem die Ziel-Flip-Zeit mithilfe des aktuellen Intervalls und der Aktualisierungsrate berechnen. Das Festlegen der Ziel-Flip-Zeit genau auf die beabsichtigte VSync-Zeit, zu der die Flip-Taste auf den Bildschirm trifft, führt jedoch zu häufigen Störungen. Diese Störungen sind auf die verpasste VSync zurückzuführen, wenn die tatsächliche VSync-Anzeigedauer ein wenig abdrift. Um vor Störungen zu schützen, subtrahiert das Betriebssystem die Hälfte des VSync-Intervalls vom berechneten Ziel-Flip-Zeit.

Hier ist eine vereinfachte Formel zum Zuordnen des aktuellen Intervalls zur Ziel-Flip-Zeit:

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

Zuordnungsintervalle, wenn die virtuelle Aktualisierungsrate WDDM 2.9 vorhanden ist

Das Feature für die virtuelle Aktualisierungsrate kann die Aktualisierungsrate der Anzeige vorübergehend auf ein ganzzahliges Vielfaches der aktuellen Aktualisierungsrate erhöhen (d. h. 24 Hz können auf 144 Hz oder 192 Hz erhöht werden). Für Geräte, die diese Verstärkung unterstützen können, wird die Formel im vorherigen Abschnitt geändert, um das schnellste Vielfache der aktuellen Aktualisierungsrate zu verwenden:

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

Zuordnen von Intervallen, wenn die Aktualisierungsrate in ein Nichtmultiple geändert wird

Wenn die Aktualisierungsrate in ein Nichtmultiple einer aktuellen Aktualisierungsrate geändert wird (z. B. von 24 Hz bis 60 Hz), muss das Betriebssystem die Warteschlangendrehungen überprüfen, um festzustellen, ob die berechnete Zielzeit für die neue Aktualisierungsrate noch gültig ist. Wenn die Ziel-Flip-Zeit geändert werden muss, bricht das Betriebssystem in die Warteschlange eingereihte Flips ab und überschreibt sie erneut mit den neu berechneten Ziel-Flip-Zeiten.