hitobject-invoke-after-recursion-cap
Status: stub. The full-length analysis is queued for a v1.0.x patch release per ADR 0018, section 5, criterion #6. The companion rule page at docs/rules/hitobject-invoke-after-recursion-cap.md contains the canonical detection logic + GPU reasoning.
TL;DR
The DXR pipeline's D3D12_RAYTRACING_PIPELINE_CONFIG.MaxTraceRecursionDepth declares an upper bound on how deep the trace stack can grow. The runtime uses this bound to size the per-lane ray stack, which is shared between TraceRay-style recursion and HitObject::Invoke-style deferred invocation. On NVIDIA Ada Lovelace, AMD RDNA 3/4, and Intel Xe-HPG (with the OMM extension), exceeding the declared depth at runtime is undefined behaviour: the hardware may corrupt adjacent stack frames, fault, or silently truncate.
What the rule fires on
A dx::HitObject::Invoke(...) call reachable from a closest-hit shader chain whose nominal recursion depth exceeds the pipeline's MaxTraceRecursionDepth. The Phase 4 call-graph + recursion-budget analysis walks the trace chain (raygen -> closest-hit -> potentially another Invoke -> closest-hit -> ...) and accumulates the depth.
See the What it detects section of the rule page for the full pattern definition.
Why it matters
The full GPU-mechanism analysis lives in the Why it matters on a GPU section of the companion rule page.
Examples
The bad / good code snippets are kept canonical on the rule page; see hitobject-invoke-after-recursion-cap.md -> Examples.
See also
- Rule page -- canonical reference + change log.
- ser overview -- broader context.
- ADR 0018 -- v1.0 readiness plan.
This is a v1.0-ship stub. Full analysis pending; track issue link TBD.