Unity submission fix and current GBV coverage

Read-only investigation, 17 September 2026, Europe/Vienna. No Editor, player, capture replay or GPU workload was started by this review. The only change from this review is this report. The crash cause remains unconfirmed.

UUM-120711: exact release evidence

Unity identifies a DX12 correction that moves BuildSubmissionData after EndRenderPassImpl() so submission data uses the current active command list. This is a native submission-state correction; the release note does not identify our shader, constant-buffer error or NVIDIA TDR as its symptom.

Release versions, dates and Markdown URLs were obtained from Unity's official release API. Sources: a7 notes, original b1 notes, 6.6.0 final notes, 6.6.1 delta notes, 6.3 releases API, 6.3.24 notes. The API-supplied Markdown is useful because requesting an older beta webpage can return the current beta notes instead.

The historical failed 6.6.0 run is documented in the earlier status and its original player log. Correction, 17 September: the user confirmed that Rampage66 has older content and reports that this copy does not crash in their use. Those historical logs do not constitute a content-matched current-project comparison. They cannot rule out an engine upgrade helping the current content; the earlier inference that another upgrade comparison was redundant is withdrawn. UUM-120711 remains a possible DX12-specific lead, not an established explanation of the independent D3D11 failures. No public issue page with additional reproduction details was established for this ID.

Fresh GBV attempts: prerequisites versus completed validation

The inspected candidate uses Unity 6000.3.24f1, build GUID 863b7c4dc60d4b53971aa9bc445b51e2, Direct3D12, RTX 4060 Laptop GPU, driver 32.0.16.1692, and the debug/GBV command flags. These attempts did not use RenderDoc.

The matching Microsoft signatures/core hash and local-only deployment are recorded separately in app-local-debug-layer.json. DLL loading is not equivalent to proving that SetEnableGPUBasedValidation(true) took effect before device creation. No runtime shader-compilation or CPU-stack evidence was captured in the two zero-callback attempts.

Microsoft documents that GBV instruments shaders and injects additional command-list work. Its default pipeline-state setting patches PSOs on their first use in a command list, potentially slowing command-list recording until a steady state is reached. Thus first-frame PSO instrumentation is a technically supported explanation for a long first render, but these logs do not establish that it consumed the elapsed 30/60 seconds, nor do they exclude a different wait or stall. Sources: GBV overview, pipeline-state creation flags.

GBV error output arrives after submitted work completes on the GPU. With no observed completed camera render, absence of messages cannot establish clean bindings. GBV also changes execution and is not a representative performance test. Microsoft's enablement API requires enablement before device creation; it must not be toggled on an existing device. No global DXCPL, registry, TDR, driver or OS setting change is proposed here.

The separate early RenderDoc capture is binding-structure evidence, not this missing GBV execution evidence. RenderDoc 1.46's app-facing debug wrapper does not forward SetEnableGPUBasedValidation; see its D3D12 hook implementation. The offline analyzer's declared/static operand bounds checks do not establish dynamic index values, executed branches, resource lifetime correctness or safety in later frames.

Later CPU evidence supersedes the missing-stack limitation for one additional run

The separately conducted 005021 run ended at its 180-second deadline with insufficient-render-coverage, zero recorded driver events and restored profiles. Its CPU analysis establishes work in the NVIDIA compiler during the instrumented first frame: the same UnityGfxDeviceWorker accumulated 78.375 seconds of user CPU across 84.109 seconds of wall time; a TID-selected deep stack passes through UnityPlayer, SDKLayers/d3d12, D3D12Core, NVIDIA's user-mode driver and nvgpucomp64. This is direct evidence of compiler-path CPU work for that additional run, beyond the generic explanation above. It does not identify the shader/PSO, prove successful compilation progress, produce GBV race coverage or explain the earlier uninstrumented driving failures. The 30/60-second runs themselves still lack these stacks.

Remaining application-side candidates and one useful comparison

The strongest unresolved content distinction is still billboard submission with reduced effects, rather than an unproven single shader defect. Read-only review of existing invocation manifests found this incomplete comparison:

The historical 182158 and 190406 commands both requested -rampageStabilitySeconds 600 -rampageStabilityQuality 2 -rampageStabilityCycles 20 -rampageStabilityStages alps-02,alps-03 -rampageGpuMinimalEffects -force-d3d11, with a visible 1920x1080 window. The latter additionally used -rampageNoBillboardShader. Neither used direct rendering, disabled SRP batching, Forward, the native-graph override or a fixed weather seed.

Source review gives the following practical limits:

• AlpineFirBillboards.cs builds ordinary MeshRenderers and cached materials. Native mode keeps the atlas, distribution and dimensions but replaces camera-facing deformation with three static planes per tree, enables material instancing and runs HDMaterial.ValidateMaterial. It changes more than a shader name and is not a pixel- or geometry-identical comparison. Suppression mode uses forceRenderingOff and retains meshes/materials/scene ownership, so its success is more informative about submission than a no-scenery test alone.
• AlpineGrassVerge.cs and DressingInstances in AlpineCanyonDressing.cs retain CPU-built GPU-instance submissions. The inspected batches are bounded at 256 with paired start/count ranges; no concrete out-of-range CPU submission or project-created constant-buffer binding was found. Their workload and interaction with other draws remain unexcluded; static array checks do not prove native GPU resource lifetime safety.
• GeneratedWorldResources destroys its explicitly owned generated resources; shared/imported source meshes are not registered by the inspected grass path. LoadRace disables the main camera, yields, destroys the previous world and yields before replacement. No demonstrated double-free or explicit invalid GPU fence was found. Continuous first-race failures and the alps-02 countdown TDR mean neither lap crossing nor repeated stage teardown is a necessary trigger.
• Main-camera Forward still retains HDRP light-list construction and other compute work; garage reflection capture has independent settings. Forward plus the managed native-graph flag off has already failed. The earlier NoGarageProbe reset and minimal-effects reset also prevent claiming that the garage probe or the disabled effect group is required for every crash. The paused NoGarageProbe run is a poor driving comparison but is still a real reset without that probe.

One bounded discriminating experiment, recommendation only: use the current candidate with the existing NativeBillboardsMinimalEffects selector, normal D3D11 submission, High, alps-02/alps-03 transitions, visible 1920x1080, at most 600 seconds/20 visits, and stop on the first GPU-reset event. This retains stock tree rendering while matching the reduced-effects side of the historical evidence. Do not add Forward, direct rendering, no-SRP or no-native-graph switches. The existing launcher parameter set is -DurationSeconds 600 -Cycles 20 -Scenario Transitions -StageIds alps-02,alps-03 -Quality 2 -GraphicsApi Direct3D11 -Isolation NativeBillboardsMinimalEffects -VisibleWindow, with an explicit current -PlayerPath. No such command was executed by this review.

A failure would show that the custom billboard shader and the suppressed effect group are not necessary for that failure. A pass would only prioritize the original billboard submission/deformation/material path or an effect interaction for a matched current-build comparison; it would not establish a full-graphics fix. Record current binary hashes, actual stock-material logs, effective isolation flags, camera coverage and OS events. Because of historical binary differences and stochastic failures, do not present one passing cell as proof of a unique cause. This evidence supports closing that specific comparison; it does not support another untargeted sequence of long rendering-switch tests.