Hardware-Flip-Warteschlange

In diesem Artikel wird das Feature "Hardware-Flip queue" beschrieben, das ab Windows 11 (WDDM 3.0) unterstützt wird. Mit der Funktion "Hardware-Flip-Warteschlangen" können mehrere zukünftige Frames an die Anzeigecontrollerwarteschlange übermittelt werden. Die CPU und Teile der GPU können zu niedrigeren Leistungszuständen übergehen, während der Anzeigecontroller mehrere Frames in der Warteschlange verarbeitet, was die Energieeffizienz von Videowiedergabeszenarien auf fähiger Hardware verbessert.

Warteschleifenmodell vor WDDM 3.0 flip

Viele moderne Anzeigecontroller unterstützen die Möglichkeit, mehrere Frames in eine Warteschlange zu stellen, die in einer Sequenz angezeigt werden sollen. Ab WDDM 2.1 unterstützt das Betriebssystem mehrere ausstehende Überschreibungsanforderungen, die auf der nächsten VSync angezeigt werden sollen. Der Display-Miniporttreiber (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 Framerate zu reduzieren, in denen mehrere Frames sequenziell mit Intervall 0 gerendert werden, wobei die Absicht ist, nur den neuesten Frame anzuzeigen.

In Videowiedergabeszenarien ist der Inhalt mehrerer zukünftiger Frames, die sequenziell angezeigt werden sollen, im Voraus bekannt und kann in die GPU eingereiht werden. Diese erweiterte Warteschlangenverwaltung ermöglicht es der CPU, während die in die Warteschlange gestellten Frames verarbeitet werden, in einen Zustand mit niedriger Leistung zu gelangen, 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 ohne weiteren CPU-Eingriff mindestens ein VSync-Intervall auf dem Bildschirm bleiben muss. Im Abschnitt Grundlegende Hardware-Flip-Warteschlange wird eine Lösung vorgestellt, die es der CPU ermöglicht, in einen Zustand mit geringer Leistung zu gelangen und die Frameverarbeitung in Warteschlange an die GPU zu entladen.

In Gamingszenarien vor WDDM 3.0 gibt es nach abschluss des Renderns der Szene in den Swap Chain Back-Puffer einen Roundtrip an die CPU, um die Anforderung zu übermitteln, den Frameinhalt auf dem Bildschirm anzuzeigen. Bei großen GPU-Workloads, die in der Nähe der VSync enden, kann dieser Roundtrip dazu führen, dass Frames verzögert werden und die vorgesehene Zielzeit verfehlen, was zu beobachtbaren Framestörungen führt. Im Abschnitt Erweiterte Hardware-Flip-Warteschlange wird ein Mechanismus eingeführt, um diesen CPU-Roundtrip zu vermeiden und dem Bildschirm abgeschlossene Frames mit sehr geringer Latenz anzuzeigen. Erweiterte Hardware-Flip-Warteschlange erfordert sowohl grundlegende Funktionen für die Hardware-Flip-Warteschlange als auch GPU-Hardwareplanungsstufe 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 bleiben.

Das Füllmuster im Diagramm zeigt die Zeiten, in denen die Dxgkrnl-Software die Warteschlangenverarbeitung und Anwendungsthreads aktivieren und CPU-Arbeit ausführen müssen. Auf jeder 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 auf jeder VSync-Instanz aufwachen und Statistiken abfragen, um schließlich zu erfahren, wann der letzte Frame im Batch von drei angezeigt wird.

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

Das folgende Diagramm veranschaulicht die vorgeschlagene Architektur.

Beim Ansatz der Hardware-Flip-Warteschlange befinden sich sowohl die Anwendungs- als auch dxgkrnl-CPU-Komponenten für zwei VSync-Intervalle zwischen v2 und v4 vollständig im Leerlauf, sodass die CPU in einen Zustand mit geringer Leistung gelangen kann. Die CPU wird nur benachrichtigt, wenn der Frame N+2 , für den die Anwendung eine Wartezeit angefordert hat, abgeschlossen ist.

Erweiterte Hardware-Flip-Warteschlange

In Gamingszenarien vor WDDM 3.0 gibt es nach Abschluss des Renderns der Szene in den Swap Chain Back-Puffer einen Roundtrip an die CPU, um die Anforderung zu übermitteln, den Frameinhalt auf dem Bildschirm zu präsentieren. Das folgende Diagramm zeigt dieses Szenario.

Die Kosten für diesen Roundtrip können dazu führen, dass Frames ihr Ziel verfehlen, wenn das Rendern zu nah an der VSync-Version abgeschlossen ist, wie im folgenden Diagramm dargestellt.

Einige Anzeigecontroller unterstützen nativ Wartebedingungen, die es der Anzeige ermöglichen, die Flip-Anforderung zu übermitteln, sobald die GPU den Frame ohne CPU-Roundtrip gerendert hat. Da die Hardware-Flip-Warteschlange den gerade abgeschlossenen Frame N ohne CPU-Roundtrip an die Anzeige übermitteln kann, kann sie verpasste Frames vermeiden, wie im folgenden Diagramm gezeigt.

Im weiteren Verlauf dieses Artikels wird das grundlegende Feature zum Umklappen der Hardwarewarteschlange erläutert.

DDI-Unterstützung

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

Überprüfen der Featureverfügbarkeit

Hardware-Flip-Warteschlange erfordert die Aktivierung/Deaktivierung der Aushandlung des Betriebssystems. Eine KMD, die Hardware-Flip-Warteschlange unterstützt, muss zuerst DXGKCB_QUERYFEATURESUPPORT während der Gerätestartzeit mit einer FeatureId von DXGK_FEATURE_HWFLIPQUEUE aufrufen, um zu bestimmen, ob das Betriebssystem die Aktivierung der Hardware-Flip-Warteschlange zulässt.

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

Eine KMD kann den folgenden Beispielcode während des Hardware-Flip-Queue-Vor- und Experimentiervorgangs 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 des Treiberups wird diese Kombination nicht offiziell unterstützt, obwohl es möglich ist, die Hardware-Flip-Warteschlange zu aktivieren, ohne die GPU-Hardwareplanung zu aktivieren. Windows erfordert derzeit die Aktivierung der GPU-Hardwareplanung, damit die grundlegende Hardware-Flip-Warteschlange für offiziell veröffentlichte Treiber aktiviert wird.

Angeben von Hardwarewarteschlangenfunktionen

MaxHwQueuedFlips wurde DXGK_DRIVERCAPS hinzugefügt, um die Unterstützung von Hardware-Flip-Warteschlangen anzugeben. Wenn das Betriebssystem die Unterstützung der Hardware-Flipwarteschlange wie zuvor beschrieben zulässt, sollte eine KMD, die 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 angezeigt werden können. Das Betriebssystem berücksichtigt die vom Treiber bereitgestellten Einschränkungen für die Art der Flips, die im Voraus in die Warteschlange gestellt werden können.

HwQueuedFlipCaps wurde auch DXGK_DRIVERCAPS hinzugefügt. Dieses Element ist derzeit für die Systemverwendung reserviert und sollte nicht von Treibern verwendet werden.

Zielzeit und Zielzeitstempelformat umkehren

Wenn das Betriebssystem eine Flip-Anforderung an die Hardware-Flip-Warteschlange sendet, sendet es auch die Ziel-Fliptime. Der Flip kann für den Benutzer sichtbar gemacht werden, nachdem die Zieldrehzeit 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 Warteschlange

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

• Die folgenden drei Member wurden der DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS Struktur von OutputFlags hinzugefügt. Ausführliche Informationen zu diesen Membern finden Sie unter DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 Wiederholungs- und Fehlerfälle .

  • HwFlipQueueDrainNeed
  • HwFlipQueueDrainAllPlanes
  • HwFlipQueueDrainAllSources

• Ein TargetFlipTime-Member wurde hinzugefügt. TargetFlipTime beschreibt die Zieldrehzeit in QPC-Einheiten. Wenn die Uhr diesen Wert erreicht, kann der Frame an die Anzeige gesendet werden, wobei VSync- und Tearing-Flags berücksichtigt werden. Bei bereits in der Warteschlange ausstehenden Flips garantiert das Betriebssystem, dass TargetFlipTime für jede MPO-Ebene, auf die von der Flip-Anforderung verwiesen wird, größer oder gleich einer der ausstehenden Flip-Zielzeiten für diese Ebene ist. Mit anderen Worten, es kann eine Sequenz von Flips mit den gleichen oder zunehmenden Zeitstempeln geben, aber es kann keine Sequenz geben, die in der Zeit zurückgeht.

DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 Wiederholungs- und Fehlerfälle

Fehler bei der Warteschlange der Anforderung an die Hardware aufgrund ausstehender Flips

Es gibt mehrere Sonderfälle, die möglicherweise verhindern, 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 gleich 1 festlegen. Das Betriebssystem versucht erneut, die Flip-Anforderung zu übermitteln, nachdem alle ausstehenden Flips auf Flugzeugen, die von diesem Flip betroffen sind, abgeschlossen sind und sobald die Zielzeit erreicht ist.

In einigen Fällen kann die Anzeigehardware das Abschließen ausstehender Flips auf allen Ebenen erfordern, nicht nur die, auf die die eingehende Flip-Anforderung verweist. In diesem Fall sollten sowohl die Flags HwFlipQueueDrainNeeded als auch HwFlipQueueDrainAllPlanes auf 1 festgelegt werden, und KMD sollte STATUS_RETRY zurückgeben.

Ebenso kann die Anzeigehardware den Abschluss ausstehender Flips für alle VidPn-Quellen erfordern, um interne Ressourcen neu zuzuweisen. 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 angeben, ob die erneute Übermittlung am IRQL des Geräts erfolgen soll (PrePresentNeeded auf 0) 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 weiteren ausstehenden Flips für diese VidPnSourceId vorhanden sind, wird diese Bedingung als ungültiger Parameterfehler behandelt.

Es ist wichtig, dass der Wert von MaxHwQueuedFlips weiterhin die maximale Anzahl von einfachen Änderungswechseln mit nur Adressen widerspiegelt, die in eine Warteschlange für eine MPO-Ebene eingereiht werden können. Der STATUS_RETRY-Mechanismus sollte für komplexere Flip Requests verwendet werden, die nicht tief in die Warteschlange eingereiht werden können, z. B. Änderungen an der Ebenenkonfiguration.

Ungültiger Parameterfehler

Im Hardware-Flip-Warteschlangenmodell wurde die Verarbeitung fehlerhafter Flip requests des Betriebssystems überarbeitet, um eine bessere Debugbarkeit zu ermöglichen. Wenn KMD keine Flip-Anforderung verarbeiten kann, sollte STATUS_INVALID_PARAMETER von DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 zurückgegeben werden. Abhängig von den Betriebssystemeinstellungen führt das Betriebssystem eine der folgenden Aktionen aus:

• Kerneldebuggerunterbrechung und Fehlerüberprüfung: Dieses Verhalten wird häufig bei Entwicklungs-/Vorabversionsbuilds aktiviert, um die Debugbarkeit direkt bei der Fehlerbedingung zu verbessern.
• Live-Kernelabbild gefolgt von einem TDR: Das Einzelhandelsendbenutzerverhalten.

Angeben des VSync-Interruptverhaltens

Um Energieeinsparungen in Flip-Szenarios in der Warteschlange zu erzielen, setzt das Betriebssystem häufig reguläre VSync-Unterbrechungen an, um die CPU in einem niedrigen Leistungszustand zu halten. Einige Flips werden jedoch so gekennzeichnet, dass ein Interrupt ausgelöst werden muss, damit die Anwendung den Batch der abgeschlossenen Geschenke beobachten und weitere Arbeiten in die Warteschlange stellen kann. Es gibt auch Fälle, in denen Anwendungen das Aufwachen für jeden VSync-Interrupt anfordern, unabhängig davon, ob ausstehende Flip requests vorhanden sind. Umgekehrt werden VSync-Interrupts in einem vollständig im Leerlauf befindlichen System angehalten, bis neue Präsentationsaktivität oder VSync-Listener angezeigt werden.

Um alle diese Fälle zu behandeln, wurde die folgende 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. Es wird auf Geräteunterbrechungsebene (Device Interrupt Level, DIRQL) aufgerufen, um mit DxgkDdiSetVidPnSourceAddress und dem VSync-Interrupt zu synchronisieren.

Interaktion mit DxgkDdiControlInterrupt

Wenn VSync-Interrupts vollständig über DxgkDdiControlInterruptDxgkDdiControlInterrupt2//DxgkDdiControlInterrupt3 deaktiviert werden, bleiben sie unabhängig vom Wert des Interruptziels PresentId deaktiviert. KMD ist erforderlich, um die aktuelle ID des Interruptziels zu speichern, damit sie berücksichtigt werden kann, sobald VSync wieder aktiviert ist.

Wenn VSync-Interrupts über DxgkDdiControlInterruptXxx aktiviert werden, bietet die vorhandene Interruptziel-ID (pSetInterruptTargetPresentId) eine feiner abgestufte Steuerung wie folgt:

• Wenn die vorhandene Ziel-ID auf UINT64_MAX festgelegt ist, ist für die Zukunft kein VSync-Interrupt erforderlich, bis die vorhandene Ziel-ID erneut geändert wird. VSync-Interrupts sind deaktiviert, aber KMD ist erforderlich, um DXGK_VSYNC_DISABLE_KEEP_PHASE Verhalten zum erneuten Aktivieren von Interrupts zu implementieren.

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

• Für jeden anderen aktuellen ID-Wert werden Interrupts ausgelöst, wenn die aktuell gescannte PresentId >= InterruptTargetPresentId.

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

2-Stufen-VSync-Deaktivierung mit DxgkDdiSetInterruptTargetPresentId

Wenn der Betriebssystemaufruf von DxgkDdiSetInterruptTargetPresentId eine InterruptTargetPresentId auf einer Ebene festlegt, die zur vollständigen Deaktivierung von VSync auf dieser VidPnSource führen würde (d. h. diese Ebene war die letzte Ebene, auf der VSync aktiviert war und jetzt auch VSync deaktiviert wurde), sollte KMD VSync-Interrupts deaktivieren, aber die VSync-Phase in hardwareaktivieren (DXGK_VSYNC_DISABLE_KEEP_PHASE). Nach einem bestimmten Zeitraum (in der Regel entspricht zwei VSync-Zeiträumen) führt das Betriebssystem einen Aufruf von DxgkDdiControlInterruptXxx mit DXGK_VSYNC_DISABLE_NO_PHASE nach. Dieser Aufruf stellt sicher, dass KMD die Möglichkeit erhält, die VSync-Phase und die VSync-Uhren zu deaktivieren, um maximale Energie zu sparen und die Leistungsparität mit Nicht-Hardware-Flip-Warteschlangensystemen zu gewährleisten.

Flip-Abbruch in Warteschlange

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 Flips in der Warteschlange an, die abgebrochen werden sollen, wenn dxgkDdiCancelFlips aufgerufen wird, und KMD meldet dem Betriebssystem den Bereich der Flips, den es synchron abbrechen konnte.

Das folgende Beispiel veranschaulicht die Mechanik und den synchronen Fall der Umkehrunterdrückung auf einer einzelnen Ebene. (Das Betriebssystem unterstützt den asynchronen Abbruch in Windows 11 Version 22H2 nicht.) Stellen Sie sich vor, die folgenden Flips werden in der Hardware-Flip-Warteschlange in die Warteschlange eingereiht:

• 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 ruft es DxgkDdiCancelFlips auf, wobei PresentIdCancelRequested auf N+2 festgelegt ist.

Wenn KMD den Zustand der Hardware-Flip-Warteschlange überprüft, wurde festgestellt, dass flip N+2 bereits an die Anzeigehardware gesendet wurde und zum Zeitpunkt des Anrufs nicht abgebrochen werden kann, aber N+3 und N+4 können synchron ohne Nebenwirkungen aus der Hardware-Flip-Warteschlange entfernt werden. KMD legt PresentIdCancelled auf N+3 fest und schließt N+2 wie gewohnt ab.

Das Betriebssystem markiert N+3 und N+4 als abgebrochen, und es behandelt N, N+1, N+2 als im Flug. Wenn die nächsten VSync-Unterbrechungen ausgelöst werden, zeigt das Flip-Warteschlangenprotokoll wie gewohnt die Zeitstempel für N, N+1, N+2 an.

Der Bereich synchron abgebrochener Flips muss kontinuierlich sein und, wenn nicht 0, die letzte an KMD übermittelte ID enthalten. Mit anderen Worten: Innerhalb beider synchron abgebrochenen Flipbereiche können keine Lücken vorhanden sein.

Abbrechen von verriegelten Flips auf mehreren Ebenen

Ein ineinander greifende Flip wird übermittelt, indem DxgkDdiSetVidPnSourceAddress mit mehreren Ebenen und PresentIds aufgerufen wird. Der Vertrag zwischen dem Betriebssystem und KMD folgt:

• Der Satz von Ebenen muss auf derselben VSync sichtbar gemacht werden.
• Die Anzeigehardware darf nicht nur eine Teilmenge dieser Ebenen auf einer VSync anzeigen, der Rest auf der nächsten VSync.

Im Hardware-Flip-Warteschlangenmodell werden solche verriegelten Flips abgebrochen, indem mehrere Ebenen und PresentIds im Aufruf von DxgkDdiCancelFlips übergeben werden. Der Satz von Ebenen, die in solchen Fällen übergeben werden, muss einer ausstehenden ineinandergreifenden Flip-Anforderung entsprechen, und die Entscheidung von KMD in Bezug auf alle ineinandergreifenden PresentIds muss identisch sein:

• Nicht abbrechen oder
• Synchron abbrechen

DxgkDdiCancelFlips wird auf der Device Interrupt-Ebene (DIRQL) aufgerufen, um mit DxgkDdiSetVidPnSourceAddress und VSync-Interrupt zu synchronisieren.

Abrufen der aktuellen Statistiken für Flips in Warteschlange

Da der Ansatz der Hardware-Flip-Warteschlange darin besteht, zu vermeiden, dass die CPU auf jeder VSync aktiviert wird, muss es einen Mechanismus geben, um die Frameanzeigezeiten für die letzten mehrere Flips in der Warteschlange beizubehalten.

Grafiktreiber, die Hardware-Flip-Warteschlange unterstützen, sind erforderlich, um Informationen für jeden abgeschlossenen oder abgebrochenen Flip pro einer bestimmten MPO-Ebene für jede aktive VidPnSource in den vom Betriebssystem bereitgestellten Puffer für das Flip Queue-Protokoll zu schreiben.

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

Nachdem ein Batch mit Flips in der Warteschlange abgeschlossen wurde, muss KMD sicherstellen, dass das Flip-Warteschlangenprotokoll für die abgeschlossenen Flips frühestens dieser beiden Zeitpunkte aktualisiert wird:

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

Warteschlangenprotokoll-DDIs umdrehen

Der folgende Rückruf im Zusammenhang mit dem Flip-Queue-Protokoll 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.

VSync-Interruptstrukturupdates

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

• Der DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 Enumerationswert wurde als InterruptType hinzugefügt.
• Die CrtcVSyncWithMultiPlaneOverlay3-Struktur wurde der Union hinzugefügt. Die Semantik von CrtcVSyncWithMultiPlaneOverlay3 ähnelt der vorhandenen CrtcVSyncWithMultiPlaneOverlay2-Struktur, mit dem Unterschied, dass crtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayInfo auf den Bereich der zuvor nicht gemeldeten PresentIds aus dem Flip-Warteschlangenprotokoll verweist.
• Die DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3-Struktur wurde für das pMultiPlaneOverlay3-Element von CrtcVSyncWithMultiPlaneOverlay3 hinzugefügt.

Verwenden des Beispieldiagramms "Basic hardware flip queue" erneut:

Angenommen , FirstFreeFlipQueueLogEntryIndex wurde zum Zeitpunkt der Übermittlung von Flip N auf 40 festgelegt, und dann wurden N, N+1, N+2-Geschenke abgeschlossen.

Nachdem eine Konfiguration mit einer einzelnen Ebene drei PresentIds N, N+1 und N+2 zu den jeweiligen Zeitpunkten v2, v3, v4 abgeschlossen hat, hat KMD drei neue Einträge in den Puffer des Flip-Warteschlangenprotokolls mit den Indizes 40, 41 und 42 geschrieben. KMD meldet den FirstFreeFlipQueueLogEntryIndex-Wert 43 in der CrtcVSyncWithMultiPlaneOverlay3-Struktur . Das Betriebssystem beobachtet, dass FirstFreeFlipQueueLogEntryIndex von 40 auf 43 geändert wurde, und liest aus den Protokolleinträgen 40, 41 und 42. KMD muss die folgenden Werte für den Puffer für das Flip-Warteschlangenprotokoll wie folgt festlegen:

• VidPnTargetId: Gleiche Bedeutung wie in CrtcVSyncWithMultiPlaneOverlay2

• PhysicalAdapterMask: 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 das Flip-Queue-Protokoll

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 sendet das Betriebssystem einen expliziten Aufruf an DxgkDdiUpdateFlipQueueLog , um kmD von seiner proprietären Hardwaredatenstruktur zu lesen und vergangene Flipinformationen 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 der DirQL-Ebene (Device Interrupt Level) aufgerufen und befindet sich in derselben Synchronisierungsklasse wie DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 DDI.

Änderungen im Anzeigemodus und Energieübergänge in Anwesenheit einer Warteschlange in der Hardware-Flip-Warteschlange

Dxgkrnl stellt sicher, dass bereits in der Warteschlange befindliche Flips in der Hardware-Flip-Warteschlange abgeschlossen oder abgebrochen werden, bevor eine Modusänderung initiiert oder der Monitor heruntergefahren wird.

Zuordnung Von Aktuellen Anforderungen zu Zeitstempeln der Hardware für das Umdrehen der Warteschlange

Wenn die Hardware-Flip-Warteschlange für einen bestimmten Adapter aktiviert ist, werden alle Flip-Aufrufe von einem Zeitstempel begleitet. Mit anderen Worten, KMD muss keine Mischung aus alter und neuer DxgkDdiSetVidPnSourceAddress-Semantik verarbeiten.

Das Betriebssystem konvertiert vorhandene intervallbasierte Present-API-Anforderungen automatisch in zeitstempelbasierte Flipaufrufe an 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.

Tearing and Non-Tearing Flips Semantik

Die Semantik von Tearing-Flips ist konzeptionell identisch, wenn die Hardware-Flip-Warteschlange aktiviert ist. Sobald TargetFlipTime erreicht ist, sollte KMD den Flip zur Anzeige übermitteln und gleichzeitig Flags wie FlipImmediate, FlipImmediateNoTearing und FlipOnNextVSync ehrt. Mit anderen Worten, KMD sollte sich so verhalten, als ob das Betriebssystem den Flip genau bei TargetFlipTime mit den gleichen Flip flags und Parametern übermittelt hätte.

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

FlipOverwrite-Unterstützung und Hardware-Flip-Warteschlange

Hardware-Flip-Warteschlange ist eine strikte Übermenge des Überschreibungsfeatures, das vom MaxQueuedMultiPlaneOverlayFlipVSync-Wert in DXGK_DRIVERCAPS gesteuert wird.

Daher ignoriert das Betriebssystem den MaxQueuedMultiPlaneOverlayFlipVSync-Wert , wenn der Treiber die Hardware-Flip-Warteschlange aktiviert, indem MaxHwQueuedFlips auf einen Wert größer als 1 festgelegt wird.

Mehrere Flips mit einem abgelaufenen TargetFlipTime

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

Interaktion zwischen Duration und TargetFlipTime

Der Duration-Parameter 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 von VidPnSourceId angegebene Ausgabe auf allen Ebenen an. In den Versionen WDDM 3.1 und Windows 2022 sendet das Betriebssystem nach Abschluss vorheriger Flip Requests nur Flip Requests mit einem neuen Duration-Parameter, um die Treiberimplementierung für Hardware zu vereinfachen, die keine benutzerdefinierten Daueränderungen in der Warteschlange unterstützt.

Zuordnung von Gegenwartsintervallen zu TargetFlipTime

Zuordnungsintervalle, wenn die Aktualisierungsrate festgelegt ist

Um vorhandene semantische Intervalle beizubehalten, muss das Betriebssystem die Zieldrehzeit unter Verwendung des aktuellen Intervalls und der Aktualisierungsrate berechnen. Wenn Sie die Zieldrehzeit jedoch genau auf die vorgesehene VSync-Zeit festlegen, zu der der Flip auf den Bildschirm gelangen soll, führt dies zu häufigen Störungen aufgrund der verpassten VSync-Zeit, falls das tatsächliche VSync-Timing etwas abdrift. Zum Schutz vor Störungen subtrahiert das Betriebssystem die Hälfte des VSync-Intervalls von der berechneten Ziel-Fliptime.

Hier sehen Sie eine vereinfachte Formel zum Zuordnen des aktuellen Intervalls zur Zieldrehzeit:

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

Zuordnungsintervalle, wenn das Feature für die virtuelle Aktualisierungsrate WDDM 2.9 vorhanden ist

Das Feature für die virtuelle Aktualisierungsrate kann die Anzeigewiederholrate 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 diesen Boost unterstützen können, wird die Formel im vorherigen Abschnitt so geändert, dass das schnellste Vielfache der aktuellen Aktualisierungsrate verwendet wird:

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

Zuordnungsintervalle, wenn die Aktualisierungsrate in ein Nicht-Vielfaches geändert wird

Wenn die Aktualisierungsrate in ein Nicht-Vielfaches einer aktuellen Aktualisierungsrate geändert wird (z. B. von 24 Hz auf 60 Hz), muss das Betriebssystem die Warteschlangen-Flips überprüfen, um festzustellen, ob ihre berechnete Zielzeit angesichts der neuen Aktualisierungsrate weiterhin gültig ist. Wenn die Zielwendezeit geändert werden muss, bricht das Betriebssystem die Flips in der Warteschlange ab und stellt sie mit den neu berechneten Zielwendezeiten erneut zurück.