Hardware-Flip-Warteschlange

In diesem Artikel wird die Hardware-Flip-Warteschlange beschrieben, die 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 zu niedrigeren Leistungszuständen wechseln, während der Displaycontroller mehrere in die Warteschlange eingereihte Frames verarbeitet, um die Energieeffizienz von Videowiedergabeszenarien auf fähiger Hardware zu verbessern.

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-Anforderungen, die auf dem 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 Spielszenarien mit hoher Framerate zu verringern, in denen mehrere Frames sequenziell mit Intervall 0 gerendert werden, wobei nur der letzte Frame angezeigt werden soll.

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. Die Voraus-Warteschlange ermöglicht es der CPU, in einen niedrigen Energiemodus zu wechseln, während die eingereihten Frames verarbeitet werden, was zu erheblichen Stromeinsparungen 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 "Basic Hardware Flip Queue" wird eine Lösung vorgestellt, die es der CPU ermöglicht, in einen Energiesparmodus zu wechseln und die Warteschlangenverarbeitung der Frames an die GPU zu übertragen.

In Spielszenarien vor WDDM 3.0, nachdem die GPU das Rendern der Szene in den Hintergrundpuffer der Swapchain abgeschlossen hat, gibt es einen Umweg zur CPU, um die Anforderung zum Anzeigen der Frame-Inhalte 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 Advanced Hardware-Flip-Queue führt einen Mechanismus ein, um diesen CPU-Roundtrip zu vermeiden und abgeschlossene Frames mit geringer Latenz auf dem Bildschirm anzuzeigen. Die erweiterte Hardware-Flip-Warteschlange erfordert sowohl die grundlegende Hardware-Flip-Warteschlange als auch die GPU-Hardwareplanungsphase 2, um vorhanden zu sein.

Einfache 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, in denen die Dxgkrnl-Software-Flip-Queue-Verarbeitung und Anwendungs-Threads aufwachen und CPU-Arbeit leisten 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 auch bei jedem VSync aufwachen und präsentierte Statistiken abfragen, um herauszufinden, wann der letzte Frame im Dreier-Block angezeigt wird.

Hardware-Flip-Queue-DDIs, die mehrere zukünftige Frames in die Warteschlange des Display-Controllers einspeisen 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.

Mit dem Hardware-Flip-Queue-Ansatz sind sowohl die Anwendungs- als auch die Dxgkrnl-CPU-Komponenten für zwei VSync-Intervalle zwischen v2 und v4 im Leerlauf, sodass die CPU in einen niedrigen Leistungsmodus wechselt. Die CPU wird erst benachrichtigt, wenn der Frame N+2, welcher von der Anwendung zum Warten angefordert wurde, abgeschlossen ist.

Erweiterte Hardware-Flip-Warteschlange

In Spielszenarien vor WDDM 3.0, nachdem die GPU das Rendern der Szene in den Hintergrundpuffer der Swapchain abgeschlossen hat, gibt es einen Umweg zur CPU, um die Anforderung zum Anzeigen der Frame-Inhalte auf dem Bildschirm zu übermitteln. Das folgende Diagramm zeigt dieses Szenario.

Die Kosten dieses Rundlaufs können dazu führen, dass Frames ihr Ziel verpassen, wenn das Rendern zu nah am VSync abgeschlossen wird, 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, werden möglicherweise verpasste Frames vermieden, wie im folgenden Diagramm dargestellt.

Im restlichen Teil dieses Artikels wird die grundlegende Hardware-Flip-Warteschlangenfunktion erläutert.

DDI-Unterstützung

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

Überprüfen der Verfügbarkeit von Features

Für die Hardware-Flip-Warteschlange ist eine Aushandlung zur Aktivierung/Deaktivierung des Betriebssystems erforderlich. Eine KMD, die die Hardware-Flip-Warteschlange unterstützt, muss zuerst während der Gerätestartzeit DXGKCB_QUERYFEATURESUPPORT mit einer Feature-ID von DXGK_FEATURE_HWFLIPQUEUE aufrufen, um festzustellen, ob das Betriebssystem das Aktivieren der Hardware-Flip-Warteschlange zulässt.

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

