XairRrR's review: PendingChainCase draws without depth writes, so its
retire has no unstored depth. The new case draws depth 0.5 that is only
on the GPU, writes level 1 of a two-level chain over the plane, takes the
view (which retires the surface) and flushes the storage write. Level 1
in guest memory must match a run without the depth write, and level 0
must hold the drawn depth.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A sampled view that a live depth surface's plane cannot serve (another
layout, more levels) is left to guest memory when a later write retired
the surface, and refused while the surface is the last writer of its
memory. Only writes the CPU can see counted. A compute pass that writes
storage images over the plane is a later writer too, but its results
stay pending in storage images, so the surface still looked current.
Forspoken (PPSA03984) builds a 5-level R32 float chain over the memory
of its 1920x1080 D32 depth target. When it sampled the whole chain
before those results reached memory, it stopped on "sampling the depth
plane ... levels 0-4 ... is not implemented". A pending storage result
over the plane now retires the surface for such a view, as a CPU write
there does.
PendingChainCase writes level 1 of a two-level R32 float chain over a
plane with a compute dispatch and flushes it, so the chain's storage
image exists, as the title's does from frame to frame. It then draws a
D32 surface there, writes the chain again and leaves the result pending.
A two-level view must then be left to guest memory with the depth
surface retired. On main the view is refused with the title's message.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
libSceAgcDriver.prx failed to load in the patched library check with an undefined symbol for HostCpuModel, because the host report called libkernel's plain C++ functions, which the patched libkernel does not export to it. The report now calls the extern C helpers and splits the joined feature list back into names.
The presentation drew the system keyboard from SystemOverlayView and laid it out
inside its own recording. It now asks SystemOverlayLayout for the system panel
at the swapchain extent, which is already validated by then, and records
whichever of the keyboard and the dialog is set through the same overlay pass
and layout transitions. Presentations with neither set are unchanged.
agc_keyboard_overlay_tests now checks the message wrapping (column limit, long
words, line breaks, surrogate pairs, the dots on an overlong message), the
layout of one to three buttons at four target sizes (inside the screen, centred,
buttons in order and not overlapping, the accent border on the focused button),
a long message and a narrow target, the refusal of zero or four buttons and of
an empty target, and the storage of the dialog with the keyboard taking the
overlay from it.
LayOutDialog turns a ModalDialogView into the same rectangle list the system
keyboard uses: a centred panel, the message word-wrapped to 36 columns and at
most 8 lines (the last one ends in dots when the text is longer), and one to
three buttons in a row with an accent border on the focused one. The scale
follows the keyboard's rule and shrinks until the panel fits the target.
AgcDriverSetSystemDialog stores the view for the presenter, and
SystemOverlayLayout returns the keyboard's layout when a keyboard is set and the
dialog's otherwise, so only one system panel is drawn at a time.
On NVIDIA's proprietary driver, function arrays that live in local memory
and are read under a data-dependent branch return wrong values in
subgroups 1-3 of a mesh workgroup; subgroup 0 is correct. A wave64
geometry program whose relative addressing keeps its VGPRs in the vector
window therefore loses register writes in every wave but the first. In
the clipping geometry program of Sony's PS5 PSP emulator (PPSA07550) the
empty waves never cleared their candidate primitive slots and wrote
degenerate triangles over wave 0's, so the 3D menu drew spikes.
On that driver a mesh program's window now lives in a device-local
storage buffer of 256 workgroup slots of 65536 dwords, claimed through a
per-slot lock and released after the final barrier. The pool is created
before the first draw that uses it records anything, and its header is
zeroed in a batch of its own that is submitted and waited for; the pool
is published only after that wait, and a failure releases it. Direct
register accesses keep one function variable per register; a direct
store also writes the buffer when a buffer read can see it, relative
reads load the buffer, relative writes store only to it, and a direct
read that may follow a relative write loads the buffer and refreshes the
variable. A buffer entry is zeroed only when a buffer read can see it
before a write. APS5_NO_MESH_WINDOW_BUFFER=1 keeps the arrays.
On a host whose imports are compared instead of write-watched (Linux
lavapipe CI resolves write protection, so PrepareImportWatch picks
Unwatch), the surface is not covered by write tracking, the fast proof
stops at its write collection before the pending scan, on main as well,
and T1 is never tried. The test required the own-object refresh on every
host, so it failed there.
Each case now asks GuestMemory whether write tracking covers the
surface. Where it does, the own-object refresh is required as before;
where it does not, the set must still be proved current and keep its
view.
Co-Authored-By: Claude <[email protected]>
Adrià