Steps 2 and 3 (spirv-opt, spirv-dis) run subprocess without text=True, so
result.stderr is bytes -- and `sys.stderr.write(bytes)` raises TypeError. The
tool's real message is replaced by a Python traceback at exactly the moment you
need it.
Building in a clean container, the visible failure was:
ERROR: spirv-opt failed for guest_output_bilinear.ps.xesl
TypeError: write() argument must be str, not bytes
with the actual cause -- `Unknown flag '--canonicalize-ids'`, i.e. a SPIRV-Tools
too old -- never printed. Use .buffer.write, as compile_shader_dxbc.py already
does at the same site.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Taking phase_b_snapshot.{cc,h} as files from the snapshot branch left it
referencing three cvars that live in that branch's cpu_flags and were not
carried across, so the kernel library failed to compile:
phase_b_snapshot_dir / phase_b_snapshot_and_exit / phase_b_dump_section_content
Ported their DEFINE_/DECLARE_ pair verbatim. Also switched one
`std::filesystem::path base(...)` to brace init -- with a single named argument
that parses as a function declaration under a newer clang than the branch was
written against, and this tree builds with -Werror.
Verified on the linked binary: all fifteen instrumentation cvars from the three
merged lineages are present, and so is every output path the superset draw
logger emits (xenia_re_draws.log, xenia_re_shaders.log, xenia_re_files.log,
xenia_ship_capture_NN.log, with idx_raw / vsconst / psconst records).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
These were sitting in stash@{0} ("On canary_experimental: doc", 2026-04-11) as
untracked files only -- no tracked change was ever stashed with them, so they
were one `git stash drop` away from being lost:
docs/ppc_instructions.{json,md} PPC instruction reference
docs/xbox360_exports.{json,md} XAM / xboxkrnl export tables
docs/xex2_format.md XEX2 container format
tools/generate_export_docs.py the generator behind them
xex2_format.md in particular is the spec a static XEX reader would need to
pull the title's XACH achievement table and .rdata tables off the disc.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
auto/canary-instrumentation-snapshot-2026-07-28 was authored from a base 85
commits behind this line and re-adds the cross-build toolchain and the audit
probes as unrelated new files, so merging it conflicts in 15 places for no
gain. Everything it carries is already here except these eight, which exist
nowhere else:
- phase_b_snapshot.{cc,h} one-shot JSON state snapshot, fired from
the JIT before the entry thread's first
guest instruction (--phase_b_snapshot_dir)
- audit_68_host_mem_watch_{base.cc,fwd.h}
- audit_69_event_signal_watch.{cc,h}
- audit_70_semaphore_release_watch.{cc,h}
Its xboxkrnl_xconfig.h is unrelated to the instrumentation and unreferenced
here, so it is deliberately left behind. The branch itself is kept (its
commits are not ancestors of this one).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
GetOrCreate reads entry->status while holding the global critical region,
but ResolveFunction published compile results by writing entry->function,
end_address and status directly, with no lock held. Nothing establishes a
happens-before edge between the two, so a thread that observes
STATUS_READY can still read a stale entry->function -- which it does
unlocked, right after GetOrCreate returns.
Benign on x86's TSO in practice; reachable on AArch64.
Add MarkReady/MarkFailed, which publish under that same lock, and route
Processor through them.
ThreadSanitizer against the real EntryTable: 2 data races before, 0 after.
The race is undefined behaviour by definition; no torn pointer was
actually observed in those runs.
Reading guest RAM from outside the emulator is easy -- Canary backs it with a
/dev/shm file, so a host process can just pread it -- but it is UNSYNCHRONISED.
The reader has no idea where the guest is in its update, so successive reads are
separated by an unknown, jittering number of guest updates.
That is not a theoretical concern. Measuring the player craft's angular velocity
this way produced 3x swings between adjacent 0.25 s windows, which made it
impossible to tell "the rate ramps up after the stick goes over" from "the
sampler is aliasing" -- the one question standing between a confirmed law shape
and its absolute scale. Widening the window does not rescue it either: a hold
long enough to average bleeds the speed, and speed is the variable under test.
So sample from inside, in VdSwap: the guest's own thread, once per guest frame,
at a fixed point in it. Consecutive lines are then exactly one frame apart by
construction and the frame counter is exact.
Which bytes to sample is not known at launch -- object addresses are found by
scanning at runtime -- so the regions come from a small control file that is
re-read whenever its mtime changes, the same trick the file input pad uses:
0x40D10590 128 a guest VA and a byte count, one region per line
and each frame appends
F <frame> H <host_ns> G <guest_ticks> R0 <hex> R1 <hex> ...
Reads are bounds-checked through LookupHeap/QueryProtect and copied out before
printing, so an unmapped or stale address logs "-" instead of taking the
emulator down. Header-only and off unless --frame_probe_log is set, so it adds
no build target and no cost to anyone not using it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The pad looked correct and did nothing. Its own log showed A arriving, the
emulator sat on "PRESS (A) BUTTON", and the title never advanced.
Cause: 360 front-ends poll XamInputGetKeystrokeEx, not XamInputGetState. This
title imports both, and its menus use the keystroke path; the driver returned
X_ERROR_EMPTY there, so every scripted press went into the void while GetState
faithfully reported a button nobody asked about.
Implement it edge-triggered, one event per call: KEYUPs for everything released
first, then KEYDOWNs, matching the SDL driver's ordering (so a thumb transition
clears before it sets). Deliberately NO auto-repeat -- scripted input wants
exactly one event per press, and repeat is precisely what makes menu steps
overshoot. Bits without a virtual key (guide, unused) are swallowed rather than
re-offered forever.
Verified on the real game: title -> main menu -> EXTRAS driven entirely from the
pad file, with `[file-pad] keystroke vk=5800 down/up` in the log for each press.
Two things that only show up once you actually script this pad.
st_mtime is whole seconds. Combined with size it looked like enough and is not:
a script stepping a menu writes several same-length states per second
(`press=A` then `press=B`, both 8 bytes), and every one after the first was
silently dropped -- the emulator simply did not react, with nothing in any log
to say why. Compare st_mtim.tv_nsec as well, and track whether the file existed
at all so a delete is registered once rather than every frame.
Also log one line per state change (not per frame, so it stays quiet). Driving
the emulator headless means there is nothing to watch; this line is the only
proof that a scripted press was picked up, which turns "did my input land?" from
a guess into a grep.
The scripted-input tool this project uses for reverse engineering created its
pad through /dev/uinput. Input devices are NOT namespaced by the kernel, so a
uinput device created inside a container registers with the HOST's input stack:
every trigger hold and button press is delivered to whatever on the host reads
gamepads, not just to the emulator. That was noticed the hard way, and it made
every runtime experiment -- booting, menu navigation, unit harvesting, flight
measurement -- unusable from inside the box.
This driver takes the kernel out of the loop. Pad state lives in an ordinary
text file only the container can see; GetState re-reads it when it changes.
Nothing is registered with the host and no X server is involved. A bonus for RE:
analogue values are exact rather than whatever a virtual stick quantises to.
press=A,START buttons by name, comma separated
buttons=0x1010 or the raw XINPUT mask
lt=0 rt=255 triggers, 0..255
lx=0 ly=0 thumbs, -32768..32767
Absent keys are neutral, so `press=A` alone is a valid file, and a missing or
empty file means no input -- the safe default if it is deleted mid-run.
Selected with --hid=file, path from --pad_file (default /tmp/xenia_pad.txt).
Deliberately NOT part of "any": this pad has to be asked for. Header-only, so it
adds no build target and no cost to anyone not using it.
The offline XBG7 decoder can only assume where a block's index data lives; the
capture now states it. Each captured draw gains an `ib base=… count=… fmt=…
endian=… len=… delta_vb=… min=… max=… idx: …` line — the guest index base, the
draw's index count, and the min/max index value read out of guest memory, which
together say both where the index buffer sits relative to the vertex buffer and
how much of the vertex pool the draw covers.
Also mix the index range into the capture's de-dup key. The engine issues several
draws over one vertex buffer, each indexing a sub-range (a 119-vertex hull LOD
draws 21 indices first, then 225); keying on (vbase, transform) alone kept only
the first batch, which reads like a mysteriously short draw and cost an earlier
session a spurious "the capture disagrees with the descriptor" mystery.
Read-only diagnostics behind the existing F10 hotkey; no emulation behaviour
changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NptfmpjdpNCKEez6d2xvA9
Both of these have been around long enough to be probably prove safe and correct.
As a reminder, color resolves only take the full shader path if the destination number format matches EDRAM encoding && full 8_8_8_8_GAMMA resolves always decode PWL to linear before MSAA sample averaging.
Keeping decode_pwl_gamma bit for testing, but it's probably superfluous.
- Stub MicDeviceRequest
- Games:
- Rock Band 2 now exits game instead of being stuck on boot when mic set to false
- Guitar Hero World Tour now properly responds when you tell it mic is connected
Treat k_8 + LOW_BLUE as alpha selection. 5451080D uses this to resolve its opacity plane, and 4D530808 does the same for a fog lighting pass. Their blue channels are black, so treating LOW_BLUE as an R/B exchange drops data.
Informed by XGCopySurface decompilation, which combines source and inverse dest swizzle, plus notcing how L8 and A8 share the same texture format.
Fixed integer fetches are updated to look widths up through the guest swizzle, so every output channel is scaled by the width it came from.
Previously, host swizzle was being walked, and it was causing some 6 bit channels to be scaled as 5 bits and vice versa.
Co-authored-by: philtimmes <5494151+philtimmes@users.noreply.github.com>
For now, this adds a depth clamp override to both backends that's kept disabled by default.
494707EE needs this for its setup draws that feed its lighting passes. It could be that guest clipping / host near and flare Z planes aren't cleanly interchangeable at the edge of the clip volume.
The fetch constant carries independent signed exponent biases in [-16, 15] for the horizontal and vertical LOD gradients. Scale the H and V gradients by exp2(lod + bias_h) and exp2(lod + bias_v) respectively in the computed LOD sample path. getCompTexLOD keeps returning the raw queried LOD, treating the adjustment like the fetch-constant LOD bias, which is also not folded into it. Zero, the common case, is a no-op.
On the cube implicit-LOD path, where no explicit gradients exist to scale, the greater of the two biases is added to the LOD bias instead - exact when both are equal, erring towards a blurrier mip otherwise.
Co-Authored-By: Herman S. <429230+has207@users.noreply.github.com>
A non-zero value in bits 0:30 of the kill flag kills the vertex, tested on the integer bits rather than as a float comparison so denormal flushing can't affect the result, matching the DXBC translator. With PA_CL_CLIP_CNTL::vtx_kill_or, the position W is set to NaN, killing the whole primitive if any of its vertices requests the kill, with the "and" operator, a dedicated cull distance after the user clip plane cull distances is set to -1, culling the primitive only when all of its vertices request it.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Explicit gradients of the direction reconstructed from the guest S/T/face coordinates pick the wrong mip on Vulkan, so sample cube fetches that use computed LOD without register gradients with implicit LOD and the accumulated LOD bias (fetch constant + register LOD + instruction bias) as the Bias image operand instead. This also makes tfetchCube consistent with getCompTexLOD, which already queries the implicit LOD. Register-gradient cube fetches keep explicit gradients in cube space, and other dimensions keep explicit gradients, matching the DXBC path. Gradient setup is skipped entirely on the implicit-LOD path.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
The check is moved after the anisotropy resolution (and the anisotropic override) so it sees, and can reset, the final filter state.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Avoids a TRANSFER_WRITE -> TRANSFER_WRITE hazard identified by the Vulkan validation layer when a texture is reuploaded (after guest memory invalidation) without having been used for drawing in between, leaving it in the transfer destination usage with no layout transition to order the copies.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
545407D4's UI shader uses tfetch1D with a nonreplicated source swizzle and a 2D constant. The way we have it set up is causing the translators to sample with Y set to 0.
Handle this as 2D in the translators. Normal scalar tfetch1D untouched.