Ein KMD kann den folgenden Beispielcode während der Inbetriebnahme von Hardware-Flip-Warteschlangen und experimentellen Phasen 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.
}

Während der Treiber-Inbetriebnahme ist es zwar möglich, die Hardware-Flip-Queue zu aktivieren, ohne die GPU-Hardwareplanung zu verwenden, jedoch wird diese Kombination nicht offiziell unterstützt. Windows erfordert derzeit, dass die GPU-Hardwareplanung aktiviert ist, damit bei offiziell veröffentlichten Treibern die einfache Hardware-Flip-Warteschlange aktiviert werden kann.

Angabe von Hardware-Warteschlangenfä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 es nicht verwenden.

Zielzeit und Zielzeitstempelformat umdrehen

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 Flips in die Warteschlange

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

• Die folgenden drei Elemente wurden der DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS-Struktur von OutputFlags 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 unter Berücksichtigung von VSync und Tearing-Flags an die Anzeige gesendet werden. In Anwesenheit von zuvor in die Warteschlange gestellten Flips garantiert das Betriebssystem, dass für jede MPO-Ebene, auf die durch die Flip-Anforderung verwiesen wird, TargetFlipTime größer oder gleich einer der ausstehenden Flip-Zielzeiten 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 Wiederholungsversuche und Fehlerfälle

Fehler beim Einreihen der Anforderung an die Hardware aufgrund von ausstehenden Flips

Es gibt mehrere spezielle Fälle, die möglicherweise verhindern, dass KMD eine Flip-Anforderung in die Warteschlange einreiht, 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 es die Anzeigehardware möglicherweise, dass ausstehende Flips auf allen Ebenen abgeschlossen werden und nicht nur auf denjenigen, auf die sich die eingehende Flip-Anforderung bezieht. In diesem Fall sollten sowohl die HwFlipQueueDrainNeeded- als auch die HwFlipQueueDrainAllPlanes-Flags auf 1 festgelegt werden, und KMD sollte STATUS_RETRY zurückgeben.

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

Darüber hinaus kann KMD dem Betriebssystem mitteilen, ob die Wiedervorlage auf dem IRQL des Geräts (PrePresentNeeded auf 0 festgelegt) erfolgen soll, oder ob das Betriebssystem diesen Aufruf auf PASSIVE_LEVEL ausführen soll (PrePresentNeeded auf 1 festgelegt). Wenn KMD weiterhin STATUS_RETRY zurückgibt, obwohl es keine ausstehenden Flips für diese VidPnSourceId gibt, wird diese Bedingung als ungültiger Parameterfehler behandelt.

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

Ungültiger Parameterfehler

Im Hardware-Flip-Warteschlangenmodell wurde die Behandlung fehlgeschlagener Flip-Anforderungen des Betriebssystems überarbeitet, um eine bessere Fehlerbehebung 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:

• Kernel-Debugger-Unterbrechung und Fehlerüberprüfung: Dieses Verhalten wird häufig für den Einsatz bei Entwicklungs- oder Vorabversionen von Builds aktiviert, um die Fehlersuche zu verbessern, sobald die Fehlerbedingung eintritt.
• Live Kernel Dump gefolgt von einem TDR: Das Verhalten des Endbenutzers für den Einzelhandel.

Angeben des VSync-Unterbrechungsverhaltens

Um Energieeinsparungen in Szenarien mit in der Warteschlange ausgeführten Flips zu erzielen, hält das Betriebssystem häufig normale VSync-Unterbrechungen an, um die CPU in einem Energiesparmodus zu halten. Einige Flips sind jedoch so gekennzeichnet, dass eine Unterbrechung ausgelöst werden muss, damit die Anwendung die Menge der abgeschlossenen Grafikbereitstellungen beobachten und weitere Aufgaben in die Warteschlange einreihen kann. Es gibt auch Fälle, in denen Anwendungen aufgefordert werden, bei jeder VSync-Unterbrechung aufzuwachen, unabhängig davon, ob noch Flip-Anfragen offen 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, wurde der folgende Treiberrückruf und die Rückrufstruktur eingeführt:

