diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 22ac327..507d53a 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -237,9 +237,14 @@ authored version can be deleted. ramp from the `DC_LUT` registers in the swap path (`apply_gamma_table.ps` / `apply_gamma_pwl.ps`). So there is no emulator post-process to subtract, and any gamma in a capture is one the game installed. - 🟡 Still not established: that this game installs a ramp at all, or that - γ ≈ 1.4 *is* it. The run logs cannot say — kernel exports log at Debug and the - harness masks Kernel logging — so that absence means nothing. + ✅ **Measured 2026-08-29: the game DOES query the display gamma.** Booted with + Kernel logging on (`--log_mask=12 --log_level=3`, which changes nothing about + the output), `VdGetCurrentDisplayGamma` is called once at video init, between + `VdGetSystemCommandBuffer` and `VdSetDisplayMode` — the moment a ramp-builder + would ask. Control in the same log: 359 `VdRetrainEDRAM` lines, so an absent + call would have shown. + 🟡 Still open: whether it then *writes* the ramp, and whether γ ≈ 1.4 is it. + That write is a GPU register operation (`DC_LUT`), invisible to kernel logs. ⚠️ Note the ramp depends on the display type the game is *told*; canary hard-codes TV/BT.709, which on hardware is a console setting. **So this is a display profile, not a fixed property of the game** — reasonable to expose as a diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index d4c5752..abc5c30 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -624,3 +624,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the this harness masks Kernel logging entirely (`log_mask = 13`), so their absence is guaranteed regardless of what the game did. Check the logging configuration before reading silence as a result. +* **Check what an experiment actually needs before filing it behind a blocker.** + The gamma question sat parked behind "needs the emulator to reach a menu" for + several iterations. It needed the emulator only to **boot** — video init, and + the `VdGetCurrentDisplayGamma` call, happen in the first seconds, long before + any title screen. A blocker that stops one experiment does not stop every + experiment in the same area, and it is worth re-reading the parked list against + what each item really requires rather than against the area it belongs to. diff --git a/docs/re/data/gamma-call-evidence.txt b/docs/re/data/gamma-call-evidence.txt new file mode 100644 index 0000000..1aa8670 --- /dev/null +++ b/docs/re/data/gamma-call-evidence.txt @@ -0,0 +1,9 @@ +# canary --log_mask=12 --log_level=3 (Kernel logging ON), 2026-08-29 +# control: the same log carries 359 VdRetrainEDRAM and 358 VdGetSystemCommandBuffer lines, +# so a missing call would have been visible. + + F 820006F4 8284E27C 1B9 ( 441) VdGetCurrentDisplayGamma + F 8200070C 8284E2BC 1BA ( 442) VdGetCurrentDisplayInformation + F 82000710 8284E2CC 1D3 ( 467) VdSetDisplayMode +d> F8000008 VdGetSystemCommandBuffer(701CF830, 701CF804) +d> F8000008 VdGetCurrentDisplayGamma(701CE1F8(00000000), 701CE1F0(0)) diff --git a/docs/re/structures/ui-render-tone-curve.md b/docs/re/structures/ui-render-tone-curve.md index 8b390b0..b4ffbc6 100644 --- a/docs/re/structures/ui-render-tone-curve.md +++ b/docs/re/structures/ui-render-tone-curve.md @@ -93,11 +93,31 @@ captured frame is a ramp **the game installed**. ✅ The stated confound is gone: the measured exponent is not an emulator artefact bolted onto the game's output. -🟡 **Not established: that this game installs a ramp at all**, or that -γ ≈ 1.34–1.49 *is* that ramp. The run logs cannot say — kernel exports log at -Debug and this harness masks Kernel logging (`log_mask = 13`, per -`boot_menu.sh`'s own comment), so the absence of gamma lines in them is expected -and means nothing. That is the reach of this negative. +✅ **The game DOES query the display gamma — measured 2026-08-29.** Booted with +`--log_mask=12 --log_level=3` (Kernel logging on, Cpu/Gpu off), which changes +nothing about the output. `VdGetCurrentDisplayGamma` is called **once at video +init**, between the command-buffer setup and `VdSetDisplayMode`: + +``` +d> F8000008 VdGetSystemCommandBuffer(701CF830, 701CF804) +d> F8000008 VdGetCurrentDisplayGamma(701CE1F8(00000000), 701CE1F0(0)) +d> F8000008 VdSetDisplayMode(40000000) +d> F8000008 VdGetCurrentDisplayInformation(701CF110) +``` + +**The control is in the same log:** 359 `VdRetrainEDRAM` and 358 +`VdGetSystemCommandBuffer` lines, so an absent call would have been visible. +Evidence in [`data/gamma-call-evidence.txt`](../data/gamma-call-evidence.txt). + +Per the export's own comment the returned type is "used in D3D +SetGammaRamp/SetPWLGamma", so the game asks the question a ramp-builder asks, at +the moment one would ask it. + +🟡 **Still not established: that it then WRITES the ramp**, or that γ ≈ 1.34–1.49 +is that ramp. The write is a GPU register operation (`DC_LUT`), invisible to +kernel logging — this run had Gpu logging masked off, and individual register +writes are not logged in any case. A GPU trace records gamma ramps as a command +type (`TraceWriter::WriteGammaRamp`), which is the next place to look. ⚠️ And the ramp a game builds depends on the display type it is *told*. Canary hard-codes `2` (TV/BT.709); on hardware that is the console's display setting. So @@ -116,6 +136,9 @@ on an **absolute** rmse threshold and a brighter frame biases it (see The right run changes nothing about the output: boot with `LOG_MASK=12 LOG_LEVEL=3` (both are needed — kernel calls log at Debug) and look for `VdGetCurrentDisplayGamma` and the `DC_LUT` writes. Same frames, no perturbation. +✅ **Run, and it answered the first half** — see above. ⚠️ And note it needed the +emulator only to **boot**, not to reach a menu: video init happens in the first +seconds. This had been parked behind the title-screen blocker for no reason. ## What a port should do with this