Chapter 28 Modern Direct3D

A dedicated tool, tools/xna-oracle/, runs XNA 4.0 under Wine using the GAC assemblies and the in-prefix csc.exe. It renders each declarative scene through XNA and CNA’s D3D9 renderer, then compares the images at zero tolerance. Both sides use the same DXVK layer on the same GPU, isolating CNA behavior from differences between graphics stacks. The pinned corpus contains 39 scene files. Every retained comparison is an exact match under this Wine/DXVK configuration; the result does not cover paths absent from that corpus.

Full device lifecycle via plain Direct3DCreate9 (not D3D9Ex, a deliberate choice), with DeviceLost / DeviceResetting / DeviceReset handling; all five XNA stock effects, with 61 of 66 compiled shader variants byte-identical to Microsoft’s own shipped bytecode (the remaining five differ only by HLSL compiler version, and are separately compared through the oracle); an oracle- and mutation-verified SpriteEffect.fx, including the half-pixel offset Direct3D 9 is notorious for — caught before it could become a false-positive “closed” claim, because the offset’s absence is invisible on a $1\times 1$ test texture and only shows up at a larger size; and GraphicsProfile.Reach / .HiDef enforcement through a D3DCAPS9 query — the only audited CNA renderer where the distinction reaches a native capability query, as Chapter 12 already noted. Render-target sampling and the PreferPerPixelLighting/specular gaps described in Chapter 15 were corrected. The specular repair produced zero-tolerance frame matches for four of five PixelLighting bytecode variants via the oracle. The fifth, an untextured vertex-lit variant, is unreachable at the pin because the required position-only vertex layout is missing on the measured stock-effect paths.

Every SurfaceFormat besides Color remains unsupported (a shared, cross-renderer limitation from Chapter 14, not a D3D9-specific one). Texture3D has no oracle-scene coverage, but it has a capability-gated sub-volume SetData()/GetData() byte round trip: D3D9_Smoke creates a $4\times 4\times 4$ volume only when D3DCAPS9::MaxVolumeExtent is nonzero, writes 32 distinct RGBA bytes into the off-origin $2\times 2\times 2$ box at $(1,1,1)$, and requires an exact readback of that same box. The test proves D3D9’s LockBox() row- and slice-pitch copy in both directions; it does not prove an oracle rendering path or automatic mip generation. OcclusionQuery is not built for this renderer at all, the same gap D3D12 carries; and SpriteSortMode.Immediate / .Texture were confirmed not viable as deterministic oracle scenes at all — Immediate is not something a raster diff can observe, and Texture sorts by an implementation-defined GetHashCode(), which no two implementations are obligated to agree on. The caveat that applies to every result in this section: D3DCAPS9 itself is synthesized by DXVK on this dev loop, not reported by XNA-era Windows driver hardware — native-Windows hardware verification remains open, as stated above.

The D3D9 smoke test establishes render-target storage and recovery. An 8x8 target with Depth24Stencil8 is bound, cleared through the public device, and copied with D3D9’s required GetRenderTargetData()–system-memory-surface–LockRect() route; its own surface must contain the exact requested color. A cube-face target has the same proof for one selected face, followed by an independent back-buffer clear/readback after unbind.

MSAA is capability-gated by IDirect3D9::CheckDeviceMultiSampleType(), not assumed from the requested count. When 4x is available, a multisampled target is cleared and unbound; D3D9’s StretchRect() resolve must make its separate sampleable texture read exactly $(200,210,220,255)$. The assertion reads the resolved result, not the multisample surface. One naming trap matters here: this is an internal device-capability check in the creation path, not GraphicsDevice::SupportsCapability. D3D9 never overrides that public method, so MultiSampleAntiAliasing still reports true even when CheckDeviceMultiSampleType() rejects every count above one. The same mismatch affects AnisotropicFiltering: sampler creation uses D3DTEXF_ANISOTROPIC and D3DSAMP_MAXANISOTROPY, but neither the public query nor the setter consults and clamps to D3DCAPS9::MaxAnisotropy.

Multiple render targets are bounded by D3DCAPS9::NumSimultaneousRTs: two targets receive one exact-color clear, unbinding restores the back buffer, and requesting one more target than the device reports throws rather than silently truncating. This proves D3D9’s multi-attachment binding and clear semantics. It does not separately prove a shader with several fragment outputs, so the result should not be generalized into a G-buffer draw claim.

