DX12_VK.md

Interface Belongs To Purpose 🧠 ID3D12Debug3 D3D12 Enables the debug layer, GPU validation, synchronized command validation, etc. Used before device creation. 📬 ID3D12InfoQueue D3D12 Receives runtime validation messages from D3D12 — your main D3D12 validation hook. Use this like VkDebugUtilsMessengerEXT. 📦 IDXGIInfoQueue DXGI Receives swapchain/factory messages, like invalid mode, missing formats, etc. DXGI-only validation. 🔎 IDXGIDebug DXGI Used to report leaked objects at shutdown (ReportLiveObjects) — works across both DXGI and D3D12 objects.

🔁 Lifecycle + Purpose Stage Interface When/Why 🔧 Before CreateDevice ID3D12Debug3 Enable validation layers and GPU validation. 🧱 After CreateDevice ID3D12InfoQueue Catch D3D12 validation errors. Set breakpoints or drain messages. 🔨 After CreateFactory IDXGIInfoQueue Catch DXGI swapchain/factory warnings or errors. 🧼 On Shutdown IDXGIDebug Report live DXGI/D3D12 objects (resource leak detection).

Slide 2: Feature Levels vs. Vulkan Device Features

Talking Points:

DX12 Feature Levels (11_0 → 12_2): coarse-grained capability buckets at device creation.
Vulkan: query VkPhysicalDeviceFeatures/VkPhysicalDeviceProperties and enable only needed features (VK Spec §33).
Levels gate resource binding tiers, heap tiers, tiled resources.
Vulkan Comparison: Vulkan’s per-feature model offers finer control; DX12 groups into preset levels for simplicity.

Theory Notes: Use D3D12CreateDevice(..., &featureLevel) to detect and branch code paths based on D3D_FEATURE_LEVEL_12_0 etc. (MSDN: feature levels). Vulkan’s model involves vkGetPhysicalDeviceFeatures and requiring explicit VkDeviceCreateInfo feature structures.

Slide 3: COM & Interfaces vs. Vulkan Handles

    +------------------------+                   +-------------------------+

    C Call:
    adapter->lpVtbl->GetDesc1(adapter, &desc);

    Impl (C++ only):
    HRESULT MyAdapter::GetDesc1(...) { ... }

EXTERN_C const IID IID_IDXGIAdapter1;

#if defined(__cplusplus) && !defined(CINTERFACE)

MIDL_INTERFACE("29038f61-3839-4626-91fd-086879011a05")
IDXGIAdapter1 : public IDXGIAdapter
{
public:
    virtual HRESULT STDMETHODCALLTYPE GetDesc1( 
        /* [annotation][out] */ 
        _Out_  DXGI_ADAPTER_DESC1 *pDesc) = 0;
    
};

#else /* C style interface */

