From 921a3cfc44259310b8c87ff1b6016459cb0c822a Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sat, 29 Aug 2026 03:05:03 +0000 Subject: [PATCH] re: GPU trace attempt produced nothing -- and the config dump is not the flags Tried to turn the gamma-ramp inference into a direct observation. canary's trace_gpu_stream records gamma ramps as their own command type (kGammaRamp, index 11 in TraceCommandType), so a boot trace should show the write. Two bounded runs produced NO trace file at all -- nothing under the prefix, no .xtr anywhere, no scratch/gpu/. Bounded deliberately: the disk is at 95% (50 GiB free) and a trace of all GPU packets during boot includes video decode, so the runner carried its own watchdog that killed the emulator the moment output passed a 2 GiB cap. It never fired -- there was nothing to cap -- and disk stayed at 95% throughout. Bounding from inside cost nothing and removed any need to gamble on how coarsely I could poll. What the attempt did establish. BeginTracing() runs at GPU init when the cvar is set (graphics_system.cc:237), but EndTracing() runs only from GraphicsSystem::Shutdown() -- so the kill -9 this session has used routinely can never finalise a trace. The second run was stopped with SIGTERM and exited cleanly; still no file, so that is not the whole story. Two candidates remain unseparated: the CLI flag not reaching the cvar, or BeginTracing failing silently. The next run removes the ambiguity by setting trace_gpu_stream in the config FILE instead. And a trap I nearly fell into. The startup config dump showed trace_gpu_stream = false after I passed --trace_gpu_stream=true, which reads as "flag ignored". It is not evidence either way: the gamma run passed --log_mask=12 --log_level=3, its dump printed log_mask = 0 and log_level = 2, and Kernel Debug logging was demonstrably ON -- that run is where VdGetCurrentDisplayGamma was captured. The dump reflects the config file and can neither confirm nor refute a command-line override. (It does not undo the earlier user_language conclusion: absence of a NAME from the dump still shows a cvar is unregistered.) The gamma-ramp write therefore remains an inference, unchanged. --- docs/re/METHOD.md | 19 +++++++++++++ docs/re/capture-harness-status.md | 46 +++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index e51ec7f..de16640 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -644,3 +644,22 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the which is the one step that could be wrong. Writing that down beside the conclusion — rather than only the supporting facts — is what lets a later reader attack it instead of inheriting it. +* **The startup config dump is the config FILE, not the effective flags.** A run + passed `--log_mask=12 --log_level=3` and its dump printed `log_mask = 0, + log_level = 2` — while Kernel Debug logging was demonstrably on, which is how + that run's finding was obtained. So a dump can neither confirm nor refute a + command-line override, and reading one as "my flag was ignored" is a mistake I + nearly made with `trace_gpu_stream`. Verify a flag by its *effect*, not by the + dump. (This does not undo the earlier `user_language` conclusion: absence of a + *name* from the dump still shows the cvar is unregistered.) +* **`kill -9` destroys anything that finalises on shutdown.** Canary starts a GPU + trace at init but only closes it in `GraphicsSystem::Shutdown()`, so the hard + kills this session used routinely could never have produced a trace. Before + concluding a feature is broken, check whether the way you stop the program is + what discards its output. +* **Bound a risky experiment from inside, not by watching it.** A boot-time GPU + trace on a disk at 95 % could have filled it between two tool calls. The runner + carried its own watchdog that killed the emulator the moment the output passed + a 2 GiB cap, so the experiment was safe regardless of how coarsely I polled. + The watchdog never fired, which is the point — it cost nothing and removed the + need to gamble on timing. diff --git a/docs/re/capture-harness-status.md b/docs/re/capture-harness-status.md index 2d94b0e..f307993 100644 --- a/docs/re/capture-harness-status.md +++ b/docs/re/capture-harness-status.md @@ -279,3 +279,49 @@ The two open items that need a running menu — the gamma control on a well-characterised and instrument-verified failure rather than on a suspicion. Neither blocks the five menu screens. **Returning to static work**; the probe is committed for whoever picks this up. + +--- + +## ❔ The GPU trace route: attempted, produced nothing, characterised + +**2026-08-29.** To turn the gamma-ramp *inference* into an observation, canary's +`trace_gpu_stream` should work — it records gamma ramps as their own command type +(`kGammaRamp`, index 11 in `TraceCommandType`). Two bounded runs produced **no +trace file at all**: nothing under the prefix, no `.xtr` anywhere, no +`scratch/gpu/`. + +Bounded deliberately: the container's disk is at **95 % (50 GiB free)** and a +boot-time trace of all GPU packets includes video decode, so the runner carried a +watchdog killing the emulator the moment the trace passed a 2 GiB cap. It never +fired — there was nothing to cap. Disk was unchanged at 95 % throughout. + +What the attempt did establish: + +* `BeginTracing()` is called at GPU init when the cvar is set + (`graphics_system.cc:237`), but `EndTracing()` runs only from + `GraphicsSystem::Shutdown()`. **A `kill -9` — which this session has used + routinely — can never finalise a trace.** The second run was therefore stopped + with `SIGTERM` and exited cleanly. Still no file, so that is not the whole + story. +* Two candidates remain and were **not** separated: the CLI flag not reaching the + cvar, or `BeginTracing()` failing silently. + +**The next step is one run and removes the ambiguity:** set +`trace_gpu_stream = true` in `xenia-canary.config.toml` itself rather than on the +command line, and stop with `SIGTERM`. If a trace appears, the CLI path was the +problem; if not, `BeginTracing` is. + +## ⚠️ The config dump in a log is the FILE, not the effective command line + +Nearly a wrong conclusion here. The dump printed at startup showed +`trace_gpu_stream = false` after I had passed `--trace_gpu_stream=true`, which +reads as "the flag was ignored". It is not evidence either way: + +| | passed on the CLI | shown in the dump | actual behaviour | +|---|---|---|---| +| gamma run | `--log_mask=12 --log_level=3` | `log_mask = 0`, `log_level = 2` | **Kernel Debug logging demonstrably ON** | + +The gamma run's flags plainly took effect — that run is where +`VdGetCurrentDisplayGamma` was captured — while its dump showed the file's +values. So the dump reflects the config file and cannot confirm or refute a +command-line override.