The oracle’s own scene format is a small, declarative text file, not a compiled asset or a piece of C++. The simplest scene in the corpus, colored3d.scene, fits in eleven lines:

With vertexcolor=true and lighting=false, BasicEffect draws one red/green/blue-cornered triangle under identity transforms over Color.CornflowerBlue, RGBA $(100,149,237,255)$. XNA and CNA render the scene independently. Matching corners establish vertex-color plumbing; matching interior pixels also exercise Gouraud interpolation. The more elaborate fog_gradient_quad (Chapter 22’s own negative-FogEnd finding), uses the identical file format with a handful of additional fog* keys — the same declarative scheme scales from this eleven-line triangle through the corpus’s 39 scenes.

The first was a sort-mode Z-clipping defect: zFarPlane=1 mapped a nonzero SpriteBatch layer depth outside Direct3D 9’s own valid clip-space Z range, silently clipping away any sprite with a nonzero layer depth entirely — fixed by using zFarPlane=-1 instead. The second was shared across renderers: GraphicsProfile never reached the device because Game’s GraphicsDevice was eagerly default-constructed (hardcoded to Reach) before GraphicsDeviceManager even existed to apply a game’s requested profile — meaning a game setting GraphicsProfile = HiDef; ApplyChanges(); had no path to the live device at all. This is a shared, cross-renderer bug, only discovered while building D3D9’s own tests, because D3D9 is the one renderer where the profile actually matters enough to notice.

The sign controls clip-space placement. SpriteBatch’s orthographic projection maps a layerDepth value in $[0,1]$ (XNA’s own documented range: 0 = front, 1 = back) onto Direct3D 9’s own native clip-space Z range, which is $[0,1]$ — not the $[-1,1]$ range OpenGL-family APIs use. Constructing that projection with zFarPlane=1 produces a near/far mapping where any layerDepth strictly greater than what the incorrect matrix treats as its own valid far bound gets clipped by the GPU’s fixed-function Z-clip test without an error. The default layerDepth=0 was unaffected, so the defect appeared only with nonzero depth ordering. The zFarPlane=-1 matrix maps the full documented $[0,1]$ layerDepth range maps inside Direct3D 9’s own valid clip volume instead of partly outside it.

Chapter 6’s CNAEXT PresentationMode is not lost before it reaches these renderers: the public manager/device forwarding path passes the selected enum to each renderer. But the final handlers are currently intentional no-ops. D3D11 explicitly discards mode; D3D12 has the same empty handler. They create and present their swap chain at the SDL window’s pixel size, not a separately rendered logical surface which could be letterboxed, cropped, or stretched.

Their SetVirtualResolution(width,height) methods only retain the supplied integers. On D3D11, GetViewportSize() still queries the window’s physical pixel size; on D3D12, the stored virtual dimensions are returned to the caller but do not create a scaling pass. Consequently setting Letterbox, Overscan, Stretch, NativeBackBuffer, or FixedHeightDynamicWidth produces no different presentation geometry on either native Direct3D renderer today. This is a renderer limitation, not an XNA-compatibility promise: the enum itself is a CNA extension, and there is no test that could honestly pixel-prove a mode-specific result until a logical render target plus final composite/scaling path exists.

The three renderers do not share one presentation-interval policy. D3D9 preserves CNA’s 0/1/2 conversion in D3DPRESENT_PARAMETERS: Immediate becomes D3DPRESENT_INTERVAL_IMMEDIATE, Two becomes D3DPRESENT_INTERVAL_TWO, and everything else becomes D3DPRESENT_INTERVAL_ONE. A runtime change marks presentation state dirty and immediately calls the same device-reset path used for a resize. This is the only CNA renderer in the Direct3D family whose source requests a literal native two-retrace interval.

It is not yet a safe implementation. Microsoft’s D3D9 contract says interval Two must be present in D3DCAPS9::PresentationIntervals, and windowed mode supports only Default, Immediate, and One.¹¹ 1 https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dpresent CNA checks neither condition. Its ordinary game window is windowed, so requesting Two can make IDirect3DDevice9::Reset() return failure. The renderer logs that result, restores its previous dimensions, leaves presentationDirty_ true, and retries at each later Present(); the public PresentationParameters still reports Two. No dedicated test exercises this route, and DXVK’s synthesized capability structure would not replace the still-needed real-Windows check anyway.

