fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues 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 421c61a517
commit 921a3cfc44
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 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 conclusion — rather than only the supporting facts — is what lets a later
reader attack it instead of inheriting it. 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 on a well-characterised and instrument-verified failure rather than on a
suspicion. Neither blocks the five menu screens. **Returning to static work**; suspicion. Neither blocks the five menu screens. **Returning to static work**;
the probe is committed for whoever picks this up. 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.