Tags: ARMSX2/ARMSX2
Tags
GS: lift the r44p1 GL fetch blocklist -- the field chose the fast path Delete gl-arm-r44p1-attachment-self-read from the driver-bug database, so r44p1 Mali takes GL_ARM_shader_framebuffer_fetch again on GLES and -- because GSUtil::AndroidAutoPrefersVulkan asks the same table -- Auto resolves back to OpenGL on those devices. The rule was correct about the defect and wrong about the trade. Through 2.6.6.4 the gate it formalised was inert: the Mali profile block re-enabled the ARM backend moments after the gate disabled it, so every r44p1 device shipped on GL + fetch. 2.6.6.5 made the gate actually engage, and on GLES -- where fetch and the texture barrier are one capability -- every self-referential draw became an RT copy plus a tile flush. Shadow of the Colossus fell 30 -> 7 fps on the Anbernic RG 477V and users mass-downgraded to 2.6.6.4. Offline replay of that scene under the device's feature shape shows why no smaller fix could win the speed back: 890 render-target copies and 938 render-pass breaks a frame against 1664 draws -- and a 2.6.6.4 replay under the same shape produces the same ledger (901/948/1664), so the old build's speed WAS the in-tile read, not better GS decisions. The known cost is unchanged from 2.6.6.4: r44p1's fetch corrupts some content (MGS3 observed; most likely the driver grants the tile-read slot per attachment format and silently degrades denied reads to memory fetches inside a live feedback loop). Vulkan stays available as the correct-rendering choice for those games, and its own r44p1 rule is untouched -- there the in-tile read is a device loss, and the RT copy is an ordinary image copy rather than a tile flush. Unlike 2.6.6.4, the restored path is ordering-correct: db41082 taught the barrier-drop logic that ARM's fetch orders overlapping primitives by spec. gs_vertex_tests 64/64, with the driver-profile pins flipped to assert the restoration on GL and the copy path on Vulkan.
Android: regenerate the PGO profile against this tree, and let genera… …te mode run The committed profile was generated from ARMSX2-mono-recovered and last refreshed on 2026-07-13 -- its own function paths name that tree. Building against it costs 7.7% of .text (15,262,600 -> 16,433,556 bytes) versus a matched profile, because every function the profile does not cover falls back to static inlining heuristics. Size is the visible symptom; the risk is speed, and this is the same class of defect as the #165 VU slam, where a profile predating recompiler churn made LTO optimise the hot VU paths the wrong way. This one is captured from armsx2-push-staging at e9f8f83 -- the first profile ever taken from the tree it is used to build. 38,219 functions against the old profile's 36,807, with microVU (292 entries), recExecuteBlock, the recompiler dispatchers, GSRendererHW::Draw and the VIF/GIF transfer loops all covered. Rebuilding with it lands .text at 15,173,960, 0.6% BELOW the last known-good build despite carrying more code -- a matched profile inlines selectively where an unmatched one inlines blindly. build-release-apk.sh required PROF unconditionally, which made regenerating impossible: PGO_MODE=generate builds the instrumented APK you play in order to CREATE a profile, so demanding one up front failed instantly with a FATAL naming a file that run never reads. Require it only in optimize mode.
PINE: stop savestate slot from clobbering the gsctl socket slot The loadstate/savestate positional was named "slot", which is also the global option selecting the PINE socket. argparse shares one namespace, so the positional overwrote it and `gsctl.py loadstate 1` dialled pcsx2.sock.1 instead of the emulator's socket, failing to connect. Give the positional its own dest and keep "slot" as the metavar, so the command line is unchanged.
iOS: shorten the longest comment blocks in the hack code Tightens the new comments this branch added and the longest blocks it sits next to, so every file it touches lands at or under the comment density it started with. Two of the trimmed blocks described what the code no longer does, which is the kind of comment that goes stale without anyone noticing.
iOS: give the menu reveal tap a surface that works on iOS 27 The reveal tap moves onto a clear SwiftUI shape overlaid on the game view, and the dynamic input zones report their classified taps through a notification the game screen listens for. The old gesture sat on the Metal render view, which iOS 27 makes non interactive so the SwiftUI overlays own touch. On that OS the tap could never fire, and once the controller poll was gone there was no path left to bring a hidden menu button back. The zones matter for the same reason: with dynamic thumbsticks or swipe camera on they tile the whole landscape screen and eat every tap before it reaches anything below.
iOS: shorten the longest comment blocks in the hack code Tightens the new comments this branch added and the longest blocks it sits next to, so every file it touches lands at or under the comment density it started with. Two of the trimmed blocks described what the code no longer does, which is the kind of comment that goes stale without anyone noticing.
PreviousNext