D3D11 and D3D12 make the opposite mistake. Both reduce the construction argument and every later setter call to vsyncEnabled_ = interval > 0; their Present() then passes only sync interval 1 or 0 to DXGI. DXGI itself accepts 1 through 4 and defines them as waiting for at least the corresponding number of vertical blanks,²² 2 https://learn.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgiswapchain-present so nothing in the native API forces CNA to collapse Two. The real windowed smoke paths prove that default presentation succeeds, but the D3D plans explicitly say the no-VSync/tearing branch is untested; no located test distinguishes sync interval 2 either.

The useful porting conclusion is deliberately narrow. D3D9 has the correct representation but incomplete validation and failure reporting; D3D11/12 have robust per-present selection but an unnecessarily Boolean representation. A successful reset or a stored PresentInterval::Two is not yet evidence of half-refresh pacing on any of the three. The cross-renderer table in §19.2.4 places these results beside the other eleven products in that audit cohort.

D3D9 likewise stands apart for the other three presentation fields. It maps the requested backbuffer enum to D3DFORMAT (with a required Color-specific A8B8G8R8-to-A8R8G8B8 display substitution), maps None/Depth16/Depth24/Depth24Stencil8 to no attachment, D16, D24X8, and D24S8 respectively, and writes D3DPRESENT_PARAMETERS.Windowed = !IsFullScreen. A later manager reset reaches UpdatePresentationFormatEXT() and immediately resets the native device. The smoke suite observes a real D24S8 surface after manager-driven setup, so this is more than a stored field.

D3D11 and D3D12 ignore all three renderer arguments. Their windowed swapchains are fixed R8G8B8A8 UNORM and their default depth attachments fixed D24S8, even when public state says Depth24 or None. Shared SDL code may still enlarge the containing window for fullscreen. Both CreateSwapChainForHwnd calls omit a fullscreen descriptor, and neither renderer calls DXGI SetFullscreenState; their exclusiveFullscreen_ fields remain false. D3D12’s HeadlessEXT route is a third case: no window means no swapchain and no default depth attachment at all. It can render only into explicitly-created targets.

These distinctions prevent two tempting overclaims. D3D9’s enum mapping is not a guarantee that every mapped format is a legal display mode; failed native reset can leave the previous attachments active while public state has already changed. And an SDL fullscreen window on D3D11/12 is not DXGI exclusive fullscreen. The inherited fourteen-product comparison and test boundary are in §19.2.5.

The D3D11 3D checks form a progressively discriminating GPU-readback ladder. The first uses the stride-16 VertexPositionColor path: a known blue clear was read back, an NDC-space opaque-red triangle was then drawn through both indexed and non-indexed calls, and the same region had to become red. That proves the input layout, shaders, constant buffer, primitive topology, rasterization, and readback path together; a stale clear or an unbound shader cannot pass it accidentally.

The next rung separated texture sampling from vertex-color modulation. A stride-20 textured draw sampled a known texel exactly, through both indexed forms, while the stride-24 variant multiplied a known vertex color through a white texture and read back that exact color. The stride-32 lighting path then exercises the per-light constant buffer: its unlit control is byte-exact, while its lit control must differ from both the unlit result and the clear color. That deliberately avoids pretending a hand-derived GPU floating-point result is more stable than it is, while still distinguishing execution of the lighting branch.

Later tests applied the same discipline to features whose happy paths look deceptively similar. Fog draws the same geometry with the flag off (exact vertex red) and at the fog end (exact fog green); an environment-map fixture constrains the reflection to the cube’s -Z face; and a skinned fixture supplies an identity bone instead of an all-zero default matrix. These fixtures falsify different failure modes. At the pin, the D3D11 smoke executable contains 147 checks exercised through Wine and DXVK GPU execution. The result supports the specific paths named here; it is not a license to extrapolate that any arbitrary, untested D3D11 state combination must therefore be correct.

