ElfReader::ReadProgramHeaders checked that a PT_LOAD's file size does
not exceed its memory size, but not that its file range lies inside the
input. The Windows and macOS writers reject such a segment later; the
Linux patcher keeps the original PT_LOADs and appends its own block at
the old end of the file, so a load reaching past the input mapped the
relinker's .dynstr, .dynsym and entry stub into the guest segment.
A PT_SCE_RELRO that no PT_LOAD covers is turned into a PT_LOAD after
the per-header checks, so it skipped them: a file size larger than its
memory size was accepted for Linux, and Windows and macOS reported a
file-range error instead.
Reject a PT_LOAD whose file range exceeds the input, and run the same
two checks on an uncovered PT_SCE_RELRO before converting it.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01P9JfvrCsztJtbkd5SATAzL
AstroBot's import log (issue #4720) names sceRegMgrNonSysGetInt as the
only libSceRegMgr export it needs; no other RegMgr export appears in
its 1909 unique imports. The signature and NID are sourced from a
community dump of PS5 3.20 firmware, cross-checked against the
open-source ChonkyStation4 emulator, not from Sony documentation, so
the export throws per the project's unknown-behavior convention
instead of guessing a return value.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
The settle queue on another family is only created under _WIN32, so on
Linux the test always skipped with a reason check_skips does not accept
and the linux job failed on every main build since #6060.
Co-Authored-By: Claude <[email protected]>
Dropping an unused stencil reference export changes the pixel variant key, so
a device that has the extension would compile a second variant and pipeline
for a shader drawn both with and without a stencil test. Only a device that
lacks the extension needs the drop, so the draw decode now checks the device's
capabilities first.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
TranslateReversedBlend may write 1 into a channel of the first color
whose source factor is ONE and take that channel's export into the
factor through the second color, when one second color cannot carry
both the source and the destination factor. None of the blends in
agc_driver_reversed_order_blend took that route, so no GPU test ran it.
The test now also blends 0x61010504 (SRC_ALPHA + ONE_MINUS_SRC_ALPHA,
alpha ONE + ONE), whose alpha channel is routed that way, into both
formats with both reversed swaps, and compares it with the exact blend
and bit for bit with the same draw into a SWAP_STD target. It passes on
an RTX 5080 and lavapipe. With 9a8816126's shader-computed factors it
fails on the RTX 5080: 160 where SWAP_STD stores 159.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The reversed-order blend computed the factors Vulkan cannot apply per
channel in the pixel shader (1 - x in fp32, a clamp for UNORM targets
and, when both positions needed it, a premultiplied export) and passed
them to the blend as a dual-source second color. A plain blend converts
the export once and forms 1 - x and the products from that converted
value, so the two paths can round differently. On UNORM8 the difference
reaches one step per substituted factor: an Intel iGPU stored 161 where
the exact blend is 159.75 for SRC_COLOR + ONE_MINUS_SRC_COLOR with an
export of 0.5 over 192 (160 through SWAP_STD), and on an RTX 5080 and
lavapipe the split path differed from the same draw into a SWAP_STD
target by up to 2 steps on other inputs.
The pixel shader now only copies values. Each channel of the second
color is the exported alpha, the channel's own export or the constant 0
or 1, and a channel of the first color whose source factor is ONE may
become 1 with its export moved into the factor. Every factor, 1 - x and
product comes from the blend through SRC1_COLOR, SRC1_ALPHA and their
ONE_MINUS forms, applied to copies of the same export values that the
first color carries. TranslateReversedBlend searches for Vulkan factors
and copy routes that reproduce each channel's guest factors and throws
for combinations no routing reproduces, such as ONE_MINUS_SRC_ALPHA in
the alpha equation next to SRC_COLOR in the color equation: of the 1995
factor combinations the shader used to compute, 932 are routed and the
others throw again, as on main. GT7's 0x65010504 is among the routed
ones. The code is now four 2-bit routes for each color, the same for
every format, and the post-pass emits no arithmetic.
agc_driver_reversed_order_blend also draws each case into a SWAP_STD
target, which Vulkan blends alone, and requires identical stored bits;
the comparison with the exact blend keeps its 1-step tolerance.
agc_driver_graphics checks every factor combination TranslateReversedBlend
accepts against the guest equations and that the post-pass adds no
arithmetic instructions.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
8_8_8_8 and 16_16_16_16 targets with COMP_SWAP 2 or 3 keep the exported
alpha in their first channel and red or blue in their fourth, so a plain
Vulkan blend would run the alpha equation on a color channel. Such draws
threw "blending into a color target with a reversed component order is
not implemented" (Gran Turismo 7, #4782).
The AMD SI and CIK register references describe CB_TARGET_MASK in the
order of components after blending and before COMP_SWAP is applied, and
RADV programs CB_BLENDn_CONTROL without regard to the swap while it
renders R4G4B4A4, B4G4R4A4, R5G5B5A1 and B5G5R5A1 through SWAP_STD_REV
and SWAP_ALT_REV and passes the CTS blend tests on Navi10. The color
block is therefore taken to blend in export order: the alpha equation
and source-alpha factors use the exported alpha and the destination
alpha is the first channel.
TranslateReversedBlend keeps the factor pairs Vulkan applies per channel
in the pipeline. Other source factors are computed by the pixel shader
from its MRT0 export (clamped for UNORM targets, as BLEND_CLAMP says)
and handed to the blend as a dual-source second color, which the
fragment output post-pass adds at location 0 index 1; when both
positions need it, the export is premultiplied by its source factor.
The code is a pipeline specialization, serialized in request version
26, and stays out of the prepared shader key.
sRGB, SNORM and integer targets, constant and second-source factors,
destination alpha in the color equation, destination factors the two
equations do not share, different color and alpha operations, MIN or
MAX with factors other than ONE, other color exports when the shader
computes factors, and devices without dualSrcBlend still throw, now
with the blend control, mapping and format in the message.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Exercise ALWAYS with KEEP and INVERT using the existing pixel program and complete color and stencil readbacks. Keep dependent comparisons and replacement operations behind the existing native extension refusal.
Co-Authored-By: Codex <[email protected]>
A pixel shader with DB_SHADER_CONTROL.STENCIL_TEST_VAL_EXPORT_ENABLE needs
VK_EXT_shader_stencil_export, which NVIDIA's driver does not offer. In a draw
without a stencil test the exported value has no effect, so the draw decode
drops the export there. On a device without the extension, the pixel shader is
no longer prepared when its ABI is resolved, where the draw's stencil test is
not known yet; it is prepared at its first draw.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Queue 0 now pipelines draw commits unless APS5_PIPELINED_DRAWS=0, and draw write ranges use the exact
color, DCC, CMASK, depth and stencil sizes unless APS5_EXACT_DRAW_WRITES=0. The base tests now run the
pipeline; agc_driver_pm4_failure_inline and agc_driver_draw_cache_reuse_inline keep the inline path
covered.
Co-Authored-By: Claude <[email protected]>
With APS5_PIPELINE_DMA=1 a DMA_DATA was enqueued before the
packet path's metadata notes ran, so a fill of 0 over a depth surface's HTILE (#374) or a color
target's CMASK (#419) never reached the surface: agc_driver_depth_fast_clear_submit failed. The
queued commit now notes the fill in order before it stores it, and a DMA copy is checked against
multisampled targets at enqueue, as on the packet path.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
(cherry picked from commit fda7dbf0416fe91ea4767ad2e94ba63b530c1dc2)
Track successful releases cumulatively across the complete depth and HTILE ownership ranges. Preserve color retirement and share its single callback; keep retired image contents alive through sampled views and recorded work. Add registry, partial/failure/protection, remap and mixed teardown regressions. Depends on native depth sampling in PR5496 and its descriptor prerequisite PR4820.
The eager-writeback commits added StorageTexture::StoreAtLabelRequested
(APS5_STORE_AT_LABEL). Nothing reads that variable, so the helper is dead
code; the deferred-writeback revert kept it by accident. Remove it so the
PR changes only the staged-clear sampled-read flush and its test.
The commit lambda held raw pointers into the draw's stage-data hits and compiled stages, which
were freed when the worker returned (agc_driver_draw_cache_reuse with APS5_PIPELINED_DRAWS=1).
Co-Authored-By: Claude <[email protected]>
Keeping it made evictOldest read the front of an empty deque (agc_buffer_pool aborted with a
double free) and stopped Take at an empty class instead of trying the next size.
Co-Authored-By: Claude <[email protected]>
A pattern fill reads its count and pattern from guest memory on the queue worker. With pipelined
draws it read them while earlier commit items that write them (labels, DMA stores, draws) were
still queued, so it stored the stale value (agc_driver_pattern_buffer_fill under load). It now
drains the draw pipeline first when a queued item writes one of its input ranges.
The same fill held the GPU lock from the input read through DrawPipeline::Enqueue. With the
pipeline full, Enqueue waited for the committer while the committer's next item waited for the GPU
lock: a deadlock. The input lock is released before the fill is queued, and Enqueue throws when it
would wait for room while the calling thread holds the GPU lock.
(cherry picked from commit c653e9ea1d1030ebf691015b30ea04f1cdd59ef8)
enqueueLabelPacket lacked the empty-deferred-labels guard that enqueueDmaPacket and the draw path
have. A predicated WRITE_DATA is never enqueued, so it is deferred on the worker; an unpredicated
WRITE_DATA to the same address that follows it was enqueued and committed first, and the deferred
store was recorded after it, leaving the older value (an EOP interrupt could fire out of order the
same way). With the guard the later label takes the packet path, which drains and orders it behind
the earlier one.
(cherry picked from commit 1f894c9b641da3460b684a8356655fbf1aeee635)
A predicated draw, dispatch or register packet stays on the pipelined keep list, so it did not drain
before the worker read its predicate. A WRITE_DATA or label to the predicate address, queued behind
earlier commit items, was not stored yet: SET_PREDICATION on P, WRITE_DATA P = 1, then a predicated
dispatch skipped it as if P were still 0 (and ran it when P was cleared). The worker now drains the
draw pipeline first when a queued item writes the predicate's bytes.
(cherry picked from commit 56b94480b3de04dfb5c4f4a1bfc5731df59eae29)
The note landed ahead of the draws still queued over that depth surface.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 41f385acbf8da99fdf3f8a8c0bd9a8802383d05f)
A capture already drains first; validation compared the runs with guest memory while a queued draw could still write them.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit a9c15be3e1c27e48b2e6a04e44c47dd5203a3057)
The resolve, CMASK and DCC passes read the color target on the worker while queued draws could still be writing it.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit c50e23120c5f139d3e11391b78b9ab228acee2c0)
The pipelined label path treated every nonzero RELEASE_MEM INT_SEL as an end-of-pipe interrupt;
main's PacketMemory excludes 3 (send data after write confirm). agc_driver failed on it with
APS5_PIPELINED_DRAWS=1 ("release with INT_SEL send data after write confirm raised an interrupt").
Co-Authored-By: TheAggie <[email protected]>
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
DrawWriteRanges decoded every written storage image element, and DecodeTextureResource refuses a zero
base address, so a draw with a null storage image bound failed (PPSA01317) instead of skipping it.
The element is now skipped by the binder's own null rule (base address words zero) before it is
decoded. agc_driver_draw_write_ranges binds a null image next to a written one.
Co-Authored-By: Gjon Gojcevic <[email protected]>
Co-Authored-By: SleglJan <[email protected]>
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
With APS5_PIPELINED_DRAWS=1, queue 0's worker decodes, captures and recompiles a draw and hands it to
a committer thread that records it (Graphics::Draw under the GPU lock), so the two run in parallel
instead of one after the other. Work the committer has not reached yet is tracked by the guest ranges
it will write; a later packet that reads or writes them, or one the pipeline cannot order, drains it.
Ordered as commit items instead of drains:
- labels (WRITE_DATA, RELEASE_MEM) and same-queue waits on them; APS5_PIPELINE_DRAIN_LABELS=1 drains;
- the end of a queue-0 submission and a released REWIND tail; APS5_PIPELINE_DRAIN_SUBMISSIONS=1 drains;
- the title's buffer fill kernels; APS5_PIPELINE_DRAIN_FILLS=1 drains;
- DMA_DATA immediates and copies (APS5_PIPELINE_DMA=1).
A draw's write ranges include the storage images it writes and its exact color and depth target
ranges (APS5_EXACT_DRAW_WRITES=1), not estimates.
Draw-path costs the pipeline exposed:
- ShaderMemory moves, so a commit owns its capture's pages;
- a submission made before the worker's current collect epoch began keeps the epoch, so a worker
behind a queue of submissions walks a surface once per catch-up (APS5_SUBMISSION_EPOCH_EACH=1 bumps
at every submission); a thread remembers the ranges it walked for the whole epoch;
- the pipeline signals only threads that wait; the pending-image and unit-shadow registries take a
spinning slim lock instead of std::mutex (winpthreads contention was kernel events); ScanPending skips
the registry walk when no pending image can overlap;
- fewer heap allocations per recorded draw (reused descriptor sets and scratch vectors, buffer pool
size classes kept).
GTA V Performance mode, prologue bank interior, RTX 5080: 11.7 -> about 20 fps together with the cheaper
captures below it.
Off by default here; the follow-up turns it on.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Co-Authored-By: Gjon Gojcevic <[email protected]>
When the address came during the wait, the host receive that followed
waited its whole SO_RCVTIMEO again, so a receive could take up to twice
the timeout. FreeBSD's soreceive_dgram sleeps once per timeout. Now the
receive waits for a datagram with WSAPoll only for what is left of the
timeout, and fails with EAGAIN when it runs out, as before. Nothing
changes when the socket already had an address or has no timeout.
The device tier of the buffer pool kept an eighth of the device-local heap (2 GiB on a 16 GiB card) whatever VK_EXT_memory_budget said the process may use. Its budget is now the smaller of an eighth of the heap and an eighth of the reported budget, at least 512 MiB; APS5_STAGING_POOL_MIB still overrides it.
(cherry picked from commit b039e1da12d7cedc3bfdf0c1d3c0c354f3cd58aa)
