present_generated_frame submitted its blit and presented immediately.
command_buffer::submit goes through queue_submit, which DEFERS to the offloader
thread when multithreaded RSX is on -- so the present waited on a semaphore whose
signal operation had not been submitted, which the spec forbids and which hangs
the present without returning the acquired image. The real present path flushes
first for exactly this reason; this now does the same.
Frame generation also refuses to run at all with multithreaded RSX enabled.
generate() submits inline on the RSX thread while the frame's own command buffer
is merely enqueued to the offloader, so the interpolation can reach the queue
before the frame it reads -- and two threads then submit to one VkQueue without
the external synchronisation vkQueueSubmit requires, which is what g_submit_mutex
exists for and what generate() bypasses by calling vkQueueSubmit directly.
Refusing is honest. Supporting it means routing through vk::queue_submit and
reasoning about deferred submission, which is not a change to make untested.
MTRSX defaults off, so this affects only users who enabled it -- and it is the
profile that produces intermittent DEVICE_LOST under load.
capture_presented_frame() was handed target_layout -- COLOR_ATTACHMENT_OPTIMAL or
TRANSFER_DST_OPTIMAL -- and stored it for generate() to use. But generate()
records into its own command buffer, submitted after the frame's, and the frame's
own transition to present_layout runs in between. So by the time the barrier
executed, its oldLayout named a layout the image had already left, and the
matching barrier on the way out restored that same wrong layout -- leaving the
image outside PRESENT_SRC_KHR when it was presented.
Both are violations: oldLayout must be the current layout or UNDEFINED
(VUID-VkImageMemoryBarrier-oldLayout-01197), and a presented image must be in
PRESENT_SRC_KHR (VUID-VkPresentInfoKHR-pImageIndices-01430). It also desynced the
renderer's own layout bookkeeping for that swapchain image on every subsequent
frame.
Passing present_layout instead describes what the image will actually be in, so
the barrier is a no-op transition that reads it where it lies and leaves it there.
Found by a Vulkan lifetime and layout audit. Not verified on device.
Two findings from the Vulkan audit, both of which let the interpolation read an
image it had no valid dependency on.
The barrier before Process used TOP_OF_PIPE with MEMORY_READ. TOP_OF_PIPE in
srcStageMask specifies no stage of execution, so the first synchronization scope
was empty and no availability operation happened for the colour-attachment and
transfer writes the frame made into that image in the PREVIOUS submission.
Submission order on a queue orders execution; it is not a memory dependency. So
the interpolation could read a partially-flushed frame -- which presents as
smearing during motion and does not respond to any interpolation setting, since
the interpolation is not what is wrong. Source scope is now
COLOR_ATTACHMENT_OUTPUT|TRANSFER with the matching write access, and the mirror
barrier's empty BOTTOM_OF_PIPE second scope becomes ALL_COMMANDS.
Separately, the swapchain was created COLOR_ATTACHMENT|TRANSFER_DST, but
FrameGen::Process copies FROM the presented image as TRANSFER_SRC_OPTIMAL. Both
that layout and vkCmdCopyImage require TRANSFER_SRC usage. Nothing else in the
renderer reads a WSI image, so it had never been needed. Requested only where the
surface reports it, with a warning otherwise, since it is not guaranteed on
Android.
Frame generation's state is file-scope global and had no teardown path.
shutdown() only finalised the old dlopen'd library, and release_shared_images()
was never called at all, so at emulation stop the fences, command pool, command
buffers, allocator, queue and the whole pass chain stayed live as children of a
destroyed VkDevice.
The reachable consequence is worse than the leak. On the NEXT boot in the same
process g_native.valid() was still true, so build_native_stack() was skipped and
generate() waited on a fence from the dead device, reset freed command buffers
and submitted to its queue. g_shared_w/h still matched too, so the output images
were not recreated either.
That is boot -> stop -> boot, and it is deterministic rather than intermittent.
It is the likeliest explanation for frame generation working in one game and then
failing immediately in the next one launched without restarting the app, which is
exactly how it was reported.
release_device_resources() destroys the stack and the images and resets the state
that gates rebuilding, including g_disabled -- a new device may not fail where the
last one did. Called from ~VKGSRender after vkDeviceWaitIdle, while the device is
still alive.
Found by a Vulkan lifetime audit. Not verified on device; the hardware was
unavailable.
shader_count() read the ENTIRE SPIR-V cache off disk and rebuilt every module,
then threw the result away -- and it ran twice per frame on the RSX thread, from
capture_presented_frame() and generated_frame_count(). At ~322KB that is roughly
644KB of file IO, four stats, two opens and hundreds of allocations per frame, on
the thread driving the whole present path.
That is CPU cost, which is why halving the GPU shader cost with fp16 changed
nothing, and why ~3ms of measured interpolation was costing ~20ms of frame time.
It arrived with the fix for shaders not loading at all: making the probe ask the
cache was right, doing it per frame was not. The verdict can only change on
import, so it is memoised and cleared there, as ARMSX2 does for the same reason
(GSLsfg.cpp:53-58, whose comment names this exact hazard).
Also: GenerateInto writes through a storage image view, which requires
VK_IMAGE_LAYOUT_GENERAL, and the blit that follows declares TRANSFER_SRC. Nothing
transitioned those images either way -- a storage write outside GENERAL is
undefined, and on Adreno a mismatched layout on a UBWC image forces a
conservative full-surface decompress. Both transitions added, with the layout
tracked across frames.
And the generated-frame blit is source-size to destination-size, so LINEAR
filtering bought nothing and cost a filtered sampling pass instead of the fast
copy path. NEAREST.
Found by a comparative audit against the ARMSX2 driver. Not yet verified on
device -- the hardware was unavailable when this was written.
The fence wait at the head of generate() blocked for up to a second on the
previous slot's work. When it actually waited, the long frame interval it
produced went straight into the pacer -- whose clock is sampled after this point
-- and any interval over 100ms trips MINIMUM_BASE_RATE and stops generation for a
full second (FrameGenPacer.cpp:29/40/97-100).
So a stall here made the pacer stand down, and it was measuring a rate we had
slowed ourselves. Measured against that: the pacer asked for a generated frame on
only ~40% of real frames, which matches one >100ms interval every couple of
seconds costing a second of generation each time.
A zero timeout asks whether the previous frame's work is done and skips this
frame if it is not. Skipping costs one generated frame; stalling cost a second of
them. With three rotating slots the work has three frames to finish, and it
measures ~3ms, so skips should be rare.
VK_TIMEOUT is now a normal outcome rather than an error, so only real failures --
VK_ERROR_DEVICE_LOST being the one actually suspected here -- reach the counter
that disables the feature.
Every non-success result from vkWaitForFences was reported as a timeout, which
hid the one detail that mattered: 60 of them arrived in 3 seconds against a
1-second timeout, so the wait was failing immediately rather than expiring.
VK_ERROR_DEVICE_LOST is the obvious candidate and means something entirely
different from a slow frame -- the device is gone and frame generation is the
messenger, not the cause.
The failure is intermittent, so this logs the result code once per stall rather
than trying to fix a cause that has not been identified.
The single-submit path broke two games -- one reported "failed", another stopped
progressing past its logo -- and reverting it restores both. It was chasing ~8 ms
of measured per-submit overhead, and the idea may still be right, but it changed
swapchain image ownership incrementally and got it wrong four separate ways:
acquiring before the count was known (leaving semaphores signalled and every
later acquire failing), sharing semaphores across in-flight frames, leaking
acquired images that were never presented, and writing storage images outside
GENERAL. That is a design that needs settling before it is written, not patched
into place against a device.
Kept, all measured:
- The acquire semaphore. Generated frames were acquired with VK_NULL_HANDLE and
written immediately -- a swapchain image used before the presentation engine
had finished with it. That was the judder: invariant to every interpolation
setting because the interpolation was never at fault, present at any frame
rate because a race has no cadence, and smearing rather than stutter because a
torn image is parts of two frames at once. Gone entirely at x2.
- The guest extent. The passes size their optical flow from the ratio between
what the game rendered and what is presented; passing the presented size for
both made that ratio 1.0 and ran the flow at full 1080p for a title that
rendered 720p. 4.8 ms -> 3.0 ms of GPU time.
- fp16 shaders, where the device reports and enables them.
- Fence timeouts are transient. disable() is permanent for the session, so one
stall during a load spike left frame generation reading "failed" until the
game was restarted with nothing wrong.
Frame generation costs ~3 ms of GPU time per frame. On a title already at the
refresh rate that is enough to cross a vblank boundary, so it trades real frames
for interpolated ones and gains nothing; it is worth having where a game has
headroom below the panel rate, not where it is already at the cliff edge.
Measured, not guessed: a GPU timer around the passes says they cost 4.1 ms per
frame, steady, while frame time went from ~17 ms to ~30 ms with generation on.
Roughly 8 ms per frame was therefore not interpolation -- it was the cost of
submitting it.
ARMSX2 records Process, every GenerateInto, and every copy into the acquired
swapchain images into ONE command buffer and issues ONE vkQueueSubmit that waits
on each acquire and signals each present. ARMSX3 submitted framegen's work and
then a separate command buffer and submit per generated frame, each its own GPU
batch on the same queue with its own scheduling gap.
generate_into_targets() takes the acquired images and does the whole frame in one
buffer and one submit; the present path acquires them up front and issues the
presents afterwards. present_generated_frame is left in place for the pipelined
path, which is still disabled, and no longer runs on this one.
Follows the acquire-semaphore fix in the previous commit -- that was the judder
(a swapchain image written before the presentation engine had finished with it),
this is the cost.
present_generated_frame acquired its swapchain image with VK_NULL_HANDLE -- no
semaphore, no fence -- and then blitted into it and presented immediately.
Vulkan requires waiting on the acquire before touching the image, so this was
writing into one the presentation engine could still be scanning out.
That accounts for what nothing else did. The artifact was invariant to flow
scale, shader family, fp16 and multiplier, because all of those change how a
pair is interpolated and the interpolation was never at fault. It appeared at
every frame rate, because a race has no cadence. It looked like smearing rather
than stutter, because a torn image is parts of two frames at once, and it only
showed during motion, because that is when consecutive frames differ.
The real frame has always had an acquire/present semaphore pair in
frame_context_t. Only the generated path went without, which is why nothing
inside frame generation could reveal it.
ARMSX2 acquires with a fence and blocks on it before submitting, and says so.
This waits on the GPU instead: the blit waits on the acquire, the present waits
on the blit, one pair per swapchain image so none is reused while in flight.
Also restores the fp16 probe consistency in shader_count(), which a git checkout
during this session reverted -- three callers ask which shader variant to use and
any two disagreeing makes a freshly imported cache read as "no shaders".
Frame generation was running the fp32 shader family on hardware that supports
fp16. Measured on an Adreno 740: real frame rate fell from ~60 to ~25 with
generation on, so the output was worse than not using it at all.
The cause was copying a hardcode without its reason. ARMSX2 sets allow_fp16 and
prefer_fp16 false and says why: PCSX2's Vulkan backend never asks for
shaderFloat16 when it creates its logical device, so a module declaring the
Float16 capability would be invalid usage there -- and its own comment ends
"restore Eden's two lines if PCSX2 ever enables the feature". Eden does gate on
the device, and Eden is the one that performs. RPCS3 enables shaderFloat16 where
the driver is trusted, and clears its own flag on the Adreno drivers whose
compiler rejects native float16, so asking the device is both possible and safe.
The device in question logs "GPU/driver supports float16 data types natively".
The compat Device answers a third query now, as Eden's does. BuildShaderCache
takes the flags rather than choosing its own, because the cache header stores
them and rejects an entry whose flags differ -- the same mismatch that made a
freshly written cache read as "no shaders".
Found by measuring instead of reasoning: the CPU side of the passes costs
0.000-0.061 ms/frame, which said the cost was GPU-side and not in how the work
was sequenced, after four attempts at the sequencing.
One command buffer and one fence meant every frame waited for the immediately
previous interpolation to finish before it could reset the buffer. The GPU
pipeline drained once per frame and the CPU could never get ahead, which is a
stall no amount of moving the work around removes -- it is the depth that is
wrong, not the placement.
ARMSX2 keeps one slot per swapchain image, each with its own command buffer and
fence, and waits on the fence belonging to the slot it is about to reuse. That
fence is several frames old, so in the normal case it is already signalled and
the wait costs nothing. Three slots here, rotated per frame.
This is the last of the differences found by reading the ARMSX2 driver rather
than reasoning about my own: the copy, then the pacer's clock, then the frame's
own command buffer, and now the depth.
Discord: the emulator logo now appears beside the cover art, as it does in
ARMSX2. By URL rather than asset key -- a key that is not in the portal makes
Discord reject the entire presence update, which is what left the card blank
before. It is the launcher icon out of this repository, so it cannot drift from
the app. With no cover the logo takes the large slot instead of sending no assets
at all.
The previous commit removed the capture copy by recording Process() into the
frame's command buffer. That traded one problem for a worse one: the present path
waits on that buffer, so the interpolation's GPU cost came straight off the real
frame rate. Measured on device, 1920x1080 content ran at 24-28 real fps with
generation on, while the CPU side of the same call cost 0.013-0.061 ms -- the
work was not expensive to record, it was expensive to be waited on.
ARMSX2 runs Process in framegen's OWN command buffer, after the frame, against
the same presented image. That costs neither the copy nor the frame, and it is
what this now does: the capture side only remembers the image and lets the pacer
plan, and generate() transitions it, runs Process, runs GenerateInto per planned
frame, and submits -- one buffer, one submission, off the critical path.
Defaults were checked against ARMSX2 first and are identical (flow scale 100,
performance shaders on, target rate 0, multiplier 2), so this was never a settings
difference.
Two defects, both from grafting the passes onto the existing shape instead of
adopting the one they were written for.
A copy per frame that ARMSX2 never makes. Process() copies the source into its
chain itself (FrameGen.cpp, CopyPresentedFrame), and ARMSX2 hands it the real
swapchain image. This handed it a capture copy made by a separate full-frame blit,
so every frame paid for two 1920x1080 copies instead of one. The capture existed
only because generation happened later, from another submission, by which time the
swapchain image was gone -- so the copy was paying for a problem the ordering
created.
And the pacer planned against a clock that jittered. Plan() derives the base frame
rate from the interval between its own calls; it sat inside generate(), behind
three early returns and a conditional call site, so it measured an interval the
game never had and planned against it. That is judder by construction, and no
amount of tuning the multiplier reaches it.
Process now runs in the frame's OWN command buffer, against the presented image,
where the frame is finished and the image is still ours -- which removes the copy
and the reason for it together. The pacer plans there too, once per frame,
unconditionally. generate() keeps only the generation half: record GenerateInto
per planned frame, submit, and let queue order carry it into the blits.
The input capture images are gone entirely.
Reported as judder and lower performance against ARMSX2 and Eden running the same
passes, which was the right comparison to make.
The cache was written with one flag set and read with another. BuildShaderCache
asked for allow_fp16 = true while LsfgShaders, the only consumer, asks for
(false, false), and the header stores those flags and is rejected when they
differ -- so the cache written at import could never satisfy the read after it.
On a desktop that is invisible: the source DLL is still there, LoadShaderModules
falls through to re-parsing the executable, and the cache is dead weight rewritten
every launch. Android has nothing to fall through to, because the picked file is
a copy in app cache that the system may clear, so it surfaced as "no shaders"
with a valid cache sitting next to it. Worth telling Camille: Eden and ARMSX2 are
both re-parsing Lossless.dll every launch rather than using their cache.
The cache also survives a missing source now. It is validated against the source's
size and mtime, which is right where an install stays put and wrong here; passing
0 skips those checks, matching what source_hash and variant already do. A replaced
Lossless Scaling is no longer noticed automatically, which is the trade -- against
losing the cache to a routine cache sweep, and re-importing is explicit.
Performance: the fence wait moved from after the submit to before the next one.
Waiting at the end put the whole interpolation on the critical path -- the thread
sat idle until the GPU finished, every frame -- when nothing required it: frame
generation and the present blits share one queue, so submission order already
orders them. Waiting at the START only blocks when the previous frame's passes
have not finished in time. The queue is now taken from the device rather than a
second vkGetDeviceQueue, so that sharing is explicit rather than incidental.
Settings: motion detail is a slider rather than three stops, and performance
shaders is a switch rather than a pair of buttons.
Three defects from the switchover, all mine.
vmaCreateAllocator crashed at pc 0 the first time frame generation was switched
on. The allocator was created with physicalDevice and device but no instance and
no vulkanApiVersion; Android builds with VK_NO_PROTOTYPES, so VMA resolves its
table dynamically through vkGetInstanceProcAddr, which answers only for global
functions when the instance is null. It stored nulls and called one. memory.cpp
documents this exact failure at its own vmaCreateAllocator -- the two getters were
supplied and the instance beside them was not.
shader_count() then answered for the wrong cache, twice. First it still counted
g_shaders, which import_shaders stopped filling when it moved to the ported
extractor: generated_frame_count() multiplies by it, so generate() returned on its
first line and frame generation sat on "starting" with nothing logged, because it
never got far enough to fail. Replacing that with GetInstalledLosslessStatus() was
also wrong -- that validates the DLL PATH, and the UI copies the picked file into
app cache, which Android may purge. A re-import wrote a good 322KB shader cache and
it still said "no shaders". It now asks whether the cache LOADS, which is the
actual question: the shaders are extracted once and the source is not needed again.
The dead initialize() call in generate() is gone with it. It built the dlopen'd
library's context, nothing uses it, and a failure there could still disable the
feature.
Settings: the in-game menu offered the multiplier alone. Someone opening it
mid-game is there to answer "it is generating but the picture is unsteady" or
"it is generating but it is too expensive", and neither is the multiplier. Target
rate, flow scale and performance mode now sit beside it. Target rate is new --
0 keeps the fixed multiplier, non-zero is Camille's adaptive pacing.
Wires up the previous commit. Frame generation now runs on OUR VkDevice, in our
own present path, instead of inside a dlopen'd library with a VkDevice of its own.
What that removes: every frame used to cross between devices as an
AHardwareBuffer -- allocated, imported as a VkImage on our device so the renderer
could blit into it, handed over as a raw buffer, imported again on theirs. The
capture images are plain device-local VkImages now, because the passes read the
very images the renderer already wrote. The AHardwareBuffer external-memory
extension was also the narrowest gate on the whole feature and is no longer
required.
Kept deliberately:
- The capture itself. The swapchain image is presented and reused, so the passes
still need a stable copy; only its backing changed.
- commit_capture(), now near-vestigial. It existed because a second VkDevice had
no semaphore joining it to ours. One device and one queue means submission
order already says this, but the call site is where the capture becomes
readable and that is worth keeping named.
- The fence wait in generate(). The present path blits the generated images
immediately after, so the old contract -- return only when they are ready --
still holds. A semaphore would do it without stalling the thread and is the
obvious next step, on a path that has broken three times from partial fixes.
Frame generation records into its OWN command buffer, as the ARMSX2 driver does:
the passes have to run after the captured frame is complete and before the
generated images are blitted, and the renderer's buffer is already closed by then.
import_shaders now drives the ported extractor rather than the library. Both kept
their own copy of the shaders, and importing through the library would have looked
like it worked -- a count comes back, the settings screen agrees -- while the cache
the passes actually read stayed empty. Its failures are now phrased for the person
who chose the file.
VKPresent.cpp is untouched: generate(), generated_frame_count(), generated_image(),
capture_presented_frame() and commit_capture() all kept their signatures and their
meaning, which is the whole reason the switchover is one commit and not five.
Builds clean. NOT yet run on hardware -- neither this nor the device-feature change
under it has drawn a frame.
Compiles; not yet wired. VKFrameGen still drives the old dlopen path and nothing
calls these passes -- that is the next commit. Landing it here keeps the port and
the switchover separable, because the present path is the part that has broken
before.
The implementation is Camille LaVey's, from eden-emu PR #4263, by way of ARMSX2
2.6.6.8. She licensed it GPL-2.0-or-later for use here: ARMSX3 derives from
RPCS3, which is GPL-2.0-ONLY with no "or later" clause, so the original
GPL-3.0-or-later terms could not be carried across. Every file records that.
Eden is unaffected -- "or later" leaves its own use exactly as it was.
Why it is worth having: the current implementation runs behind a dlopen'd .so
with its OWN VkDevice, so every frame crosses devices as an AHardwareBuffer --
allocated, imported on our device, handed over, imported again on theirs. These
passes run on our device in our own present path and that round-trip disappears.
It also brings adaptive pacing: instead of a fixed x2, generate as many frames as
it takes to hold a target refresh rate, which is the answer to a game oscillating
between 60 and 30 on a 60Hz panel.
Porting notes, all of it concentrated in three seams rather than spread:
- LsfgVkCompat's Device adapter wrapped GSDeviceVK and now wraps vk::render_device.
28 of the 31 files never mention either and were not touched.
- GSConfig lives in FrameGenConfig.h, mapping RPCS3's mode enum and cfg fields to
the names the passes read, so a later merge from Eden touches passes not wiring.
- LosslessDll's platform calls (FileSystem/Path/GSXXH) became fs:: and an inline
FNV-1a; the hash only has to notice the DLL changed since the cache was written.
Two changes outside the tree were prerequisites, not cleanups:
- vkCreateDevice now ENABLES vulkanMemoryModel and robustness2's nullDescriptor
when the device reports them. Both were already probed and never enabled, and a
shader that declares the memory model on a device where it was not enabled is
invalid usage rather than a soft fallback -- desktop drivers shrug it off while
Adreno takes the device down mid-frame, so it would have looked fine until it
was not. Only nullDescriptor is turned on, not robustness2's expensive half.
- The Android Vulkan loader gained vkFreeDescriptorSets, which it never loaded.
New settings: Frame Generation Target Rate (0 = fixed multiplier) and Frame
Generation Lossless Path. Nothing ships the shaders; they are read from the
user's own legitimately purchased copy, exactly as before.
A game that is visible but unreadable is the failure mode that costs the most
time, because nothing about it looks like a permissions problem. The core opens
games with ordinary file IO. Without All files access the scanner falls back to
SAF document trees, and a title found that way has no filesystem path to open --
but it is still listed, still launches, and then sits on its first loading
screen when the reads never arrive. The same shape appears when the grant is
revoked after a folder was added, or when a disc sits on storage the app was
never given. Moving the same files into the emulator's own games directory fixes
all of it at once, which is what makes the cause so hard to see: the game works
or does not depending only on where it lives.
Boot now proves the content is readable first, at two offsets. Size alone proves
nothing -- an entry can be listed with its real size and still refuse to deliver
bytes -- so it reads byte 0 and byte 32769, the ISO descriptor, the first place
any disc is read for real. Failure returns invalid_file_or_folder with a message
naming the two fixes, rather than handing the core content it cannot read.
The scanner says the same thing at the point it falls back, distinguishing "All
files access is not granted" from "this tree has no filesystem path", because
they need different fixes.
Read-only probe, and directory-installed titles skip it: fs::is_file is false for
them and they were never affected.
Reported by a tester whose whole library started working after moving the ISOs
into ARMSX3/config/games -- cover art, launching, and Prototype no longer locking
up, all from the move alone.
Reverts upstream 8a6c96745, taken in the ROP remap merge, back to the 0.8
behaviour. The check is sound on a desktop filesystem, but on Android the disc is
read through SAF/content URIs and this predicate decides how a title gets
mounted: System.cpp:1572, 1589, 1764 and 1878 all branch on it, as does
rpcsx-android.cpp:3935. A short read there does not fail the boot outright, it
silently routes the title down a different mount path -- which is what a game
that reaches its first loading screen and never leaves it looks like.
Not identical to 0.8: magic[] is zero-initialised. The original compared it
without checking the read at all, so a failed read compared uninitialised stack.
Zeroing restores "do not reject on a short read" without the undefined behaviour,
and a genuinely non-ISO file still fails the CD001 test.
iso_archive::is_valid() stays. It comes from a different upstream commit
(d6d5c6082), System.cpp calls it, and it is not part of this predicate.
Reported against NASCAR 2011, which reached the menus before the merge and now
sticks on the first loading screen. NOT confirmed as the cause -- the reporter's
build predates the local commits, and the other public candidates in that window
are the Adreno compute group size and the driver pipeline cache work.
The PS3 has two PPU hardware threads and upstream's own config comment says this
must be 2. With 1, SPURS does not get the concurrent PPU progress it expects and
its task modules fail validation: the SPU executes its own HALT instruction and
the graphics pipeline stops. It presents as an intermittent freeze after 10-30
minutes, on hardware where the same build with the default is fine.
There is no UI for this value -- it is reachable only through a raw core
override, so it is set deliberately and then forgotten. Nothing reported it,
which meant an affected log was indistinguishable from a healthy one and the
setting had to be found by eye in the config dump, after a diagnosis that went
through the SPU halt, the reservation path and an instruction-level SPU test run
before arriving at a configuration difference.
Six of Terry Welsh's screensavers (GPL-2.0-or-later) run as animated library
backgrounds alongside Flurry: Flux, Plasma, SolarWinds, Hyperspace, Lattice and
Skyrocket.
They are GL 1.x -- immediate mode, the fixed-function matrix stack, display
lists, texgen -- so savers/gl1.c answers all of that on GLES2 rather than the
renderers being rewritten. Display lists are not an optimisation to skip here:
each saver compiles its particle shape once and replays it per particle with a
different matrix, so glCallList IS how they draw.
Flux, Plasma, SolarWinds and Hyperspace are byte-identical to upstream. They
build with RS_XSCREENSAVER, their own platform-neutral path, and everything it
expects from an X11 host is answered by savers/compat. Lattice and Skyrocket
ship Windows-only and were hand-ported; each carries a header listing exactly
what was removed. rss-glx has neutral versions of those two but is GPL-2.0-only,
which ARMSX2 (GPL-3.0) could not take.
Every saver is compiled inside its own namespace by a *_unit.cpp. They all
declare the same globals -- draw, idleProc, cleanUp, readyToDraw -- because each
was built as a separate executable, and two in one .so collide at link time.
Notes on the three bugs that were not obvious:
- The render thread gets a 16MB stack. Skyrocket's World constructor declares a
1024x1024x3 starmap as a LOCAL, 3MB, then a 768KB sunsetmap. On a Windows main
thread that was fine; here it was a SIGSEGV in memset before the first frame.
- gl1_frame_begin clears the first frames and then masks alpha off. These savers
fade the previous frame instead of clearing, and that fade writes destination
alpha, dragging a composited surface toward transparent -- which reaches the
screen as TV static. Same fix Flurry needed.
- The saver lifecycle is serialised behind a mutex and a generation token. Each
view owns a GL thread, so switching preset let the outgoing thread's teardown
land after the incoming thread's init and wipe it; gl1 keeps its state in one
global. A view may now only free the run it started.
Also renames the settings mirror armsx2-settings.json to armsx3-settings.json
(issue #82). The old name stays readable: after a reinstall it is the only copy
of a user's settings, so it is still restored from, still collected into new
backups, and now deleted alongside the new one -- leaving it behind would
silently re-seed settings that had just been purged. Old backup archives restore
unchanged.
The library background rendered as full-screen TV static with the smoke
faintly visible behind it.
Flurry draws its trails by fading the PREVIOUS frame rather than clearing,
so it needs the back buffer to still hold what it drew last time. EGL
defaults EGL_SWAP_BEHAVIOR to EGL_BUFFER_DESTROYED, which leaves the buffer
undefined after every eglSwapBuffers, so every frame started from
uninitialised GPU memory -- which is what reached the screen as static.
Measured: a single fade darkened the buffer by 3.17%, but sixty consecutive
fades only achieved 6.5% in total, where sixty compounding 3.17% fades
should have taken a corner reading 123 down to 17. The fade was working
every frame; its result was not surviving the swap. A 64x64 readback of that
corner went from mean=128 ndiff=41 to mean=0 ndiff=0 with preservation on.
Preservation must be requested on the config and on the surface, and is then
queried back rather than assumed, since a driver may refuse it.
Also set the surface alpha once and mask further alpha writes off. Flurry
fades with GL_SRC_ALPHA/GL_ONE_MINUS_SRC_ALPHA, which writes destination
alpha as well as colour and drags it toward the fade's own value -- harmless
for a screensaver that owns the display, wrong for a surface the window
compositor blends. RGB is untouched, so the trails are unaffected.
Calum Robinson's Flurry screensaver (2002), ported from the xscreensaver tree and
offered alongside the XMB wave. Asked for by a tester who has wanted it on a
handheld since the Mac original.
The renderer is his, unmodified. It draws the way 2002 did -- client-side vertex
arrays, a fixed-function ortho, GL_QUADS -- none of which GLES2 has, so
gl_compat.c answers those calls with a shader, a matrix uniform and an index
buffer instead. That keeps the diff against upstream to four lines: gluBuild2DMipmaps
becomes glTexImage2D plus glGenerateMipmap, GETTIMEOFDAY_TWO_ARGS is set by hand
rather than by xscreensaver's configure, DrawSpark is guarded because it is
immediate-mode and upstream never defines DRAW_SPARKS, and the xlockmore shell is
replaced by four entry points. Its own target rather than part of the JNI glue:
BSD-3-clause next to GPL, and plain C that wants none of the C++20 around it.
FlurryGlView is the same TextureView and EGL shell XmbGlView already uses, so it
reports through onGlStatus the same way and a device that cannot bring GL up
falls back to the 2D backdrop rather than showing a hole.
Off by default, and the description says why. This is a live particle simulation,
and an animated library background has been walked back here once before --
ARMSX2 shipped a looping video behind this same screen and removed it in 2.5.9
when the continuous decode turned out to cost real performance. The loop is
capped at 60fps for the same reason XmbGlView caps itself at 30: Flurry already
refuses to advance faster, but without a cap the thread still spins at panel rate.
Also adds @JvmStatic to Rpcs3Bridge.deleteState, which NativeApp calls from Java.
Kotlin-only compilation does not catch that.
Deleting a slot could never work. There was no delete entry point, so the picker
called java.io.File(getGamePathSlot(slot)).delete() -- and getGamePathSlot answers
OCCUPANCY, not a path. Its own declaration two lines below says so: "Not
getGamePathSlot, which answers a title id". So the call was
File("SHVH06660").delete(), which removes nothing and returns false. Every delete
failed, and the UI correctly reported that it had. Issue #80.
Added _rpcsx_deleteStateFromSlot, which resolves the file through
armsx3_slot_find, the same function load uses. That matters: the extension
depends on which build wrote the state -- .zst today, .gz and bare historically --
and building the path by hand is how this went wrong to begin with. The thumbnail
beside it goes too, best effort, so a removed state cannot leave a slot still
showing as occupied.
Saving arms after_kill_callback with Emu.Restart and then kills the VM. The
restart runs BootGame, whose restore_on_no_boot does ensure(IsStopped()) -- and
that overload accepts only stopped, loading or stopping. A Resume landing
anywhere in that window puts the state at running and turns the assert into a
process abort.
Issue #81, from the log: "Emulation has been resumed!" at 0:03:23.275950 and
"{Savestate Prepare Thread} Verification failed (object: 0x0)" at 0:03:23.275981.
Thirty one microseconds apart, on different threads.
Android makes the window far easier to hit than desktop. CallFromMainThread runs
its callback INLINE on the calling thread here rather than deferring it, so the
whole kill-and-restart chain executes on the savestate thread while the UI thread
stays free to resume underneath it.
Guarded on m_emu_state_close_pending, which is the emulator's own marker for that
window and is cleared on every failure path, so this cannot leave a game stuck
unresumable. Placed in Resume() rather than in the Android entry point so it also
covers the resume that surface-loss recovery issues.
discover_ether_address() reads the MAC with SIOCGIFHWADDR. Android has not let an
app do that since Android 6 and enforces it hard from 10 -- the ioctl returns
EPERM and /sys/class/net/*/address is unreadable -- so on every modern Android
device that branch failed, np_handler logged
NPHandler: Failed to discover ethernet or ip address!
and gave up. That leaves the network stack unidentified and blocks RPCN and any
game that asks it who it is. Reported as issue #79 against two unrelated titles,
with network settings that looked correct and could not have helped, because
nothing exposed in them reaches this.
The IP half was never the problem: it learns the local address from a UDP connect
to 8.8.8.8, which is a routing lookup and sends nothing.
Derive the address from Console PSID, exactly as the derive_mac_from_psid path at
the top of the same function already does. Nothing validates it against hardware
-- it identifies the console to the network stack and to peers -- and a locally
administered address is the correct thing to present when the platform refuses
the real one. Console PSID defaults to a per-install random value, so two users
do not end up sharing one.
Tried after the ioctl rather than in place of it, so a device or ROM that does
answer still uses its own.
"Is this submission finished" costs 1.9ms per call and returns not-ready 0.0% of
the time on Adreno 740 -- about 5ms a frame in Minecraft, a quarter of the RSX
thread. Measured with the profiler's own counters (fence polls 2.6/frame,
1903712 ns each).
That is the same signature this code already carries a comment about:
vkGetFenceStatus measured 19.7ms per call and never once returned VK_NOT_READY,
"a wait wearing a query's name". The zero-timeout vkWaitForFences that replaced
it is ten times better and still, evidently, a wait -- the driver appears not to
honour a zero timeout either way. That is driver behaviour, so which call is best
is a per-device question and not something to decide here.
ARMSX3_FENCE_POLL in driver_env.txt selects between them:
wait0 default, today's zero-timeout wait
status vkGetFenceStatus, what this used before
defer speculative callers do not ask the driver at all
The third is the interesting one. check_present_status walks the queued frames
looking for ones that have already finished and gives up on the first that has
not, and poke_all discards the result entirely -- neither wants to wait, so
neither should be the thing that does. They now pass allow_block=false. next()
and reset() keep the blocking form, so the command buffer ring cannot be starved
by this and "CB chain has run out of free entries" cannot fire because of it.
Default behaviour is unchanged. This ships as a lever rather than a fix on
purpose: the last renderer change justified by one game on one device was
reverted in 0.7.1 after wider testing, and the note on that revert asked for
pieces that come back one at a time with testing behind each. The profiler
already prints per-call timing, so each mode can be judged on the device in front
of whoever is testing.
89c6d08ed made untouched_expected a high-water mark to stop a silent port
resetting it every period. That fixed a measured, severe bug -- H.A.W.X. 2 ran
its audio clock at 55% of real time with the ring buffer permanently empty -- and
its own commit message flagged what was left unverified: whether anything depends
on the baseline falling again within a stable port configuration.
It does, and the mark latches. The fast path runs whenever untouched ==
active_ports, and stores min(max(untouched, expected), active_ports), so the first
fully silent period a title has pins the baseline at its maximum. From then on
`untouched > untouched_expected` can never be true and the loop stops waiting for
late ports for the rest of the session. Every game has a silent period.
Going back to upstream's instantaneous store is not the fix: that is exactly what
produced the H.A.W.X. stall. A port a game leaves started while writing only
zeros still flips the -0.0f tags, so it reads as touched on the few periods a
write lands in and untouched on the rest; following that dip drops the baseline
and the next period waits out the whole timeout, every flicker.
Hysteresis covers both, because the two differ in duration rather than shape. The
flicker is one period wide; a game that genuinely starts filling its ports stays
filled. Raise at once, lower only after the lower count has held for eight
periods -- far longer than any flicker, still a small fraction of the untouched
timeouts this feeds. For the H.A.W.X. case the behaviour is unchanged.
Bounded either way: the in_progress gate below is untouched, so no half-written
buffer was ever mixed by this. What the latch cost was the wait for a port that
had not started yet.
Issue #73: F1 Championship Edition silent since v0.8 except during videos, on
every audio backend. The reporter also notes the races run at 10fps and the
videos are "a bit choppy" -- so audio dies when the machine is saturated and
survives when it is not. That is a load correlation, not a code-path split, and
it rules out the theory that cellAudio is never reached.
cellAudio.cpp has no commits at all in the v0.6..v0.8 window. Across every audio
setting the Android UI writes, the only delta is the default backend moving from
Cubeb to Oboe, with a migration that moved existing users too.
Cubeb starts the OS stream in Open() and never stops it while open; its Play and
Pause only flip a bool. Oboe's call requestStart and requestPause for real, and
this backend asked for an Exclusive low-latency stream with a two-burst buffer --
4 to 10ms. An Exclusive AAudio stream holds the app to the callback deadline and
the platform disconnects it when that is missed for long enough, which at 10fps
is continuous. ARMSX2's own Oboe backend, same team and same device class, uses
Shared with a 4096-frame capacity.
Three fixes here:
Open() asks for Shared, and sizes the buffer from the emulator's own Desired
Audio Buffer Duration rather than a burst multiple. cellAudio fills ahead by that
much, so a stream that cannot hold it underruns however the trigger is set.
Play() started the stream AFTER committing m_playing, and never rolled it back on
failure. onAudioReady requires m_playing but a stream that never started does not
call it, so cellAudio's backend_active never armed, every block it enqueued was
discarded by the !backend_active check in enqueue(), and the early return at the
top of Play() made that permanent for the session. Start first, claim second.
Operational() answered `m_stream && !m_reset_req`, which is true for a stream that
failed to start or was disconnected -- so cellAudio's "backend stopped
unexpectedly" recovery never ran. It now reports the stream state.
Also: audio::configure_audio() is what turns a changed audio node into a rebuilt
backend, and its only caller is main_application.cpp, which is Qt and not part of
this build. Writing Audio Renderer changed the YAML and nothing else until the
next boot, so "try another backend" was a null experiment -- which is how that
issue collected three backends' worth of identical results. Call it from the
Android settings path, alongside the overlay resets that had the same gap.
And the "Audio Backend (advanced)" row only affects Cubeb, since cubeb_backend is
read once in CubebBackend's constructor. Under Oboe it did nothing while staying
interactive and showing a selection. Hidden unless the renderer is Cubeb.
The core is built for armv8.1-a and that is a floor, not a preference:
util/simd.hpp emits SQRDMLAH and util/asm.hpp carries inline LSE atomics. On
ARMv8.0 silicon -- Cortex-A53/A57/A73, so Exynos 9610, Snapdragon 660 and the
like -- those are illegal opcodes.
What the user saw was a bare crash. The fault is a SIGILL inside a static
constructor while the linker is still running libarmsx3-core.so's initialisers,
so it happens before any of our code can report anything, and the top frame names
a log-channel registration rather than a CPU problem. Because the core is
dlopen'd lazily, it surfaced at whatever first needed it -- issue #15 filed it as
"crashes when selecting the firmware .pup file", which is where the crash appears
and not what it is about.
Check /proc/cpuinfo for atomics and asimdrdm before that dlopen and report it.
Checked across every core listed, not just the first, since emulator threads are
scheduled on all of them.
Fails OPEN by design: an unreadable or unfamiliar /proc/cpuinfo returns null and
loads as before. Blocking a device that would have worked is worse than the crash
this replaces. Verified on a Snapdragon 8 Gen 2 that all eight cores report both
flags, so nothing changes there.
The reason is also held in unsupportedCpuMessage so a screen can show it later; a
toast is easy to miss for something this final.
The RPCS3 config database is maintained against desktop, so a fix specific to
this port has nowhere upstream to live. Add a small local map layered on top of
whatever the database says.
First entry: Tales of Symphonia Chronicles (BLUS31213, BLES01935) gets Frame
limit "PS3 Native". That is the only mode which honours the game's own
cellGcmSetFlipMode(CELL_GCM_DISPLAY_VSYNC) request -- every other mode flips
immediately, so a title pacing itself by flipping on alternate vblanks free-runs
to the 60 cap, which is issue #77: 60fps in a 30fps game and battles at double
speed.
Applied in three places because none of them alone is enough: after refresh(),
which clears the directory before writing; after setEnabled(), which moves the
whole directory aside; and at startup, so it works for users who never downloaded
the database at all. Merged rather than overwritten, and skipped entirely if the
database already sets a Frame limit for that title.
UNVERIFIED against the reporter's device. The mechanism is read from the code,
not measured, and the failure mode matters: PS3 Native applies NO limit when a
game does not request vsync, so if this title turns out not to, it would run
unbounded rather than capped at 60. Drop the serials from the map if the reporter
says it is worse.
PS3 Native is the only Frame limit mode that honours the game's own
cellGcmSetFlipMode(CELL_GCM_DISPLAY_VSYNC) request: in handle_emu_flip every
other mode falls through and flips immediately, while that one defers the flip to
a real vblank. A title that paces itself to 30fps by flipping on alternate
vblanks therefore free-runs to the 60 cap under Auto, our default -- reported in
issue #77 as Tales of Symphonia running at 60 and battles playing too fast.
The mode already existed and Rpcs3Settings could already write it, but nothing
reachable from the UI ever did: the only control is the Display FPS Cap row,
which maps to numeric presets or Second Frame Limit. It was reachable solely as a
raw core override. That also explains the reporter's follow-up -- capping by hand
does slow the game, but through the wall-clock limiter, which pushes flips off
the vblank boundary and brings tearing and audio glitches with it.
Added as -1 in that row rather than as a new setting, since it is mutually
exclusive with a numeric cap. Both clamps on the way to the core floored at 0 and
would have quietly turned it into "no cap".
setFrameLimitEnabled needed the same widening. It runs last, so its `cap > 0`
test read -1 as "no explicit rate" and wrote Auto back over PS3 Native -- the
collision its own comment describes, one value along.
Deliberately NOT the default: with no vsync request from the game this mode
applies no limit at all, so titles that never ask for vsync would run unbounded.
Both sat inside set_transform_program, the handler upstream rewrote for
ROP_OUTPUT_REMAP. Resolving that conflict took upstream's version as the base and
re-applied our profiler scopes, which put the scopes back and quietly dropped
these.
The first is the one that matters. e13fc184f made the redundant vertex program
check actually compare: the destination holds each word byte-swapped individually
by copy_data_swap_u32, while be_t<u64> swaps all eight bytes and so also exchanges
the two words. Without the rotl the check compares (w0,w1) against (w1,w0), which
can only match when w0 == w1 -- so it never fires, and every single upload marks
the ucode dirty. That forces a vertex program re-analysis, a program cache hint
drop and a full transform constant re-upload on every draw.
That is a per-draw cost on the RSX thread, restored to 0.9.4 by the merge after
being fixed, and it fits issue #78: Wipeout HD Fury reported as much higher CPU
and far worse performance on 0.9.4 than 0.9.3, with no other change in the window
that adds per-draw work.
The second is g_xform_program_words, which the profiler divides by
g_xform_program_calls to report average batch size. Losing the increment prints 0
rather than printing nothing -- exactly the failure mode I checked for on the
transform CONSTANT counter during the same merge, and missed on this one.
ISO.cpp, the other conflicted file, was checked the same way and lost nothing.
ARMSX3_PIPELINE_CACHE=0, read through driver_env.txt like the compute group size
override, so a suspected regression can be A/B'd on a single build.
Issue #78 reports Wipeout HD Fury running far worse on 0.9.4 than 0.9.3 with much
higher CPU. That window holds 28 commits, and most of them only remove work, so
the plausible suspects are this cache, the upstream ROP output remap, and the ISO
reader revert. Guessing between them is not worth a release each.
This one is worth being able to eliminate first because it is the only change that
introduces a structure shared between threads that previously shared none: up to
eight shader cache loader workers at boot, plus the async pipeline compiler
workers during play, all now insert into one VkPipelineCache. Concurrent use is
permitted by the spec, but the driver still has to serialise its own inserts.
Not evidence that it IS the cause -- it is the cheapest candidate to rule out.
2026-08-21 00:14:00 -04:00
210 changed files with 117842 additions and 543 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
jpolo1224