D3D9 and D3D11 take the simplest possible immediate route. Their public setters call the corresponding native viewport and scissor setters; their rasterizer mapping separately controls scissor enable. Neither SpriteBatch implementation replaces those native rectangles, and both derive their 2D projection size from the currently-bound native viewport. D3D11 Smoke Check O reads the exact native viewport, depth range, and scissor back through the corresponding native getters. That is strong native-state evidence but still one layer short of a public behavioral pixel test because the check invokes renderer methods directly.

D3D9 implements both states, but its evidence label needed correction. The renderer plan now calls viewport and scissor “oracle-proven.” A direct recount/search of the current 39-scene tools/xna-oracle/scenes corpus finds cull-mode scenes but no viewport or scissor scene, and the D3D9 smoke program’s resize check proves a full-size post-reset viewport, not a custom sub-region. The safest current claim is therefore native-source implementation plus broad D3D9 draw coverage, not a zero-tolerance XNA comparison for these two states.

D3D12 now splits the two states. Its SetViewport() override stores rectangle and depth range, and every ordinary, extended, instanced, and SpriteBatch command list obtains that value through GetEffectiveViewportEXT(). The getter clamps depth to $[0,1]$ and falls back to the current full target only when no positive custom rectangle is active. SpriteBatch also uses the same effective width and height as its projection basis, so coordinates remain local to the sub-viewport rather than being transformed twice. A native off-screen GPU check distinguishes inside/outside pixels, two custom rectangles in successive draws, depth-range behavior, and the full-target reset on a target switch. Scissor remains the negative half: there is still no rectangle hook, scissorTestEnable is not part of the PSO, and every draw installs a full-target D3D12_RECT. The complete product comparison is §19.4.3.

D3D11 immediately clears every bound RTV and selects the native depth and stencil clear bits independently when a DSV exists. D3D12 mirrors that selection with synchronous command lists. Both have strong direct-renderer proof: stencil-plane bytes are read back from the GPU, changed to a second value, and depth is distinguished by whether one identical triangle passes. Those tests bypass GraphicsDevice’s public route, but the route now derives depth and stencil availability independently from the bound 2D/cube attachment instead of inferring stencil from every non-None depth enum. D3D12 still requires a bound colour resource before its combination helper can record any command list; once one is bound, however, a requested depth/stencil aspect with no DSV is deliberately a legal no-op, matching D3D11.

D3D9’s native IDirect3DDevice9::Clear bits are likewise immediate and individually selected, but their final gate consults depthStencilFormatOrdinal_, the presentation format captured for the backbuffer. Binding a differently-formatted 2D or cube target never updates that field. A target can therefore lose a depth clear when the backbuffer has no depth, or receive a stencil bit selected because the backbuffer has one. The smoke test’s seven public combinations all use a D24S8 backbuffer and mostly check colour preservation, so they cannot reveal this mismatch. See §19.4.2 for the corresponding thirteen-product contrast within that audit cohort.

The repeated phrase “GPU readback” in this chapter names several different mechanisms. D3D11 has a ReadBackbuffer() override: it always copies backBufferTexture_ into a staging texture, honors RowPitch, and backs the public GraphicsDevice::GetBackBufferData() route with exact windowed clear/draw tests. It does not redirect to a currently bound render target.

D3D12 has no corresponding override. A public backbuffer call reaches IGraphicsRenderer’s default runtime_error on a windowed device, while HeadlessEXT has no swapchain to read in the first place. The D3D12 smoke suite’s many exact GPU pixel assertions call its working render-target-resource readback helpers directly; the shared public SpriteBatch example below likewise reads the off-screen render target, not GetBackBufferData(). Those results prove the named draw/resource path but cannot be quoted as evidence for a public backbuffer bridge that does not exist. The complete renderer matrix and FNA contrast are in §19.2.6.

Unlike the driver-managed D3D11 model, D3D12 makes the command allocator lifetime explicit. CNA therefore creates exactly two ID3D12CommandAllocator objects (kFramesInFlight = 2), one reusable graphics command list, one shared ID3D12Fence, and one remembered fence value per allocator slot. The essential operation, SignalAndWaitForFrameEXT(frameIndex), deliberately has a slightly counter-intuitive ordering: it signals a new, monotonically increasing value for the frame just submitted, then waits only for the previous value recorded for that same slot before allowing its allocator to be reused. Thus a call for slot 0 may submit value v2 while waiting for older v0; it must not wait for v2 itself, because doing so would erase the overlap the two slots exist to permit.