typedef struct IDXGIAdapter1Vtbl
{
    BEGIN_INTERFACE
    
    DECLSPEC_XFGVIRT(IUnknown, QueryInterface)
    HRESULT ( STDMETHODCALLTYPE *QueryInterface )( 
        IDXGIAdapter1 * This,
        /* [in] */ REFIID riid,
        /* [annotation][iid_is][out] */ 
        _COM_Outptr_  void **ppvObject);
    
    DECLSPEC_XFGVIRT(IUnknown, AddRef)
    ULONG ( STDMETHODCALLTYPE *AddRef )( 
        IDXGIAdapter1 * This);

╔════════════════════════════════════════════════════════════╗ ║ COM ABI: Stable, Cross-Language ║ ╚════════════════════════════════════════════════════════════╝

🔧 OBJECT MEMORY LAYOUT (C & C++ Compatible)

    +------------------------------+
    | IFoo* (COM object pointer)   |
    +------------------------------+
              │
              ▼
    +------------------------------+
    | IFooVtbl* (vtable pointer)   |
    +------------------------------+
              │
              ▼
    +------------------------------+
    | QueryInterface (slot 0)      |
    | AddRef        (slot 1)       |
    | Release       (slot 2)       |
    | Bar           (slot 3)       |  ← IFoo method
    +------------------------------+

🔁 C++ CALL:

    obj->Bar(42);

🔁 C CALL:

    obj->lpVtbl->Bar(obj, 42);

💡 BOTH resolve to the SAME function via the vtable. ABI is fixed: same offsets, same signatures.

───────────────────────────────────────────────────────────────

🧠 WHY IS THIS ABI-STABLE?

✔ Vtable layout is frozen per interface UUID ✔ Object layout is always: [vtable*] ✔ Function order NEVER changes ✔ All interfaces derive from IUnknown ✔ Memory managed via AddRef/Release ✔ Extensibility via QueryInterface

───────────────────────────────────────────────────────────────

🔄 C INTERFACE:

typedef struct IFooVtbl { HRESULT (QueryInterface)(IFoo, REFIID, void**); ULONG (AddRef)(IFoo); ULONG (Release)(IFoo); HRESULT (Bar)(IFoo, int); } IFooVtbl;

typedef struct IFoo { IFooVtbl* lpVtbl; } IFoo;

───────────────────────────────────────────────────────────────

👨‍💻 C++ INTERFACE:

class IFoo : public IUnknown { public: virtual HRESULT Bar(int x) = 0; };

───────────────────────────────────────────────────────────────

🏗️ EXTENDING INTERFACES:

// Old interface IFoo { Bar() }

// New (safe) interface IFoo2 : IFoo { Baz() } ← separate UUID, new vtable

→ Use QueryInterface to access new features safely

───────────────────────────────────────────────────────────────

💎 COM ABI BENEFITS:

✅ Works across DLLs ✅ Cross-compiler & cross-language ✅ Immutable interface layout ✅ No name mangling issues ✅ Used by DirectX, Windows Shell, Office, etc.

───────────────────────────────────────────────────────────────

Talking Points:

DX12 objects are COM interfaces (IUnknown, vtable pointers, AddRef/Release, QueryInterface).
Vulkan: opaque handles with implicit dispatch tables keyed per-object (VK Spec §8.1).
COM ABI ensures language interoperability and binary stability (MSDN COM architecture).
Vulkan Comparison: Vulkan’s loader binds dispatch tables to handles; DX12 uses standard COM under-the-hood.

Theory Notes: COM reference counting auto-manages lifetimes; Vulkan requires explicit vkDestroy* calls. COM’s QueryInterface parallels Vulkan’s vkGet* functions for retrieving related interfaces.

Slide 4: DXGI (WSI) & Swapchains

Talking Points:

DXGI for WSI: IDXGIFactory4/6 enumerates adapters, creates swap chains (CreateSwapChainForHwnd).
Present modes: FLIP_DISCARD, FLIP_SEQUENTIAL (MSDN DXGI_SWAP_EFFECT).
Vulkan: VkSurfaceKHR, vkCreateSwapchainKHR, present modes (VK_PRESENT_MODE_FIFO_KHR, MAILBOX, IMMEDIATE) (VK Spec §12).
HDR/color spaces via IDXGISwapChain4::SetColorSpace1.
Vulkan Comparison: Vulkan uses platform-specific WSI extensions (VK_KHR_win32_surface, etc.); both require semaphores/fences for sync.

Theory Notes: DXGI abstracts window-system integration; slide buffers are ID3D12Resource textures. Vulkan’s swap chain images are VkImages bound to the surface.

Slide 5: Resource Types—Buffers & Textures

Talking Points:

ID3D12Resource: unified for buffers and textures (MSDN).
Dimensionality: Buffer, TEX1D/2D/3D, arrays, cube maps.
Usage flags: ALLOW_UNORDERED_ACCESS, ALLOW_RENDER_TARGET, ALLOW_DEPTH_STENCIL.
Layouts: TEXTURE_LAYOUT_ROW_MAJOR vs. UNKNOWN (optimal).
Vulkan Comparison: Vulkan splits VkBuffer and VkImage with explicit VkBufferCreateInfo/VkImageCreateInfo (VK Spec §3.2/3.3).

Theory Notes: DX12’s resource descriptor (D3D12_RESOURCE_DESC) bundles dimension, format, layout, and flags. Vulkan’s model separates image tiling (VK_IMAGE_TILING_*) for more explicit control.

Slide 6: Heaps & Memory—DX12 vs Vulkan

Talking Points:

DX12 Heaps: DEFAULT (GPU-only), UPLOAD (CPU-write), READBACK (CPU-read) (MSDN D3D12_HEAP_TYPE).
Committed vs. Placed resources: auto vs. manual sub-allocation.
Vulkan: vkAllocateMemory, memory types and heaps (VK Spec §10).
Sub-allocation: placed resources parallel Vulkan’s vkBind*Memory with offsets.
Vulkan Comparison: Vulkan’s fine-grained controls vs. DX12’s tier-based heap types.

Theory Notes: DX12’s heap model simplifies selection for common patterns; Vulkan allows arbitrary memory type matching via flags (e.g., HOST_VISIBLE, DEVICE_LOCAL). Third-party allocators like VMA fill the gap in Vulkan.

Slide 7: Resource Creation & Aliasing

Talking Points:

CreateCommittedResource (heap+resource) vs. CreatePlacedResource (sub-allocate).
Aliasing barriers (AliasingBarrier) when reusing the same heap region.
Vulkan: sparse binding and vkBindBufferMemory/vkBindImageMemory + layout transitions (VkImageMemoryBarrier) (VK Spec §15).
Vulkan Comparison: Both support memory aliasing; DX12 explicitly declares alias transitions.

Theory Notes: Use aliasing to minimize GPU memory footprint. DX12 requires explicit D3D12_RESOURCE_BARRIER_TYPE_ALIASING calls; Vulkan sparse binding offers more dynamic page-level control.

Slide 8: Descriptors & Heaps—ASCII Model

Talking Points:

┌─────────────────────────────────────────────────────┐ │ /// DESCRIPTOR HEAPS /// │ └─────────────────────────────────────────────────────┘

• Descriptor Heaps = linear GPU memory slabs for views (CBV/SRV/UAV) or samplers • Two views: ├─ CPU‐visible (for writing descriptors) └─ GPU‐visible (for binding in root signature) • Heap Types: ├─ D3D12_DESCRIPTOR_HEAP_TYPE_CBV_SRV_UAV └─ D3D12_DESCRIPTOR_HEAP_TYPE_SAMPLER • Analogous to Vulkan’s VkDescriptorPool + VkDescriptorSetLayout but flattened

┌─────────────────────────────────────────────────────┐ │ /// CREATING A DESCRIPTOR HEAP /// │ └─────────────────────────────────────────────────────┘

Step 1. Fill D3D12_DESCRIPTOR_HEAP_DESC: ├─ Type = CBV_SRV_UAV ├─ NumDescriptors = 100 ├─ Flags = SHADER_VISIBLE └─ NodeMask = 0

Step 2. Call device->CreateDescriptorHeap(&desc, IID, &heap);

Step 3. Get CPU handle start: ptrCPU = heap->GetCPUDescriptorHandleForHeapStart();

Step 4. (Optional) GPU handle: ptrGPU = heap->GetGPUDescriptorHandleForHeapStart();

Step 5. Write descriptors: device->CreateConstantBufferView(&cbvDesc, ptrCPU + i*stride);

CPU Descriptor Heap (CBV/SRV/UAV, CPU_ONLY)
+-------------------------------+
| [Offset 0] CBV to buf0        |  D3D12_CPU_DESCRIPTOR_HANDLE cpu0 = heap->GetCPUHandle(0)
| [Offset 1] SRV to texA        |  descSize = device->GetDescriptorHandleIncrementSize(TYPE)
| [Offset 2] UAV to buf2        |  cpuHandle = cpuHeapStart + 1 * descSize
| ...                           |
| [Offset 63] ...               |
+-------------------------------+
          |
          | CopyDescriptorsSimple( n, gpuHeap->GetCPUHandle(0), cpuHeap->GetCPUHandle(0), TYPE )
          v
GPU Descriptor Heap (SHADER_VISIBLE)
+-------------------------------+
| [Offset 0] GPUVisibleHnd0     |  D3D12_GPU_DESCRIPTOR_HANDLE gpu0 = heap->GetGPUHandle(0)
| [Offset 1] GPUVisibleHnd1     |  gpuHandle = gpuHeapStart + 1 * descSize
| [Offset 2] GPUVisibleHnd2     |
| ...                           |
| [Offset 63] ...               |
+-------------------------------+
Shader binding via root descriptor table: BaseGPUHandle + index * descSize

**References:**  
- MSDN: CreateDescriptorHeap, CopyDescriptorsSimple (https://docs.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-id3d12device-createdescriptorheap)  
- VK Spec §7: Descriptor Sets and Pools (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#descriptorsets)
----------------------+    ------------>   +----------------------+
| Offset0: CBV to buf0 |                     | Offset0: ShaderVisHnd|
| Offset1: SRV to texA |                     | Offset1: ShaderVisHnd|
| Offset2: UAV to buf2 |                     | Offset2: ShaderVisHnd|
| ...                  |                     | ...                  |
+----------------------+                     +----------------------+
GetCPUDescriptorHandleForHeapStart() &        GetGPUDescriptorHandleForHeapStart()
pass CPU writes, then copy into GPU heap before binding.

Slide 9: CPU vs GPU Descriptors

Talking Points & Theory Notes:

CPU heap updates: Create*View into CPU heap; fast writes.
Copy to GPU heap: CopyDescriptors, CopyDescriptorsSimple (MSDN).
Bind GPU heap: SetDescriptorHeaps + root signature tables.
Vulkan Comparison: vkUpdateDescriptorSets writes directly to pool memory; driver handles paging.

Slide 10: Root Signatures vs Pipeline Layouts

Talking Points & Theory Notes:

Root signature elements: root constants, root descriptors, descriptor tables (MSDN).
Vulkan: VkPipelineLayout includes VkDescriptorSetLayouts + VkPushConstantRange (VK Spec §14).
DX12 allows inline constants, reducing indirection.

Slide 11: PSO vs VkPipeline

Talking Points & Theory Notes:

PSO (ID3D12PipelineState): monolithic, includes shaders, root sig, blend/depth states (MSDN).
Vulkan: VkPipeline created per-state, use VkPipelineCache to speed up (VK Spec §18).
Pipeline libraries and serialization exist in both.

Slide 12: Command Lists vs Command Buffers

Talking Points & Theory Notes:

DX12: ID3D12GraphicsCommandList + bundles for secondary lists (MSDN).
Vulkan: VkCommandBuffer + secondary buffers.
Recording/reset: DX12 Reset/Close, Vulkan vkBegin/vkEnd (VK Spec §9).

Slide 13: Synchronization & Barriers

Talking Points & Theory Notes:

DX12: D3D12_RESOURCE_BARRIER types—Transition, Aliasing, UAV; fences/events via ID3D12Fence (MSDN).
Vulkan: vkCmdPipelineBarrier, VkMemoryBarrier, semaphores/fences (VK Spec §12).

Slide 14: Render Passes vs Manual RTV/DSV Binding

Talking Points & Theory Notes:

Vulkan’s VkRenderPass defines attachments, subpasses, dependencies (VK Spec §7.3).
DX12: no render pass object; manually bind RTV/DSV via OMSetRenderTargets and issue barriers.
DX12 tile-based architectures depend on explicit clear calls and barrier hints.

Slide 15: Feature & Extension Management

Talking Points & Theory Notes:

Check support via CheckFeatureSupport (MSDN).
Interface casting for new features: ID3D12DeviceX where X indicates version.
Vulkan: enumerate and enable extensions in vkCreateDevice.

Slide 16: Debugging & Profiling

Talking Points & Theory Notes:

DX12 debug layer (ID3D12Debug), GPU-based validation (ID3D12DebugDevice1), PIX markers.
Vulkan: VK_EXT_debug_utils, validation layers, RenderDoc.

Slide 17: Mesh & Amplification Shaders

Talking Points & Theory Notes:

DX12: DispatchMesh, DispatchMeshIndirect with ID3D12PipelineState5 (MSDN).
Vulkan: VK_EXT_mesh_shader, vkCmdDrawMeshTasksEXT (VK Spec §45).

Slide 18: Bindless Rendering & NonUniformResourceIndex

Talking Points:

Unbounded descriptor tables (DESCRIPTOR_RANGE_FLAG_DESCRIPTORS_VOLATILE).
HLSL: use NonUniformResourceIndex to circumvent uniform indexing rules.
Vulkan Comparison: VK_EXT_descriptor_indexing and nonUniformIndexing (VK Spec §14.3).

Theory Notes: Descriptor indexing allows shaders to fetch resources out-of-bounds of static array sizes. In HLSL:

Texture2D myTextures[] : register(t0);
uint idx = input.Index;
auto srv = myTextures[NonUniformResourceIndex(idx)];

Slide 19: Sampler Feedback & VRS

Talking Points & Theory Notes:

Sampler feedback: D3D12_FEATURE_D3D12_OPTIONS12; track requested texture mips/tiles for streaming.
Variable rate shading: D3D12_FEATURE_D3D12_OPTIONS6.
Vulkan: VK_EXT_sampler_feedback, VK_KHR_fragment_shading_rate.

Slide 20: Resource Lifetime & State Management

Talking Points & Theory Notes:

Explicit state transitions and hazard tracking in DX12.
Vulkan: VkImageMemoryBarrier, subpass dependencies.
Best practices: batch barriers, minimize flushes.

Slide 21: Memory Heaps & Aliasing

Talking Points & Theory Notes:

Detailed heap tiers: tier 1 vs tier 2 resource binding, alignment requirements.
Aliasing strategies: ring allocators, per-frame buffering.
Vulkan sparse binding: fine-grained page mapping vs DX12’s coarse aliasing.

Slide 22: Pipeline Differences Overview

Talking Points & Theory Notes:

Monolithic PSO vs modular Vulkan pipelines (shader modules + pipeline cache).
Root signature vs descriptor set layouts + push constants.
Render pass vs manual RTV/DSV.
Map each Vulkan concept to DX12 equivalent in table form.

Slide 23: Descriptor Memory Models

Talking Points & Theory Notes:

Opaque descriptor sets (Vulkan) vs direct descriptor heaps (DX12).
Allocation cost: pool allocate vs raw heap creation.
Update cost: vkUpdateDescriptorSets driver-managed vs explicit copy in DX12.

Slide 24: Render Pass & Framebuffer Details

Talking Points & Theory Notes:

Vulkan: subpass load/store ops, multisample resolves.
DX12: manual clear (ClearRenderTargetView), resolve via ResolveSubresource.

Slide 25: Summary of Key Differences

Talking Points:

Render passes vs manual barriers.
Descriptor pools vs heaps.
PSO vs pipeline cache & libraries.
Feature levels vs extension querying.

Theory Notes:

Vulkan Construct	DX12 Equivalent
`VkRenderPass`	Manual RTV/DSV binding + barriers
`VkDescriptorSet`	Descriptor heap entry in CPU/GPU heaps
`VkPipeline` + `VkPipelineCache`	`ID3D12PipelineState` + `ID3D12PipelineLibrary`
`VkPhysicalDeviceFeatures`	`D3D_FEATURE_LEVEL_X` + `CheckFeatureSupport`

Links: MSDN D3D12 docs & Vulkan Spec (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html)

======

🧠 1. Theory: Descriptor Heaps & Indexing in DX12 Descriptor Heap A descriptor is a GPU-visible handle to a resource (like a texture, buffer, sampler). DX12 has the notion of descriptor heaps—linear arrays of descriptors in GPU-visible memory. There are 4 types of descriptor heaps:

CBV_SRV_UAV: Constant Buffer, Shader Resource, Unordered Access
SAMPLER
RTV: Render Target
DSV: Depth Stencil But only CBV_SRV_UAV and SAMPLER heaps can be shader-visible. Root Signature & Root Table A root signature defines how shaders access resources. The typical way:
Use a descriptor table (pointer into the heap)
Index into it in the shader using a register (t0, u0, s0, etc.) For bindless, you create a large descriptor heap (e.g., 100k entries) and bind it once. Then:
In the shader, you use NonUniformResourceIndex to access a dynamic index.
Indexing is dynamic and non-uniform, so GPU must not assume same index across threads.

🧩 2. Vulkan Comparison (Why it's more opaque) Vulkan doesn't expose descriptor heaps directly. Instead:

Uses descriptor sets (collections of bindings).
You allocate descriptor set layouts, which define the types and number of descriptors.
Then you allocate descriptor sets from descriptor pools, and bind them explicitly per draw. Bindless in Vulkan? Possible, but harder:
Needs VK_EXT_descriptor_indexing extension.
Must enable descriptorBindingVariableDescriptorCount, descriptorBindingPartiallyBound, and mark bindings with VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT.
Descriptor indexing is accessed via NonUniformEXT and runtime arrays in shaders. There’s no concept of a monolithic descriptor heap like in DX12.

Shader Models in DirectX 12 define the capabilities and feature level of shaders, acting as a versioned contract between the HLSL compiler, runtime, and GPU driver. Starting from Shader Model 6.0 (released in 2017 with DXIL and wave intrinsics), newer versions like SM6.6 and SM6.7—delivered through the Agility SDK—add advanced features such as resource descriptor indexing (bindless), inline ray queries, and wave size control (SM6.8). These are enabled via CheckFeatureSupport(D3D12_FEATURE_SHADER_MODEL) and require both compiler (dxcompiler) and runtime support. Shader compilation targets are specified explicitly (e.g., cs_6_7) and compile to DXIL, the DirectX Intermediate Language. This model is tightly integrated with the Agility SDK (https://learn.microsoft.com/en-us/windows/win32/direct3d12/d3d12agilitysdk), which decouples shader feature adoption from OS updates, letting apps opt into newer Shader Models through versioned redistributables. In contrast, Vulkan exposes shader features via extension enums, VkPhysicalDeviceFeatures2, and SPIR-V capabilities, offering more granular control but less centralized versioning. For example, Vulkan's descriptor indexing (VK_EXT_descriptor_indexing) or float16 (VK_KHR_shader_float16_int8) extensions map to Shader Model 6.5 and 6.2 features, respectively. Documentation and feature matrices can be found at Microsoft’s Shader Model 6 overview (https://learn.microsoft.com/en-us/windows/win32/direct3d12/d3d12-graphics-programming-guide-shader-model-6-overview) and the HLSL compiler repo (https://github.com/microsoft/DirectXShaderCompiler).

Pikachuxxxx/DX12_VK.md

Pikachuxxxx commented Jun 20, 2025

Uh oh!