fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: GPU trace attempt produced nothing -- and the config dump is not the flags

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-29 03:05:03 +00:00
parent 81625e8f29
commit 5b51c734fc
2 changed files with 65 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/re/METHOD.md
View File

@@ -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.

46
docs/re/capture-harness-status.md
View File

@@ -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.