swapchain-resource-analysis

Swapchain and Resource Analysis

Use this skill when the target pass/resource is not proven yet, especially when work starts at final presentation, swapchain output, backbuffer format, or a suspected resource bottleneck. The goal is to trace the render pipeline far enough backward to find real scene/HDR data, prove where destructive SDR mapping happens, and decide whether the fix is shader replacement, resource upgrade, SwapChainPass/output-format work, UI separation, or rejection of a postprocess-only approach.

Related skills and scope

Do not duplicate setup or shader-math workflow here. Capture only the facts those workflows need.

Core principle: RenoDX is not inverse tonemapping

RenoDX mods should not be framed as "take the finished SDR frame and inverse-tonemap it." That is the postprocess class of tools such as Microsoft AutoHDR, RTX HDR, and generic ReShade FX filters. Those methods guess missing HDR after the game has already compressed/clipped/graded the image.

RenoDX should instead preserve or recover a real upstream signal:

scene HDR / pre-tonemap composite
-> game exposure, bloom, fades, presentation effects
-> SDR tonemap or hard clip
-> optional LUT/color grade
-> UI/video/composite
-> final output encode / swapchain

The preferred RenoDX target is before the destructive SDR step, or at a shader that still receives the upstream signal plus an SDR reference. A final swapchain pass is only a valid target when it still has access to the HDR/pre-SDR resource, handles final color-space/output encode, or is used for verification/UI separation. It is not valid when it only reads the completed SDR backbuffer.

HDR upgrade model

Treat HDR upgrade work as preservation of range and gamut through the game's real pipeline, followed by an intentional output conversion.

Neutral output is the baseline. Resource upgrades, proxy paths, and swapchain color-space changes should preserve the original SDR art direction while removing proven range/precision limits. Default settings should match the original look as closely as practical. They should not create a default "HDR look" by increasing contrast, saturation, or colorfulness; visual augmentation belongs in explicit sliders or named presets such as HDR Look. Rare exceptions need explicit user intent and validation evidence.

Use this model to decide whether the mod needs a shader replacement, a resource format upgrade, a swapchain proxy path, or all three.

Boundaries

• Focus on DevKit draw/resource/swapchain analysis, render-target format decisions, and resource-upgrade planning.
• Use this before handle-sdr-tonemap-lut when the shader capture point is unknown or when a final-output hack is being proposed.
• After a shader-side tonemap/LUT target is proven, switch to handle-sdr-tonemap-lut for HLSL/Slang math.
• Keep setup/build/link details in setup-game-mod-dev unless they are directly needed to prove resource behavior.
• Do not create a RenoDX strategy that only inverse-tonemaps the final SDR swapchain image.
• Do not treat a fullscreen pass as "the tonemap" until draw inputs prove whether it receives HDR scene data, SDR color, UI, video, or an encoded output.

Expected output from this skill

Produce these sections:

1. Pipeline classification - final output format, swapchain color space, final blit/composite, tonemap/LUT/UI/video positions.
2. Format/proxy plan - RGBA8U bottlenecks, RGBA16F/proxy needs, final SwapChainPass/RGB10A2/PQ or scRGB output path.
3. Resource chain - relevant resources/views, formats, bind flags, copies/resolves, and where values are clipped or preserved.
4. HDR source proof - draw/resource evidence for the last usable pre-SDR signal and why it is not merely final SDR output.
5. Target decision - shader replacement, resource upgrade, SwapChainPass/output encode, UI separation, or explicit rejection.
6. Handoff plan - exact shader/resource facts to pass to handle-sdr-tonemap-lut or C++ addon work.
7. Verification checklist - captures, resource readbacks, format checks, UI/video checks, and final HDR output validation.

Step 1: Classify the final output path

Start at presentation, but use it as a map anchor rather than the default mod target.

If the final draw only samples an SDR/UNORM post-tonemap color buffer, do not design an inverse-tonemap mod from that point. Continue backward.

Step 2: Work backward through draws and resources

Use DevKit snapshots, draw details, and resource analysis to map the chain from swapchain to scene composite.

1. Inspect the last frame draws first, then step backward through fullscreen passes.
2. For each candidate draw, record:
   • shader hash and stage;
   • input SRVs/UAVs and output RTV/UAVs;
   • resource/view format, dimensions, mips, array slices, and bind flags;
   • whether the resource is copied, resolved, cleared, or reused later;
   • blend state and color-write masks.
3. Analyze resource contents before and after suspected destructive passes.
4. Prefer evidence from values/ranges, formats, and shader math together; a resource name or fullscreen triangle alone is not proof.
5. Stop only when you can identify the last useful pre-SDR signal or prove that the game no longer exposes one without earlier resource upgrades.

Useful proof signs for an upstream HDR source:

• float or high-range formats carrying values above SDR white before clamp/encode;
• shader math with exposure, bloom, scene color, or known filmic/hard-clip behavior;
• a later pass clamps/saturates, applies a tone curve, samples a LUT, or writes to UNORM;
• UI/HUD is absent from the candidate source and composited later;
• changing scene exposure/bloom affects the candidate in a physically plausible way instead of merely stretching final SDR pixels.

Step 3: Identify destructive SDR operations

Classify where information is lost. This determines whether shader replacement is enough or resource upgrades are required.

Step 4: Choose a valid RenoDX target

Use the narrowest target that preserves real upstream data.

The final swapchain pass can be edited only if draw inputs prove it is still part of the real game pipeline. A pass that reads a completed SDR frame and applies an inverse curve is not a RenoDX tonemap replacement.

For new game mods, prefer an HDR10/PQ output path with an SDR/HDR toggle. The internal render/proxy path may still use RGBA16F or similar resources to preserve HDR-critical values, but that does not mean the public output mode should default to scRGB. Treat scRGB as a rare output choice for specific compatibility or integration needs.

