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.

If this workflow reaches C++ addon planning, review, creation, or editing under src/, read docs/CXX_STYLE.md in full before that work. Analysis that does not touch C++ does not need to load the guide.

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.