The smoke test invokes the primitive for slots 0, 1, and 0 again, verifies that v0 < v1 < v2, and, on the second use of slot 0, requires GetCompletedValue() to have reached v0. It intentionally does not assert that v2 has completed on return: ID3D12CommandQueue::Signal() is asynchronous, so that would be a race, not a correctness condition. A separate explicit event wait establishes eventual completion. The test also places 48 64-MiB GPU copies ahead of the old fence and comparing that wait with an already-complete control wait; the loaded wait is measurably slower, establishing that WaitForSingleObject() supplies back-pressure.

The reusable two-slot primitive is directly tested, but the current ordinary clear/draw helper uses ExecuteCommandListAndWaitEXT(), its intentionally simpler synchronous sibling: it submits a closed list, signals a fresh fence value, and waits for that value before returning. Present() likewise uses that synchronous helper for its explicit back-buffer transition before calling IDXGISwapChain3::Present(). Consequently a “Two frames in flight” therefore describes tested infrastructure and the allocator-reuse rule; it does not claim that current ordinary CNA drawing overlaps two CPU frames. The off-screen test paths retain a deterministic readback boundary.

Render-target, depth-stencil, shader-resource, and sampler descriptors come from four separate heaps; their current allocators are fixed-capacity, monotonically advancing bump allocators, not a general free-list. A destroyed resource does not return its descriptor slot during the device’s lifetime, and exhaustion throws a named std::runtime_error instead of silently aliasing another resource’s view. The capacities in the live renderer — 64 RTV, 8 DSV, 64 CBV/SRV/UAV, and 16 sampler descriptors — are therefore engineering limits of this implementation, not Direct3D 12 limits. Destroying many transient resources can therefore exhaust a descriptor heap even when GPU memory has been released; callers cannot assume unlimited descriptor churn during one device lifetime.

Swap-chain creation under plain Wine (as opposed to a Proton-managed launch) crashes outright, reproduced twice with a full symbolized backtrace pointing to a null-pointer read inside Wine’s own dxgi.dll. The cause is external to CNA: a mismatch between Debian’s own system dxgi.dll and vkd3d-proton’s separately overridden d3d12.dll — two DLLs that were never meant to be paired this way. Once launched through Proton, which supplies the matched DLL pair expected by vkd3d-proton, swapchain creation and a ten-frame clear-and-present loop through a window succeed in two runs.

Earlier D3D12 documentation listed runtime state objects, sixteen-slot sampler state, public 2D and cube render targets including MRT, Texture3D, and TextureCube::GetData() as open. They are implemented at the pin. The live tracking file remains the authority for revisions after this edition.

Both implementations store public uniform writes in the same 128-byte block. The caller’s name argument is deliberately ignored. What selects a value is which setter was called:

There are two further consequences that the common public surface does not make obvious. SetUniformFloatArray() and SetUniformVec2Array() inherit IEffectRenderer’s no-op defaults on both renderers. So do all three SetTexture() renderer hooks. The sprite’s primary resource still works because SpriteBatch itself binds its texture and sampler to t0/s0; a second 2D texture, cube map, or volume texture set through ShaderEffect does not. Effect authors should therefore treat the layout above as a tiny fixed ABI, not as name-reflected HLSL constants.

D3D11 can bind the compiled vertex shader, pixel shader, input layout, and dynamic constant buffer as separate context state. Every Bind() performs a write-discard map, copies the 128 bytes, and attaches the buffer to b0 for both shader stages. The native map mode is D3D11_MAP_WRITE_DISCARD.

D3D12 has no equivalent independent shader bind. Its effect constructor must build a complete ID3D12PipelineState up front, using the same cached root-signature shape as the stock sprite path: one CBV at b0, one SRV table at t0, and one sampler table at s0. The 128-byte constant buffer lives in a persistently mapped upload resource; Bind() only copies the current values, while D3D12SpriteBatchRenderer::FlushBatch() binds the resource and the prebuilt PSO inside its command list.

That PSO also makes D3D12’s boundary stricter and directly visible in source: it is compiled for one DXGI_FORMAT_R8G8B8A8_UNORM, single-sample color target, with blending, depth, and stencil disabled and culling set to none. Those choices match the custom-effect pixel test. They do not form a dynamic promise that the same object can be reused for an MRT set, an MSAA target, another color format, or caller-selected pipeline state; those dimensions would require separate PSOs and a cache key that the current effect renderer does not build.

