refreshImports checked every live host import, failure and refusal
again at each guest allocation registry change. A title that maps
memory often (SuperTuxKart, ~1650 maps a second) paid a walk that grew
with the live imports: ~34 FPS with ~1.1 GiB of imports on RADV.
The import table now keeps a weak_ptr snapshot of the ranges it was
last checked against and diffs it with the new lease. Only imports
whose import window touches a changed span, and imports made since the
last refresh, are checked again. Every import is checked when the window
is 0 or the window or budget changed. SuperTuxKart's menu goes from
~34 to ~45 FPS with the same imports live.
The modules these entries were read from record SDK 13.60 (0x13600007)
in their module-param segment, so they are firmware 13.60. Only the
version label changes; the behaviour described is unchanged.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_013XFS3FUfBtqCVfwmBrRQ6q
be write-watched at the initial import ("native FMASK contents require
watched guest memory") and at each reuse ("native FMASK sampling requires
watched guest memory"). In Linux comparison mode a host import over the
FMASK unwatches it, so the target is refused one check after the color,
DCC and CMASK ranges that the previous commit accepts.
Treat an FMASK range that a compared host import covers
(ComparedHostImportCovers) as the color and metadata ranges are treated:
keep a copy and its NewestStamp at the initial import, skip it in the
import's UnchangedSinceAll, and at reuse require the stamp and the bytes
to be unchanged, comparing them at most once per collect epoch. An
explicitly unwatched FMASK range is still refused.
Four-sample targets take no FMASK range, so this changes nothing for them.
Refs https://github.com/boykopovar/AnyPS5/issues/9724
Rush 2 Recompiled (PPSA69423) and Wave Race 64 Recompiled (PPSA69424)
stop with "AGC graphics: initial multisampled DCC contents require
watched guest memory"
(https://github.com/boykopovar/AnyPS5/issues/9724). On Linux with
lavapipe, the write-watch probe finds that device accesses to a host
import trip the write watch, so every imported range is compared rather
than watched. A multisampled DCC target whose color, DCC or CMASK range
lies in such an import was then refused at its first draw: importing the
target takes a write generation for each range, and a compared range has
none.
A range that is not watched but lies in a live host import the probe
compares is now copied when the target is imported, and its metadata
again when a whole fill is taken as its fast clear. Each later use
compares the range with that copy, at most once per collect epoch, and
counts any driver or GPU store over its 64 KiB blocks since the copy as
a write, so a guest store of new bytes or any store by the driver
refuses the resident target as a watched range does. A range left
unwatched outside such an import is refused as before.
This covers the Linux comparison mode, not the Windows deferred settle
(BF-150): compared imports on Windows still refuse.
GFX11 renumbers the image formats past 29, so the raw codes 10, 37 and 1
read as other formats on the console's GFX10 numbering (37 is
11_11_10_UNORM there, 2_10_10_10_SNORM on gfx1100). Name them, and say
why the TYPE 9 depth compare control only answers at 32_FLOAT: gfx1100
compares 16_UNORM and 32_FLOAT only and answers zero for the others.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The entry recorded TYPE 1 only from a gfx1010 measurement with format 22 and left other formats and
depth-compare reads open. Measured on a gfx1100 with the hardware oracle: image_sample_lz,
image_sample_b, image_load, image_sample_c_lz and image_get_resinfo return zero and no fault for
TYPE 0 and TYPE 1 over formats 22, 10, 37 and 1, with a nonzero base over readable memory and with a
zero base. A TYPE 9 control in the same kernel returns the stored texel, the raw dword, the declared
64 and 32, and 1.0 from image_sample_c_lz with an ALWAYS depth compare and format 22.
Co-Authored-By: Claude Opus 5 <[email protected]>
On a PS5 the builder writes 15 dwords: a tag write of 0xc6000006, opcode 0x3a with its arguments, initiator 0x80 whatever the modifier, and a closing tag write; GetSize returns 60. AnyPS5 wrote NUM_INSTANCES and DRAW_INDEX_2 under argument meanings nothing confirms. The driver refuses 0x3a, whose field meanings are not known, and names it DRAW_INDEX_MULTI_INST as Linux's nvd.h does.
A delta read its blocks with ReadCommittedUnsynced while GPU work
accepted before the call could still write them, so a capture could
hold a block from before a DMA copy that the replay then wrote back over
the copy's result. A delta with blocks to read now waits up to 10 s for
the accepted submissions and records the serials after the wait; the
capture stops with a warning when the work does not finish. The Windows
quarantine of agc_driver_frame_replay is removed.
Fixes#10711
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Dean