Direct3D 12 Core 1.0-Featureebene

Die Core 1.0-Featureebene ist eine Teilmenge des vollständigen Direct3D 12-Featuresatzes. Die Core 1.0-Featureebene kann durch eine Kategorie von Geräten verfügbar gemacht werden, die als rein computebasierte Geräte bezeichnet werden. Das allgemeine Treibermodell für Computer, die nur computebasierte Geräte sind, ist das Microsoft Compute Driver Model (MCDM). MCDM ist ein herunterskaliertes Peer des Windows Device Driver Model (WDDM), das über einen größeren Bereich verfügt.

Ein Gerät, das nur die Features innerhalb einer Kernfunktionsebene unterstützt, wird als Core-Gerät bezeichnet.

Hinweis

Computergeräte, MCDM-Geräte, Core Feature Level-Geräte und Core-Geräte bedeuten dasselbe. Der Einfachheit halber bevorzugen wir das Core-Gerät.

Erstellen eines Core-Geräts

Im Allgemeinen rufen Sie zum Erstellen eines Direct3D 12-Geräts die Funktion D3D12CreateDevice auf und geben eine Mindestfunktionsebene an.

Wenn Sie eine Featureebene von 9 bis 12 angeben, ist das zurückgegebene Gerät ein funktionsreiches Gerät, z. B. eine herkömmliche GPU (die eine Obermenge der Funktionalität eines Core-Geräts unterstützt). Ein Core-Gerät wird für diesen Bereich von Featureebenen nie zurückgegeben.

Wenn Sie andererseits eine Core-Featureebene angeben (z. B. D3D_FEATURE_LEVEL::D 3D_FEATURE_LEVEL_1_0_CORE),kann das zurückgegebene Gerät funktionsreich sein, oder es kann ein Core-Gerät sein.

// d3dcommon.h
D3D_FEATURE_LEVEL_1_0_CORE = 0x1000

Wenn Sie eine _CORE Featureebene angeben, überprüft die Laufzeit-/Debugebene, ob die von Ihrer Anwendung verwendeten Features von dieser Featureebene zugelassen _CORE werden. Dieser Satz von Features wird weiter unten in diesem Thema definiert.

Shadermodell für Core-Geräte

Ein Core-Gerät unterstützt shader Model 5.0 oder mehr.

Die Runtime führt die Konvertierung von 5.x-Nicht-DXIL-Shadermodellen in 6.0 DXIL durch. Daher muss der Treiber nur 6.x unterstützen.

Ressourcenverwaltungsmodell für Kerngeräte

  • Unterstützte Ressourcendimensionen: nur rohe und strukturierte Puffer (keine typisierten Puffer, texture1d/2D usw.)
  • Keine Unterstützung für reservierte (gekachelte) Ressourcen
  • Keine Unterstützung für benutzerdefinierte Heaps
  • Keine Unterstützung für diese Heapflags:
    • D3D12_HEAP_FLAG_HARDWARE_PROTECTED
    • D3D12_HEAP_FLAG_ALLOW_WRITE_WATCH
    • D3D12_HEAP_FLAG_ALLOW_DISPLAY
    • D3D12_HEAP_FLAG_ALLOW_SHADER_ATOMICS (Beachten Sie, dass Shader-Atomaren erforderlich sind, ist dieses Flag für ein anderes Feature, adapterübergreifende Atomaren)

Ressourcenbindungsmodell für Core-Geräte

  • Unterstützung nur für Ressourcenbindungsebene 1
  • Ausnahmen:
    • Keine Unterstützung für Textur-Sampler
    • Unterstützung für 64 UAVs wie Featureebene 11.1 und mehr (im Gegensatz zu nur 8)
    • Implementierungen müssen keine Begrenzungen implementieren, die bei Shaderzugriffen auf Ressourcen über Deskriptoren überprüft werden. Zugriffe außerhalb der Grenzen führen zu undefiniertem Verhalten.
      • Als Nebenprodukt wird das Deskriptorbereichsflag D3D12_DESCRIPTOR_RANGE_FLAG_DESCRIPTORS_STATIC_KEEPING_BUFFER_BOUNDS_CHECKS in Stammsignaturen nicht unterstützt.
  • UAV-/CBV-Deskriptoren können nur für Ressourcen aus Standardheaps erstellt werden (also keine Upload-/Rückschreibeheaps). Dadurch wird ihre Anwendung gezwungen, Kopien durchzuführen, um Daten über CPU-<->GPU abzurufen.
  • Obwohl es sich um die niedrigste Bindungsfunktionenebene handelt, sind auch in dieser Ebene noch einige Features erforderlich, die es wert sind, aufzurufen:
    • Deskriptorheaps können aktualisiert werden, nachdem Befehlslisten aufgezeichnet wurden (siehe D3D12_DESCRIPTOR_RANGE_FLAG_DESCRIPTORS_VOLATILE in der Ressourcenbindungsspezifikation).
    • Stammdeskriptoren sind im Grunde GPUVA-Zeiger.
      • Obwohl keine MMU-/VA-Unterstützung vorhanden ist, können Puffer-VAs, die in Stammdeskriptoren verwendet werden, durch Implementierungen durch Adresspatches emuliert werden.

Einschränkungen für strukturierte Puffer

Strukturierte Puffer müssen über eine Basisadresse verfügen, die auf 4 Byte ausgerichtet ist, und stride muss 2 oder ein Vielfaches von 4 sein. Der Fall für einen Schritt von 2 gilt für Apps mit 16-Bit-Daten, insbesondere wenn typisierte Puffer in D3D_FEATURE_LEVEL_1_0_CORE nicht unterstützt werden.

Die in Deskriptoren angegebene Stride muss mit dem in HLSL angegebenen Schritt übereinstimmen.

Unterstützung von Befehlswarteschlangen für Core-Geräte

Nur Compute- und Kopierwarteschlangen (keine 3D-, Video- usw. Warteschlangen).

Shaderunterstützung für Core-Geräte

Nur Compute-Shader, keine Grafik-Shader (Scheitelpunkt, Pixel-Shader usw.) oder verwandte Funktionen wie Renderziele, Austauschketten, Eingabeassemblierer.

Arithmetische Genauigkeit

Kerngeräte müssen keine Denorms für 16-Bit-Gleitkommavorgänge unterstützen.

Unterstützte APIs für Core-Geräte

Die folgende Liste stellt die unterstützte Teilmenge der vollständigen Anwendungsprogrammierschnittstelle dar (APIs, die in Core 1.0 Feature Level nicht unterstützt werden, sind nicht aufgeführt).

ID3D12Device-Methoden

ID3D12Device1-Methoden

ID3D12Device2-Methoden

ID3D12Device3-Methoden

ID3D12Device4-Methoden

ID3D12Device5-Methoden

ID3D12CommandQueue-Methoden

ID3D12CommandList-Methoden

ID3D12GraphicsCommandList-Methoden

ID3D12GraphicsCommandList1-Methoden

ID3D12GraphicsCommandList2-Methoden

ID3D12GraphicsCommandList4-Methoden