The v1 streak counter caught nothing during a real freeze: the healthy-run
baseline and not one new (thread, object) pair, while the process burned 1255
ticks per 10 s with two guest threads sitting in KeWaitForSingleObject. That
refuted "loops on timeouts against one object" and left two blind spots, and this
covers both.
A per-thread one-second window counts EVERY call, tracks how many DISTINCT
objects it saw, and logs the last object and the last RESULT when the rate passes
500/s. So a thread rotating over several handles (which resets a same-object
streak) and a thread whose waits SUCCEED rather than time out (which a timeout
counter cannot see) both show up now.
Self-selecting like v1: the healthy poller runs at ~33 calls/s on a 30 ms
timeout, so the 500/s floor stays silent on a good run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
Project Sylpheed freezes mid-mission about half the time. Under gdb every one of
the emulator's 79 threads is in a WAIT, yet the process still burns 1253 ticks
per 10 s - 280 of them in guest threads the backtrace shows blocked inside
KeWaitForSingleObject. So they are cycling: a timed wait that expires and is
re-entered on an object nobody signals. Naming that object is the next step.
Logging it the ordinary way is not possible. KeWaitForSingleObject is
kHighFrequency, so it is silent unless --log_high_frequency_kernel_calls=true,
and measured: that flag writes 175 MB and leaves the emulator seventeen minutes
into a boot with the screen still black.
So count CONSECUTIVE timeouts on the SAME object, per thread, in
xeKeWaitForSingleObject, and log at 100 and then every 500. It is self-selecting:
a wait that is being satisfied never builds a streak.
Measured on a healthy 25-minute Stage 02 run: 27 lines, all one thread
(F800004C) polling one Event (guest VA BE56BB5C) with a ~30 ms timeout - a
legitimate poller, and the baseline a frozen run has to be compared against. Not
"silent", as first drafted, but quiet enough to leave on.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
A thread created suspended publishes its state and its suspend count in TWO
separate lock scopes:
{ lock; state_ = kSuspended; notify_all(); } // lock released here
if (create_suspended) { lock; suspend_count_ = 1; wait(count == 0); }
and Resume() does WaitStarted() - which waits only for state_ != kUninitialized -
followed by `if (suspend_count_ == 0) return false;`. So a resumer can slip into
the gap: it sees the thread started, sees suspend_count_ still 0, drops the
resume and returns false. The new thread then sets the count to 1 and waits on it
forever. A textbook lost wakeup.
Measured in Project Sylpheed. Pressing (A) on the title makes the game do
XamUserGetXUID -> NtCreateEvent -> ExCreateThread(entry=821748F0,
CREATE_SUSPENDED) -> NtResumeThread, and the loader thread then never ran: zero
kernel calls of its own (it appeared in the log only as an argument) and 00:00:00
host CPU time, while the emulator sat at 546% CPU. Boots reached the main menu
1 time in 6.
Fixed by publishing state_ and suspend_count_ under one lock and waiting without
releasing it, so a resumer past WaitStarted() always observes 1.
On the first clean boot after the fix the same loader thread is the CALLER on 20
kernel-call lines and issues 4 ResolvePath asset reads. Every failed boot before
it had exactly zero of both.
Also logs when the host resume is refused. XThread::Resume's Linux path
discarded that bool - the Windows path turns it into X_STATUS_UNSUCCESSFUL - so a
dropped resume was invisible from both sides. Note the log is not by itself a
defect: resuming a thread that is not suspended legitimately returns false, and
it fires ~7 times in a normal boot.
(cherry picked from commit a60fe7d11c)
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.
(cherry picked from commit 15fe11d5d9)
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.
(cherry picked from commit e3e17e4951)
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.
(cherry picked from commit d15c8cfab6)
The offset was being multiplied by the scale and divided by the host scaled size, which collapsed back to guest step, so the cvar changed nothing on Vulkan while D3D12 stepped host texels. Since the size is already in host texels, dividing the offset by it gives the proper step.
Unnormalized coordinates convert to host texels before the offset add so the offset isn't multiplied along with the coordinate. Folds in the fix for 5841095A.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Strips and fans normalize to triangle list host draws instead of being rejected. The conversion buffer is built at runtime when the backend did not bake one at init.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Co-authored-by: Reality <reality@xenios.jp>
They were picked whenever front faces were culled, even with both faces culled. Matches D3D12.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Words at or past the size in the fetch constant read as 0 now instead of whatever sits in shared memory, matching real hardware.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Guest sample 1 lives in host sample 3 when 2x-as-4x. This might have originally just been a typo or oversight.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Mainly for NaN preservation. GS discards primitives by checking positions for NaN, mostly for vertex kill, and without the controls drivers might fold those checks away.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Mips were always regenerated by blitting down from base, even when guest resolved real data into scaled memory.
The upload footprint is the guest mip reduced then scaled while the subresource is the base scaled then reduced, so the deepest mips of scaled textures can disagree by a row or column per axis. Compressed formats round up to the block and absorb it, uncompressed copies now clamp per axis so they never overrun the host image.
Matches D3D12 fix for the same problem.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
Exp 31 is a large finite value up to 131,008 on the guest, not Inf or NaN.
Packing used to clamp colors at 65504 and unpacking returned Inf for extended encodings.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
The domain shader reads the patch index from the hull shader output instead of gl_PrimitiveID, which bypassed the endian swap, offset, wrap and clamp already applied upstream.
The tessellator winds clockwise now. Clip space Y is not flipped on Vulkan, so counterclockwise winding inverted the facing and guest backface culling removed whole surfaces.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.com>
This is a combination of three different Edge commits.
Guest page access is resolved with system page granularity so that anything deciding on protection now takes permissive access of every guest page a system page covers, which matters when the host is larger than the guest.
Access violations: Write faults on pages with no watch armed are only reported handled if guest mapping allows the write.
Invalidation of unwatched ranges when made writable or freed: Decommit, Release and Protect-to-writable (including write-combine) raise invalidation callbacks even with no watch armed.
Co-authored-by: Herman S. <429230+has207@users.noreply.github.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.
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>