The two smoke tests use byte-for-byte equivalent HLSL to turn a solid red texture into exact cyan. The vertex shader’s vpSize field is at byte zero because the renderer fills it; the four padding vectors advance the next public vector slot to byte 80:

D3D11 runs this through a windowed Wine/DXVK device and reads the sprite’s top-left region. D3D12 runs the same public GraphicsDevice/SpriteBatch sequence against a HeadlessEXT off-screen device, then reads the render target. In both cases solid $(255,0,0,255)$ must become exactly $(0,255,255,255)$. That result proves more than successful compilation: the fixed input layout, automatic viewport slot, b0 constant-buffer/root binding, t0/s0 resource path, custom pixel shader, and GPU readback all participated in one observable public-API draw.

Neither D3D11_RESOURCE_MISC_TEXTURECUBE nor a D3D11_SRV_DIMENSION_TEXTURECUBE view can ever be multisampled, and D3D12’s equivalent D3D12_SRV_DIMENSION_TEXTURECUBE has no multisampled variant either — so on both renderers, the MSAA color resource becomes a plain, non-cube six-slice Texture2DMSArray used only as a render-target view, while a second, single-sample, cube-flagged resource receives ResolveSubresource() on unbind. The shader-resource view targets the resolved resource. D3D12 additionally requires two explicit resource-barrier transitions (RESOLVE_SOURCE on the color resource, RESOLVE_DEST on the resolve target) that D3D11 does not need at all — its context-level ResolveSubresource() call handles the equivalent state transition implicitly. Both renderers resolve only the currently active face on unbind, the same one-face-at-a-time convention their mip-chain handling follows. On both renderers, an $8\times 8$ cube face requested at 4x MSAA is cleared, resolved, and read back exactly; GetMultiSampleCount() must also report four.

After drawing one cube face, D3D11 calls ID3D11DeviceContext::GenerateMips() on a shader-resource view spanning all six faces. The GPU regenerates every face’s chain; unchanged level-zero faces reproduce their prior mips. D3D12 has no corresponding convenience operation. Its GenerateMipsEXT() reads the active face’s preceding level through ReadbackSubresourceRGBA8(), box-filters it on the CPU, and uploads the next level with UploadSubresourceRGBA8(). It repeats this round trip for each level of that face. Both routes produce the required chain, but their synchronization and cost differ substantially. Shared bytecode and state mappings do not imply a shared resource algorithm.

D3D11 and D3D12 now override the cube-face route and retain the active cube separately from the single-2D and MRT state. Before any cube-to-cube, cube-to-2D, cube-to-MRT or cube-to-backbuffer transition, FlushPendingCubeResolveEXT() clears that tracking pointer and calls the outgoing cube’s UnbindAsRenderTarget(). That ordering is important: the callback performs the active-face MSAA resolve and mip generation before the new destination replaces native state. The plural normalized-descriptor path recognizes a single cube face and delegates to this same route; cube faces in a multi-target set remain an explicit renderer rejection rather than being silently treated as 2D targets.

The original direct smoke checks still prove the two low-level algorithms described above, but they are no longer the only evidence. Shared GraphicsDevice fixtures now drive an asymmetric rendered cube face through public binding and readback, rebind it for the usage test, and isolate preserved multisample content across two faces. Those fixtures make a skipped finalization, wrong face/subresource, stale resolve or false preservation visibly fail. Thus the former caution remains a useful account of how the hole escaped an implementation-local smoke test, not a current feature limitation.

The first routine public-device tests exposed four corrected D3D12 defects:

• •

  SpriteBatch ignored sampler filter and address-mode updates, inheriting state from a prior 3D draw;

• •

  render targets failed to bind their depth-stencil views;

• •

  the six combined color/depth/stencil clear variants threw; and

• •

  SetDepthTestEnabled, SetDepthWriteEnabled, and SetBlendEnabled threw when the Model route called them.

All four are fixed at the pin. Their discovery also shows why direct renderer smoke tests and public GraphicsDevice fixtures are complementary: the former had not traversed these shared-framework call paths.