Nachverfolgung der Zuordnungsnutzung

Wenn die Zuordnungsliste wegfällt, hat der Videospeicher-Manager (VidMm) keinen Einblick mehr in die Zuordnungen, auf die in einem bestimmten Befehlspuffer verwiesen wird. Daher ist das VidMm nicht mehr in der Lage, die Zuordnungsnutzung nachzuverfolgen und die zugehörige Synchronisierung zu verarbeiten. Diese Verantwortung liegt nun beim Benutzermodustreiber (UMD). Insbesondere muss die UMD die Synchronisierung im Hinblick auf den direkten CPU-Zugriff auf die Zuordnung und Umbenennung verarbeiten.

Das VidMm verschiebt die Zuordnungsvernichtung asynchron auf sichere Weise, die sowohl für den aufrufenden Thread nicht blockiert als auch leistungsfähig ist. Daher muss sich eine UMD keine Gedanken darüber machen, die Zuordnungsvernichtung zurückstellen zu müssen. Wenn VidMm eine Anforderung zur Zuweisungsvernichtung empfängt, wird standardmäßig davon ausgegangen, dass Befehle, die vor der Vernichtungsanforderung in die Warteschlange gestellt werden, möglicherweise auf die zerstörte Zuordnung zugreifen können. VidMm verschiebt daher den Zerstörungsvorgang, bis die Befehle in der Warteschlange abgeschlossen sind. Wenn die UMD weiß, dass ausstehende Befehle nicht auf die zu zerstörende Zuordnung zugreifen, kann VidMm angewiesen werden, die Anforderung zu verarbeiten, ohne zu warten, indem das Flag AssumeNotInUse festgelegt wird, wenn Deallocate2 oder DestroyAllocation2 aufgerufen wird.

Lock2

Die UMD ist für die ordnungsgemäße Synchronisierung in Bezug auf den direkten CPU-Zugriff verantwortlich. Insbesondere ist eine UMD erforderlich, um:

1. Unterstützung der Sperrsemantik ohne Überschreiben und Verwerfen, was bedeutet, dass die UMD ein eigenes Umbenennungsschema implementieren muss.

2. Für Zuordnungsvorgänge, die eine Synchronisierung erfordern (d. a. nicht die oben genannten no-overwrite oder discard):

   • Gibt WasStillDrawing zurück, wenn versucht wird, auf eine derzeit ausgelastete Zuordnung zuzugreifen und der Aufrufer angefordert hat, dass der Lock-Vorgang den aufrufenden Thread (D3D11_MAP_FLAG_DO_NOT_WAIT) nicht blockiert.
   • Oder warten Sie, wenn das flag D3D11_MAP_FLAG_DO_NOT_WAIT nicht festgelegt ist, bis eine Zuordnung für den CPU-Zugriff verfügbar ist. Die UMD muss eine Nichtpolwartevorgang implementieren. Die UMD nutzt den neuen Kontextüberwachungsmechanismus.

Vorerst muss die UMD weiterhin LockCb/UnlockCb aufrufen, um VidMm aufzufordern, eine Zuordnung für den CPU-Zugriff einzurichten. In den meisten Fällen ist die UMD in der Lage, die Zuordnung für die gesamte Lebensdauer zugeordnet zu halten. In Zukunft werden LockCb und UnlockCb jedoch zugunsten neuer Lock2Cb - und Unlock2Cb-Aufrufe veraltet sein. Das Ziel dieser neueren Rückrufe besteht darin, eine neue sauber Implementierung mit einem neuen Satz von Argumenten und Flags bereitzustellen.

Swizzlingbereiche werden aus WDDM Version 2 entfernt. Es liegt in der Verantwortung des Treiberentwicklers, die Abhängigkeit von swizzling-Bereichen von Aufrufen von LockCb zu entfernen, während diese zu einer Implementierung wechseln, die auf Lock2Cb basiert.

Lock2Cb wird als einfache Methode zum Abrufen einer virtuellen Adresse für eine Zuordnung verfügbar gemacht. Es gibt einige Einschränkungen, die auf der Art der Zuordnung und dem aktuellen Segment basieren, in dem sie sich derzeit befindet.

Der Treiber gibt an, ob auf ein Segment über das CpuVisible-Flag zugegriffen werden kann, das sich im Flags-Element der DXGK_SEGMENTDESCRIPTOR-Struktur befindet.

Für Zuordnungen mit CPU-Zugriff:

• Zwischengespeicherte CPU-barrierefreie Zuordnungen müssen sich innerhalb eines Blendensegments befinden oder nicht resident sein, um gesperrt zu werden. Wir können die Cachekohärenz zwischen der CPU und einem Speichersegment auf der Grafikverarbeitungseinheit (GPU) nicht garantieren.
• Cpu-barrierefreie Zuordnungen, die sich in einem vollständig auf die CPU zugänglichen Arbeitsspeichersegment befinden (größesverändert mithilfe der größenveränderlichen BAR), sind garantiert sperrbar und können eine virtuelle Adresse zurückgeben. In diesem Szenario sind keine besonderen Einschränkungen erforderlich.
• Zuordnungen mit CPU-Zugriff in einem Speichersegment, auf das nicht auf die CPU zugegriffen werden kann (mit oder ohne Zugriff auf eine CpuHostAperture), können aus verschiedenen Gründen nicht einer virtuellen CPU-Adresse zugeordnet werden. Wenn cpuHostAperture nicht mehr verfügbar ist oder die Zuordnung kein Blendensegment angibt, ist es unmöglich, eine virtuelle Adresse abzurufen. Aus diesem Grund müssen alle cpu-barrierefreien Zuordnungen in Nicht-CPU-zugänglichen Speichersegmenten ein Blendensegment in ihrer unterstützten Segmentmenge enthalten. Diese Anforderung garantiert, dass VidMm die Zuordnung im Systemspeicher platzieren und eine virtuelle Adresse angeben kann.
• Cpu-fähige Zuordnungen, die sich bereits im Systemspeicher befinden (und/oder einem Blendensegment zugeordnet sind) funktionieren garantiert.

