Under GSBackThreadMode >= Lockstep roughly half the GS work moves to a second
thread, and every surface that reports GS cost -- OSD, PerfLog, the Qt status
bar, PINE stats, gsrunner's @HWSTAT@ block -- measured the MTGS thread alone.
So the split read as a large GS saving. It is not: on a Rogue Galaxy savestate
here, mode 0 costs 15.8% / 2.63 ms and mode 3 costs 17.0% / 2.84 ms plus
14.2% / 2.37 ms on the back thread -- about twice the total GS CPU time, bought
to halve the critical path. That is a real trade, but nobody could see it.
The back thread registers its own handle at entry, as the SW rasterizer workers
do; StopBackThread clears it after the join. Unlike every other handle here it
is written by a thread other than the one sampling it, so the handle and its
running total sit behind a mutex taken twice a second. Installing a handle
rebases the total off it, so the first window after a GSreopen respawn measures
the new thread rather than its difference against the retired one's.
The figure is omitted, not reported as zero, wherever a back thread does not
exist -- otherwise a mode 0 vs mode 3 comparison reads a permanent 0% as
meaningful. gsrunner latches the presence flag during the run because DumpStats
executes after VMManager::Shutdown, by which point the thread has joined.
MsgGSDump (0x14, ARMSX2-local) queues a GS dump of the next N frames:
[u32 frames][u32 path_len][path bytes], where frames == 0 stops a recording
dump and UINT32_MAX records until stopped -- the same press/release pair the
GSDumpMultiFrame hotkey binds. The reply is JSON carrying the resolved dump
path, so a client knows the file to wait for instead of guessing at the
snapshots folder's auto-naming.
Three things the naive version of this gets wrong, all found by testing it
against a live Dragon Quest VIII:
QueueSnapshot honours a caller-supplied path only when it ends in .png, and
silently substitutes an auto-named file otherwise -- a scripted client would
write somewhere it never looks. Normalise the path up front instead, dropping
a .gs/.gs.xz/.gs.zst/.png suffix if the caller spelled one out so that naming
the file you want does not earn a doubled extension.
A request that arrives while a dump is already recording creates no second
dump: the VSync handler only opens one when none exists. It writes a stray
screenshot, and worse, overwrites the running dump's remaining frame count and
cuts it short. The first version of this replied with a path for a file that
was never created and truncated the recording that was. Refuse instead, with
reason "already recording"; the caller can stop the running dump first. The
same defect reachable via the Screenshot hotkey is left alone here -- it is a
renderer behaviour change and belongs in its own commit.
The PINE thread cannot push MTGS packets: the ring is single-producer and that
producer is the EE thread. Take the same two-hop route BuildStatsJson already
documents -- Host::RunOnCPUThread, then RunOnGSThread -- and read GSConfig's
compression method on the GS thread, since it decides the extension.
QueueSnapshot and GSQueueSnapshot now return whether they took the request;
existing callers ignore it. GSIsDumpRecording and GSHasFrontParser expose the
two pieces of GS-thread state the reply needs. pipelined_incomplete surfaces
the known GV7-2 gap rather than letting a script collect corrupt dumps.
Verified live: every promised path was written, refusals produced no files,
and all three dump shapes replay in gsrunner -- single-frame as 4 (2) frames,
a stopped multi-frame recording as 186 (91).
Help menu (Linux desktop and everywhere):
- GitHub Repository pointed at a dead branch (/tree/macOS); now the repo root.
- Removed the PCSX2 Wiki and Documentation items (they linked pcsx2.net /
wiki.pcsx2.net, impersonating upstream) and replaced them with a single
ARMSX2 Website item pointing at armsx2.net.
- Removed Check for Updates (the auto-updater is disabled, so it only ever
errored) and About Qt.
- About dialog body reworded to describe ARMSX2 (crediting PCSX2 as upstream).
Wrong-destination / impersonation fixes:
- PINE MsgVersion reply now identifies as "ARMSX2" (buffer sized accordingly).
- Bug-report links (GS unknown-video-mode / invalid-lod, EE COP2 warnings) now
point at github.com/ARMSX2/ARMSX2/issues.
- "download a fresh copy" recovery messages (VMManager, SaveState, Windows
updater, Win32 update-not-supported dialog) now point at armsx2.net.
- Auto-updater release/compare endpoints and staging-dir name de-PCSX2'd.
UI strings: setup wizard, cover downloader, and the Settings widgets (Qt) plus
their Big-Picture/Fullscreen ImGui twins now say ARMSX2. The "PCSX2Blue" theme
settings key is left unchanged (persisted / matched in code); only its display
name changes.
Interop identifiers deliberately left as-is: the PINE socket name (pcsx2.sock,
for PINE-client compatibility) and the RetroAchievements client name.
The PINE server thread called MTGS::RunOnGSThread + WaitGS directly to sample
GS memory stats and device/driver info. The MTGS ring is single-producer:
m_WritePos is owned by the EE/CPU thread, so pushing a packet from the PINE
thread creates a second producer that races the EE thread's own ring writes,
desyncing the pending-packet count. That lost wakeup deadlocks the EE thread
(parked in WaitGS) against the GS thread (asleep in WaitForWork).
Marshal the sample onto the CPU thread first -- the legitimate ring producer --
and block until the GS-owned data has been gathered.
Both `gsctl stats` and `gsrunner -stats-json` reported counters with no
indication of which GPU or driver produced them, so a stats blob from a
tester was not attributable — and driver identity is the axis nearly every
mobile GPU behaviour turns on.
This matters beyond provenance. Several GS features are force-overridden
per-driver (framebuffer fetch and texture barriers are forced on for Adreno
regardless of INI), so without knowing the driver you cannot tell whether a
settings A/B was applied at all or silently compared a config against itself.
gsrunner captures the strings on the GS thread at first present rather than
at shutdown, where the device may already be gone. Both emitters escape the
values, since GetDriverInfo() is multi-line on Vulkan.
Debugging a GS performance problem meant restarting the emulator and reloading a
savestate for every "did you try setting X?", and the only way to read the
statistics that drive that decision was to look at the OSD. PINE already
provides a unix socket, a thread, framing, a config key and the RunOnCPUThread
marshalling pattern, but its opcodes stop at guest-RAM peek/poke plus savestates
and game identity -- no host statistics, no settings.
Adds four ARMSX2-local opcodes at 0x10+ (upstream PINE ends at 0xF, so a generic
client will never send them):
MsgGetStats PerformanceMetrics, all GSPerfMon counters and the texture
cache memory figures, as JSON.
MsgGetSetting read a setting by section/key.
MsgSetSetting write a setting, apply it, and report whether the key forces a
GS device reopen.
MsgFrameAdvance step a paused VM.
MsgSetSetting writes the persisted key rather than poking EmuConfig directly,
because a direct poke is silently reverted by the next ApplySettings, which
re-derives EmuConfig from the INI layer stack. The restart_required answer comes
from a new GSOptions::IsRestartOption, sitting next to RestartOptionsAreEqual so
the two lists stay in sync.
Statistics are gathered on the PINE thread. PerformanceMetrics and g_perfmon are
benign scalar reads, but GSgetMemoryStats dereferences g_texture_cache and
g_gs_device, which are GS-thread owned, so that one is marshalled through
RunOnGSThread.
tools/gsctl.py is a stdlib-only client emitting JSON on stdout.
Verified against a headless gsrunner replay: toggling accurate_blending_unit
between 0 and 5 over the socket moves barriers 1.0 <-> 91.5 and draw calls
55.5 <-> 101.5, repeatably, with no restart.
Brian Degenhardt
chaoticgd
SternXD
TheTechnician27
GovanifY
Stenzek