• DXGKDDI_SETINTERRUPTTARGETPRESENTID
• DXGKARG_SETINTERRUPTTARGETPRESENTID

KMD liefert einen Zeiger auf seine 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-Unterbrechungen vollständig über DxgkDdiControlInterrupt/DxgkDdiControlInterrupt2/DxgkDdiControlInterrupt3 deaktiviert werden, bleiben sie unabhängig vom Interruptziel PresentId-Wert deaktiviert. KMD muss die neueste Interruptziel-Present-ID speichern, damit sie berücksichtigt wird, sobald VSync erneut aktiviert wird.

Wenn VSync-Interrupts über DxgkDdiControlInterruptXxx aktiviert werden, bietet die Interruptziel-Present-ID (pSetInterruptTargetPresentId) eine genauere 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-Unterbrechungen sind deaktiviert, aber für die erneute Aktivierung von Unterbrechungen ist KMD erforderlich, um das Verhalten DXGK_VSYNC_DISABLE_KEEP_PHASE zu implementieren.

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

• Für jeden anderen vorhandenen ID-Wert werden Unterbrechungen ausgelöst, wenn die derzeit 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 Fläche festlegt, die dazu führen würde, VSync für diese VidPnSource vollständig zu deaktivieren (d. h. diese Fläche war die letzte, die VSync aktiviert hielt, und jetzt deaktiviert sie ebenfalls VSync), 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 Energie zu sparen und die Leistungsparität mit softwarebasierten Flip-Queue-Systemen aufrechtzuerhalten.

Abbruch eines eingereihten Flips

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

Das Betriebssystem gibt den Bereich der in die Warteschlange gestellten Flips an, die abgebrochen werden sollen, wenn DxgkDdiCancelFlips aufgerufen wird, und KMD berichtet an das Betriebssystem zurück, welcher Bereich der Flips synchron abgebrochen werden konnte.

Das folgende Beispiel veranschaulicht die Mechanik und den synchronen Fall der Drehstornierung 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
• Zeit t4

Das Betriebssystem beschließt dann, die Flips N+2, N+3 und N+4 abzubrechen. Daher wird DxgkDdiCancelFlips mit PresentIdCancelRequested auf N+2 festgelegt.

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 und ohne Nebenwirkungen aus der Hardware-Flip-Warteschlange 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 behandelt N, N+1, N+2 als im Flug. 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 fortlaufend sein und, wenn er nicht null ist, wird davon ausgegangen, dass er die letzte an KMD übermittelte ID enthält. 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 verketteter Flip wird durch Aufrufen von DxgkDdiSetVidPnSourceAddress mit mehreren Ebenen (Planes) 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 bei einem VSync anzeigen und den Rest bei dem nächsten VSync.

Im Hardware-Flip-Warteschlangenmodell werden solche verketteten Flips abgebrochen, indem mehrere Ebenen und PresentIds im Aufruf an DxgkDdiCancelFlips übergeben werden. Die Gruppe der in solchen Fällen übergebenen Ebenen muss einer ausstehenden verriegelten Flip-Anforderung entsprechen, und die Entscheidung der KMD bezüglich aller verriegelten PresentIds muss dieselbe sein.

• Nicht abbrechen, oder
• Gleichzeitiges Abbrechen

DxgkDdiCancelFlips wird auf Geräteunterbrechungsebene (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) bereitgestellt wird, bevor der erste DxgkDdiSetVidPnSourceAddress-Aufruf für eine bestimmte MPO-Ebene bei jeder aktiven VidPnSource erfolgt. Das Betriebssystem darf den Protokollpuffer der Flip-Queue löschen, wenn die Flip-Queue keine ausstehenden Anforderungen enthält. In diesem Fall wird ein neuer Protokollzeiger vor dem nächsten DxgkDdiSetVidPnSourceAddress-Aufruf bereitgestellt. Das Flip-Warteschlangenprotokoll ist zyklisch. 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 Log der Flip-Warteschlange für die abgeschlossenen Flips spätestens zu einem dieser beiden Zeitpunkte 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