Für Zuordnungen, auf die nicht auf die CPU zugegriffen werden kann:

• Cpu-barrierefreie Zuordnungen werden durch Abschnittsobjekte unterstützt, die nicht direkt auf den GPUs-Framepuffer verweisen können. Um eine Nicht-CPU-barrierefreie Zuordnung zu sperren, muss die Zuordnung ein Blendensegment in der unterstützten Segmentmenge unterstützen oder sich bereits im Systemspeicher befinden (darf sich nicht auf dem Gerät befinden).

Wenn eine Zuordnung erfolgreich gesperrt wurde, während die Zuordnung nicht auf dem Gerät vorhanden ist, aber kein Blendensegment unterstützt, darf die Zuordnung für die Dauer der Sperre nicht in ein Speichersegment committet werden.

Lock2 enthält derzeit keine Flags, und reservierte Flagbits müssen alle 0 sein.

CpuHostAperture

Um die Sperrung mit Nicht-CPU-zugänglichen Speichersegmenten besser zu unterstützen, wenn die Größenänderung des Balkens fehlschlägt, wird in der PCI-Blende eine CpuHostAperture bereitgestellt. CpuHostAperture verhält sich wie ein seitenbasierter Manager, der dann über die DDI-Funktion (DxgkDdiMapCpuHostApertureDevice Driver Interface) direkt Regionen des Videospeichers zugeordnet werden kann. Das VidMm kann dann einen Bereich des virtuellen Adressraums direkt einem nicht zusammenhängenden Bereich von CpuHostAperture zuordnen und die CpuHostAperture-Instanz dem Videospeicher zuordnen, ohne dass bereiche geschwommen werden müssen.

Die maximale Menge an sperrbarem Arbeitsspeicher, auf die die CPU in Nicht-CPU-zugänglichen Arbeitsspeichersegmenten verweisen kann, ist auf die Größe von CpuHostAperture beschränkt. Die Details zum Verfügbarmachen von CpuHostAperture für den DirectX-Grafikkern finden Sie unter CPU-Hostpertur.

E/A-Kohärenz

Auf x86/x64 müssen heute alle GPUs E/A-Kohärenz über PCIe unterstützen, damit eine GPU auf einer zwischenspeicherbaren Systemspeicheroberfläche lesen oder schreiben kann und die Kohärenz mit der CPU aufrechterhalten kann. Wenn eine Oberfläche aus Gpu-Sicht als Cache kohärent zugeordnet wird, muss die GPU die CPU-Caches beim Zugriff auf das Surface snoopn. Diese Form der Kohärenz wird in der Regel für Ressourcen verwendet, aus denen die CPU lesen soll, z. B. einige Stagingoberflächen.

Auf einigen Arm-Plattformen wird die E/A-Kohärenz nicht direkt in der Hardware unterstützt. Auf diesen Plattformen muss die E/A-Kohärenz emuliert werden, indem die CPU-Cachehierarchie manuell ungültig wird. Das VidMm verfolgt dazu Vorgänge zu einer Zuordnung, die von der GPU (Lese-/Schreibvorgang der Zuordnungsliste) und der CPU (Zuordnungsvorgang, Lese-/Schreibvorgang) stammt. VidMm gibt eine Cacheinvalidierung aus, wenn festgestellt wird, dass der Cache möglicherweise Folgendes enthält:

• Daten, die zurückgeschrieben werden müssen (CPU-Schreibvorgänge, GPU-Lesevorgänge)
• Veraltete Daten, die ungültig gemacht werden müssen (GPU-Schreibvorgänge, CPU-Lesevorgänge).

Auf einer Plattform ohne E/A-Kohärenz liegt die Verantwortung für die Nachverfolgung des CPU- und GPU-Zugriffs auf Zuordnungen bei der UMD. Der Grafikkern macht einen neuen Invalidate CacheDDI verfügbar, mit dem die UMD den virtuellen Adressbereich zurückschreiben und für ungültig erklären kann, der einer zwischenspeicherbaren Zuordnung zugeordnet ist. Auf Plattformen, die keine E/A-Kohärenz unterstützen, muss UMD diese Funktion nach dem CPU-Schreibvorgang und vor GPU-Lesevorgängen sowie nach dem Schreiben und vor dem Lesen der CPU aufrufen. Letzteres mag zunächst unintuitiv erscheinen. Da die CPU daten jedoch spekulativ gelesen haben könnte, bevor der GPU-Schreibvorgang sie in den Arbeitsspeicher macht, ist es notwendig, alle CPU-Caches für ungültig zu erklären, um sicherzustellen, dass die CPU Daten aus dem RAM erneut liest.