Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Da die Zuordnungsliste nicht mehr vorhanden ist, hat der Videospeicher-Manager (VidMm) keine Einblicke mehr in die Zuordnungen, auf die in einem bestimmten Befehlspuffer verwiesen wird. Daher ist der VidMm nicht mehr in der Lage, die Zuordnungsnutzung nachzuverfolgen und die zugehörige Synchronisierung zu verarbeiten. Diese Verantwortung fällt nun auf den Benutzermodustreiber (UMD). Insbesondere muss die UMD die Synchronisierung bezüglich des direkten CPU-Zugriffs auf die Speicherzuweisung und Umbenennung handhaben.
Die VidMm verzögert die Zerstörung von Zuweisungen asynchron und auf sichere Weise, die sowohl nicht blockierend für den aufrufenden Thread als auch leistungsfähig ist. Daher muss sich eine UMD nicht darum kümmern, die Zuweisungsvernichtung zurückstellen zu müssen. Wenn VidMm eine Zuordnungsvernichtungsanforderung empfängt, wird standardmäßig davon ausgegangen, dass Befehle, die vor der Zerstörungsanforderung in die Warteschlange gestellt wurden, möglicherweise auf die zu zerstörende Zuordnung zugreifen können. VidMm verschiebt somit den Löschvorgang, bis die Befehle in der Warteschlange abgeschlossen sind. Wenn die UMD weiß, dass ausstehende Befehle nicht auf die zu zerstörende Zuordnung zugreifen, kann die VidMm angewiesen werden, die Anforderung zu verarbeiten, ohne darauf zu warten, indem das Flag "AssumeNotInUse " beim Aufrufen von Deallocate2 oder DestroyAllocation2 festgelegt wird.
Lock2
Die UMD ist für die Verarbeitung einer ordnungsgemäßen Synchronisierung im Hinblick auf den direkten CPU-Zugriff verantwortlich. Insbesondere ist eine UMD für Folgendes erforderlich:
Unterstützen Sie die Semantik für das Nicht-Überschreiben und das Verwerfen von Sperren, was bedeutet, dass die UMD ein eigenes Umbenennungsschema implementieren muss.
Für Zuordnungsvorgänge, die eine Synchronisierung erfordern (d. r. nicht das oben genannte "No-overwrite" oder "verwerfen"):
- Geben Sie WasStillDrawing zurück, wenn versucht wird, auf eine derzeit ausgelastete Zuordnung zuzugreifen und der Aufrufer angefordert hat, dass der Sperrvorgang den aufrufenden Thread nicht blockieren soll (D3D11_MAP_FLAG_DO_NOT_WAIT).
- Oder, wenn das D3D11_MAP_FLAG_DO_NOT_WAIT-Flag nicht gesetzt ist, warten Sie, bis eine Zuordnung für den CPU-Zugriff verfügbar wird. Die UMD muss einen nicht-abfragenden Wartevorgang implementieren. Die UMD nutzt den neuen Kontextüberwachungsmechanismus.
Für den Moment muss die UMD weiterhin LockCb/UnlockCb aufrufen, damit die VidMm eine Zuordnung für den CPU-Zugriff einrichtet. In den meisten Fällen kann die UMD die Zuordnung für die gesamte Lebensdauer beibehalten. In Zukunft werden LockCb und UnlockCb zugunsten der neuen Lock2Cb- und Unlock2Cb-Aufrufe veraltet werden. Das Ziel dieser modernen Rückruffunktionen besteht darin, eine neue saubere Implementierung mit einem frischen Satz von Argumenten und Flags bereitzustellen.
Swizzling-Bereiche werden ab Version 2 des WDDM entfernt. Es liegt in der Verantwortung des Treiberentwicklers, die Abhängigkeit der Swizzling-Bereiche von Aufrufen der Funktion LockCb zu entfernen und zu einer Implementierung überzugehen, die auf Lock2Cb basiert.
Lock2Cb wird als einfache Methode zum Abrufen einer virtuellen Adresse für eine Zuordnung bereitgestellt. Es gibt einige Einschränkungen, die auf der Art der Zuordnung und dem aktuellen Segment basieren, in dem es derzeit ansässig ist.
Der Treiber zeigt anhand des CpuVisible-Flags an, ob ein Segment vom Prozessor zugänglich ist. Dieses Flag befindet sich im Flags-Mitglied der DXGK_SEGMENTDESCRIPTOR-Struktur.
Für CPU-zugängliche Zuordnungen:
- Zwischengespeicherte CPU-zugängliche Zuordnungen müssen sich in einem Apertursegment befinden oder nicht im Speicher sein, um gesperrt zu werden. Wir können die Cachekohärenz zwischen der CPU und einem Speichersegment für die Grafikverarbeitungseinheit (GPU) nicht garantieren.
- CPU-zugängliche Zuordnungen, die sich in einem vollständig CPU-zugänglichen Speichersegment befinden (vergrößert mit der Resizable BAR), sind garantiert sperrbar und können eine virtuelle Adresse zurückgeben. In diesem Szenario sind keine besonderen Einschränkungen erforderlich.
- Cpu-zugängliche Zuordnungen innerhalb eines nicht CPU-zugänglichen Speichersegments (mit oder ohne Zugriff auf eine CpuHostAperture) können aus verschiedenen Gründen nicht in eine virtuelle CPU-Adresse eingebunden werden. Wenn die CpuHostAperture außerhalb des verfügbaren Speicherplatzes liegt oder die Zuordnung kein Blendensegment angibt, ist eine virtuelle Adresse nicht zu erhalten. Aus diesem Grund müssen alle CPU-zugänglichen Zuordnungen in nicht-CPU-zugänglichen Speichersegmenten ein Aperture-Segment in ihrem unterstützten Segmentset enthalten. Diese Anforderung garantiert, dass VidMm die Zuordnung innerhalb des Systemspeichers platzieren und eine virtuelle Adresse bereitstellen kann.
- CPU-zugängliche Zuordnungen, die sich bereits im Systemspeicher befinden (und/oder in einem Apertursegment zugeordnet sind), funktionieren garantiert.
Für nicht-CPU-zugängliche Zuordnungen:
- CPU-zugängliche Zuweisungen werden von Abschnittsobjekten unterstützt, die nicht direkt auf den GPU-Framepuffer verweisen können. Um eine nicht CPU-zugängliche Zuordnung zu sperren, muss die Zuordnung ein Blendensegment im unterstützten Segmentsatz unterstützen oder sich bereits im Systemspeicher befinden (darf nicht auf dem Gerät vorhanden sein).
Wenn eine Zuordnung erfolgreich gesperrt ist, während sie sich nicht auf dem Gerät befindet und kein Apertursegment unterstützt, darf die Zuordnung für die Dauer der Sperre nicht in ein Speichersegment zugewiesen 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 das Ändern der BAR-Größe fehlschlägt, wird eine CpuHostAperture in der PCI-Apertur bereitgestellt. Die CpuHostAperture verhält sich als seitenbasierter Manager, der dann über die DxgkDdiMapCpuHostApertureDevice Driver Interface (DDI)-Funktion direkt Regionen des Videospeichers zugeordnet werden kann. Die VidMm kann dann einen Bereich des virtuellen Adressraums direkt einem nicht zusammenhängenden Bereich des CpuHostAperture zuordnen und die CpuHostAperture anschließend auf den Videospeicher abbilden, ohne dass Swizzling-Bereiche erforderlich sind.
Die maximale Menge an sperrbarem Arbeitsspeicher, auf den die CPU in nicht CPU zugänglichen Speichersegmenten verweisen kann, ist auf die Größe des CpuHostAperture beschränkt. Die Details zum Verfügbarmachen des CpuHostAperture für den DirectX-Grafikkernel finden Sie in CPU-Host-Apertur.
E/A-Kohärenz
Auf x86/x64 muss heute alle GPUs die E/A-Kohärenz über PCIe unterstützen, um einer GPU das Lesen oder Schreiben auf eine zwischenspeicherbare Systemspeicheroberfläche zu ermöglichen und die Kohärenz mit der CPU aufrechtzuerhalten. Wenn eine Oberfläche aus der Sicht der GPU als Cache-kohärent zugewiesen wird, muss die GPU die CPU-Caches beim Zugriff auf die Oberfläche durchsuchen. Diese Form der Kohärenz wird in der Regel für Ressourcen verwendet, von 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. Die VidMm führt dies durch Nachverfolgen von Vorgängen zu einer Zuordnung aus der GPU (Zuordnungslisten-Lese-/Schreibvorgang) und der CPU (Zuordnungsvorgang, Lese-/Schreibzugriff) durch. VidMm gibt eine Cache-Ungültigheit aus, wenn sie bestimmt, dass der Cache entweder Folgendes enthält:
- Daten, die zurückgeschrieben werden müssen (CPU-Schreibzugriff, GPU-Lesezugriff)
- Veraltete Daten, die ungültig gemacht werden müssen (GPU-Schreibzugriff, CPU-Lesevorgänge).
Auf Plattformen ohne E/A-Kohärenz liegt die Verantwortung, den CPU- und GPU-Zugriff auf Zuordnungen zu verfolgen, bei der UMD. Der Grafikkern macht einen neuen Invalidate CacheDDI verfügbar, den die UMD verwenden kann, um den virtuellen Adressbereich zurückschreiben und ungültig zu machen, der einer zwischenspeicherbaren Zuordnung zugeordnet ist. Auf Plattformen, die keine Unterstützung für E/A-Kohärenz haben, ist die UMD verpflichtet, diese Funktion nach dem CPU-Schreiben und vor dem GPU-Lesen sowie nach dem GPU-Schreiben und vor dem CPU-Lesen aufzurufen. Letzteres mag zunächst unintuitiv erscheinen. Da die CPU jedoch spekulative Daten vor dem GPU-Schreibvorgang in den Arbeitsspeicher lesen könnte, ist es erforderlich, alle CPU-Caches zu ungültig zu machen, um sicherzustellen, dass die CPU Daten aus dem RAM erneut liest.