Der folgende rückrufbezogene Callback in der Flip-Warteschlange und die 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 Enumerationswert DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 wurde als InterruptType hinzugefügt.
• Die CrtcVSyncWithMultiPlaneOverlay3-Struktur wurde zur Union hinzugefügt. Die Semantik von CrtcVSyncWithMultiPlaneOverlay3 ist der bestehenden CrtcVSyncWithMultiPlaneOverlay2 Struktur ähnlich, mit der Ausnahme, dass CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo anstelle einer einzigen zuletzt abgeschlossenen PresentId für jede Ebene auf den Bereich der zuvor nicht gemeldeten PresentIds aus dem Flip-Queue-Log verweist.
• Die DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3-Struktur wurde für das Mitglied pMultiPlaneOverlayVSyncInfo von CrtcVSyncWithMultiPlaneOverlay3 hinzugefügt.

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

Angenommen, FirstFreeFlipQueueLogEntryIndex wurde zum Zeitpunkt der Übermittlung von Flip N auf 40 festgelegt und dann wurden die Präsentationen N, N+1, N+2 abgeschlossen.

Nach Abschluss einer einzelnen Konfiguration einer Ebene von drei PresentIds N, N+1 und N+2 zu den jeweiligen Zeiten v2, v3, v4, hat KMD drei neue Einträge im Flip-Queue-Logpuffer 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 Pufferwerte für das 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[41]. PresentId = N+1

• LogBufferAddressForPlane0[41]. PresentTimestamp = v3

• LogBufferAddressForPlane0[42]. PresentId = N+2

• LogBufferAddressForPlane0[42]. PresentTimestamp = v4

Explizite Aktualisierungsanforderung für Flip-Warteschlangenprotokoll

Es gibt Fälle, in denen das Betriebssystem Informationen über den letzten abgeschlossenen Stapel von Flips abrufen muss, ohne auf den VSync-Interrupt warten zu müssen. In solchen Fällen ruft das Betriebssystem explizit dxgkDdiUpdateFlipQueueLog auf, um KMD aufzufordern, aus seiner proprietären Datenstruktur der Anzeigehardware zu lesen und vergangene Flip-Informationen in die Flip-Warteschlangen-Log-Datei 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.

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

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

Zuordnen von Present-Anforderungen zu Hardware-Flip-Queue-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. Die folgenden Abschnitte erörtern verschiedene Fälle und wie sie einer Kombination aus Flags, Dauer und von KMD empfangenen Zeitstempeln zugeordnet werden.

Zerreißende und nicht-zerreißende Flip-Semantik

Die Semantik von Tearing-Flips ist konzeptionell identisch, wenn die Hardware-Flip-Warteschlange aktiviert ist. Sobald die TargetFlipTime erreicht ist, sollte KMD das Flip übermitteln, um 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 genau zu TargetFlipTime 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 strenge Obermenge des Flip overwrite-Features, die von MaxQueuedMultiPlaneOverlayFlipVSync-Wert in DXGK_DRIVERCAPS gesteuert wird.

Daher ignoriert das Betriebssystem den Wert "MaxQueuedMultiPlaneOverlayFlipVSync", wenn der Treiber sich 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, sobald der in dieser Struktur angegebene Flip auf dem Bildschirm erscheint. 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 Daueränderungen unterstützt, die in Warteschlangen gestellt werden, sendet das Betriebssystem Flip-Anforderungen mit einem neuen Duration-Parameter, erst nachdem frühere Flip-Anforderungen abgeschlossen sind.

Zuordnen von Present-Intervallen zu TargetFlipTime

Intervallzuordnung, wenn die Bildwiederholrate 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 verpasstes VSync zurückzuführen, wenn das tatsächliche VSync-Timing etwas abweicht. Um gegen Störungen zu schützen, subtrahiert das Betriebssystem die Hälfte des VSync-Intervalls von der berechneten Zielumschaltzeit.

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

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

Zuordnungsintervalle bei Vorhandensein der Funktion der virtuellen Aktualisierungsrate WDDM 2.9

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.