Swapchain proxy conversion checklist

Use a swapchain proxy/output shader only after the resource chain proves a high-precision signal survives to that point.

Swapchain proxy pixel shader snippet shows the intended thin SwapChainPass shape. Treat it as a starting point after proof, not as evidence that final SDR output is a valid HDR source.

• Prefer renodx::draw::SwapChainPass(...) in the proxy pixel shader when the final pass is just the shared output conversion for a proven intermediate signal.
• Drive SwapChainPass with a compact injected preset when the mod exposes an SDR/HDR output mode. In current shared shader code the preset mapping is -1 none, 0 SDR, 1 HDR10, 2 scRGB; prefer named constants/macros over raw numbers when editing shader code.
• Prefer the HDR10 preset for HDR mode and the SDR preset for SDR mode. Use the scRGB preset only when a concrete compatibility or integration requirement needs it.
• Treat HDR10 swapchain selection as a facilitator for the feature, not proof that the frame is HDR. Coordinate target format, DXGI color space, SwapChainPass preset, and user output mode together.
• For an SDR/HDR toggle on an HDR10-capable path, the SDR mode may still use the upgraded/proxy machinery but should select the SDR preset and SDR color space; HDR mode should select the HDR10 preset and HDR10 color space.
• For a scRGB path, select the scRGB preset and extended linear color space when the target format/proxy path is float/scRGB-compatible.
• Prefer a RGBA16F or equivalent proxy/intermediate for HDR-critical rendering when RGBA8U would clip values or quantize gradients.
• Do not require a floating-point swapchain just because the working pipeline is floating-point; the proxy can encode into RGB10A2/PQ HDR10 or linear scRGB at the end.
• Preserve the game's expected gamma or sRGB-domain behavior where practical, then handle known gamma mismatches in the final proxy/output shader.
• Convert deliberately to the final display representation: linear scRGB for wide-gamut linear HDR paths, or PQ/HDR10 for HDR10 paths.
• Keep the proxy shader focused on format/color-space encoding and final scaling. Do not hide a final-SDR inverse tonemap inside it.
• Verify whether UI/HUD/video are already composited into the proxy input; if so, separate or independently scale them before final output when possible.

Output preset and color-space synchronization

When a mod supports an SDR/HDR output toggle, the swapchain state and shader preset must move together.

Prefer a cbuffer-driven preset for per-frame toggles because it is cheap, works with one proxy shader, and can be updated from OnPresent after the mod knows the current user output mode and swapchain target. Avoid baking the user's SDR/HDR choice into static shader variants unless the game already requires separate output shaders.

Swapchain output sync snippet shows the C++ runtime pattern used by high-quality addons: update the injected output preset and queue the matching swapchain color space together during presentation.

Keep SwapChainPass work here scoped to output conversion and runtime state synchronization. If the next task is changing a proven game tonemap/LUT shader, hand off to handle-sdr-tonemap-lut; if the next task is wiring the addon/build/deploy path, hand off to setup-game-mod-dev.

Step 5: Plan resource upgrades carefully

When the analysis proves a format/resource bottleneck, plan addon work around the actual resource lifetime.

• Upgrade every relevant create/copy/resolve alias in the chain, not just the final view that looked clipped.
• Preserve dimensions, mips, arrays, sample count, bind flags, clear values, and typeless compatibility unless the change is required and verified.
• Track SRV/RTV/UAV view formats separately from resource formats.
• Verify barriers/states and copy paths still make sense after a format upgrade.
• Confirm the upgraded format actually preserves values above 1.0, negative channels when needed, and reduced banding through the relevant post-process chain.
• Re-check all consumers of the upgraded resource, especially UI/video/composite passes that may expect SDR or UNORM.
• Use clone/hotswap only as a DevKit proof; move proven upgrades and shader registrations into the game addon before treating the mod as real.
• Capture original and upgraded resource outputs at the same draw before judging the visual result.

Step 6: Handoff to shader-side tonemap/LUT work

Once a shader target is proven, pass these facts into handle-sdr-tonemap-lut:

If any of these facts are missing because the only known signal is final SDR output, continue resource analysis instead of inventing an inverse.

Validation checklist

• Prove the candidate source with resource readback before replacement.
• Compare original vs baseline replacement at the same draw before custom HDR changes.
• Show where values above SDR white exist or explain why resource upgrade is required to preserve them.
• Show whether the chain needs negative-channel support for wider-gamut output or only luminance headroom above 1.0.
• Verify UI/HUD/video/menu paths do not get unintended inverse-tonemap expansion.
• Verify any proxy/output shader performs only intentional gamma/scRGB/PQ conversion and final scaling.
• Verify the default output remains neutral against the vanilla SDR reference; extra contrast/saturation must be opt-in through sliders or named presets, not baked into the resource/output path.
• Verify the SDR/HDR toggle updates both the injected output preset and the swapchain color space/target state.
• Verify scene highlights respond to game exposure/bloom/settings as upstream data, not as final-frame heuristics.
• Verify the final swapchain/output mode and color space match the selected RenoDX mode.
• Document any rejected final-only approach explicitly as "not RenoDX; postprocess inverse tonemap class."

Common anti-patterns

Committed RenoDX swapchain examples

Use these as references for concepts, not copy-paste templates.

Useful references

• docs/DEVKIT_MCP.md - DevKit/MCP draw, shader, and resource inspection workflow.
• setup-game-mod-dev - local build, DevKit, game-folder link, dump/decompile, and baseline setup.
• handle-sdr-tonemap-lut - shader-side RenoDRT/PsychoV/LUT bridge once a valid target is proven.