Freigegebene Heaps

Die Freigabe ist nützlich für Multiprozess- und Multiadapterarchitekturen.

Überblick über Freigabe

Freigegebene Heaps ermöglichen zwei Dinge: Das Freigeben von Daten in einem Heap über einen oder mehrere Prozesse hinweg und eine nicht deterministische Auswahl des nicht definierten Texturlayouts für Ressourcen, die innerhalb des Heaps platziert werden. Das Freigeben von Heaps über Adapter hinweg entfernt auch die Notwendigkeit der CPU-Marshalling der Daten.

Sowohl Heaps als auch zugesicherte Ressourcen können freigegeben werden. Das Freigeben einer zugesicherten Ressource teilt tatsächlich den impliziten Heap zusammen mit der Beschreibung der zugesicherten Ressource, sodass eine kompatible Ressourcenbeschreibung dem Heap von einem anderen Gerät zugeordnet werden kann.

Alle Methoden sind Freethreads und erben die vorhandene D3D11-Semantik des NT-Handle-Freigabedesigns.

Freigeben von Heaps über Prozesse hinweg

Freigegebene Heaps werden mit dem D3D12_HEAP_FLAG_SHARED Member der D3D12_HEAP_FLAGS Enumeration angegeben.

Freigegebene Heaps werden auf Heaps mit CPU-Zugriff nicht unterstützt: D3D12_HEAP_TYPE_UPLOAD, D3D12_HEAP_TYPE_READBACK und D3D12_HEAP_TYPE_CUSTOM ohne D3D12_CPU_PAGE_PROPERTY_NOT_AVAILABLE.

Das Vorschließen einer nicht deterministischen Auswahl eines nicht definierten Texturlayouts kann verzögerte Rendering-Szenarien für einige GPUs erheblich beeinträchtigen, sodass es nicht das Standardverhalten für platzierte und zugesicherte Ressourcen ist. Das verzögerte Rendering wird bei einigen GPU-Architekturen beeinträchtigt, da deterministische Texturlayouts die effektive Speicherbandbreite verringern, die beim gleichzeitigen Rendern auf mehrere Render-Zieltexturen desselben Formats und derselben Größe erzielt wird. GPU-Architekturen entwickeln sich von der Nutzung nicht deterministischer Texturlayouts weg, um standardisierte Swizzle-Muster und standardisierte Layouts effizient für verzögertes Rendering zu unterstützen.

Freigegebene Heaps kommen auch mit anderen Nebenkosten:

  • Freigegebene Heapdaten können nicht so flexibel wie In-Prozess-Heaps aufgrund von Informationsveröffentlichungsbedenken wiederverwendet werden, sodass der physische Speicher häufiger null ist.
  • Es gibt einen geringfügigen zusätzlichen CPU-Aufwand und eine erhöhte Systemspeicherauslastung während der Erstellung und Zerstörung freigegebener Heaps.

Freigeben von Heaps über Adapter hinweg

Freigegebene Heaps über Adapter hinweg werden mit dem D3D12_HEAP_FLAG_SHARED_CROSS_ADAPTER Member der D3D12_HEAP_FLAGS Enumeration angegeben.

Über einen Adapter freigegebene Heaps können mehrere Adapter Daten freigeben, ohne dass die CPU die Daten zwischen ihnen Marshallen muss. Während unterschiedliche Adapterfunktionen bestimmen, wie effizient Adapter Daten zwischen ihnen übergeben können, erhöht lediglich die Aktivierung von GPU-Kopien die effektive Bandbreite. Einige Texturlayouts sind für Kreuzadapter-Heaps zulässig, um einen Austausch von Texturdaten zu unterstützen, auch wenn solche Texturlayouts andernfalls nicht unterstützt werden. Bestimmte Einschränkungen können für solche Texturen gelten, z. B. nur das Kopieren unterstützen.

Die adapterübergreifende Freigabe funktioniert mit Heaps, die durch Aufrufen von ID3D12Device::CreateHeap erstellt wurden. Ihre Anwendung kann dann Ressourcen über CreatePlacedResource erstellen. Es ist auch von Ressourcen/Heaps zulässig, die von CreateCommittedResource erstellt wurden, jedoch nur für Zeilen-Hauptressourcen D3D12_RESOURCE_DIMENSION_TEXTURE2D (siehe D3D12_RESOURCE_DIMENSION). Die adapterübergreifende Freigabe funktioniert nicht mit CreateReservedResource.

Für die adapterübergreifende Freigabe gelten weiterhin alle üblichen Regeln für die ressourcenübergreifende Ressourcenfreigabe. Ihre Anwendung muss die geeigneten Hindernisse ausstellen, um eine ordnungsgemäße Synchronisierung und Kohärenz zwischen den beiden Adaptern sicherzustellen. Ihre Anwendung sollte adapterübergreifende Funktionen verwenden, um die Planung von Befehlslisten zu koordinieren, die an mehrere Adapter übermittelt werden. Es gibt keinen Mechanismus zum Freigeben von adapterübergreifenden Ressourcen in D3D-API-Versionen. Gemeinsam genutzte Ressourcen werden nur im Systemspeicher unterstützt. Adapterübergreifend gemeinsam genutzte Heaps/Ressourcen werden in D3D12_HEAP_TYPE_DEFAULT-Heaps und D3D12_HEAP_TYPE_CUSTOM-Heaps (mit dem L0-Speicherpool und den Eigenschaften der schreibgeschützten CPU-Seite) unterstützt. Treiber müssen sicherstellen, dass GPU-Lese-/Schreibvorgänge für gemeinsam genutzte Heaps mit anderen GPUs auf dem System übereinstimmen. Der Treiber muss z. B. die Heap-Daten möglicherweise aus den GPU-Caches ausschließen, die in der Regel nicht geleert werden müssen, wenn die CPU nicht direkt auf die Heapdaten zugreifen kann.

Ihre Anwendung sollte die Verwendung von Adapter-Heaps nur auf Szenarien beschränken, die die bereitgestellten Funktionen erfordern. Cross-Adapter-Heaps befinden sich in D3D12_MEMORY_POOL_L0, was nicht immer von GetCustomHeapProperties vorgeschlagen wird. Dieser Speicherpool ist für diskrete/ NUMA-Adapterarchitekturen nicht effizient. Und die effizientesten Texturlayouts sind nicht immer verfügbar.

Es gelten jedoch außerdem die folgenden Einschränkungen:

  • Die Heap-Flags im Zusammenhang mit Heap-Ebenen müssen D3D12_HEAP_FLAG_ALLOW_ALL_BUFFERS_AND_TEXTURES sein.
  • D3D12_HEAP_FLAG_SHARED müssen ebenfalls festgelegt werden.
  • Entweder muss D3D12_HEAP_TYPE_DEFAULT oder D3D12_HEAP_TYPE_CUSTOM mit D3D12_MEMORY_POOL_L0 und D3D12_CPU_PAGE_PROPERTY_NOT_AVAILABLE festgelegt werden.
  • Nur Ressourcen mit D3D12_RESOURCE_FLAG_ALLOW_CROSS_ADAPTER können auf Adapter-Heaps platziert werden.
  • Eine geschützte Sitzung kann nicht an die Erstellung des Heaps übergeben werden, wenn D3D12_HEAP_FLAG_SHARED_CROSS_ADAPTER angegeben wird.

Weitere Informationen zur Verwendung mehrerer Adapter finden Sie im Abschnitt Systeme mit mehreren Adaptern.