NVIDIA's Windows driver reads a host import of guest memory far slower than a buffer it allocated.
Since draw vertex and index ranges are bound in place from host imports (#2253, measured on Linux), Astro
Bot's Crash Site on Windows 11 with an RTX 5070 Ti spends 164 ms of every frame in draws on the GPU, and
45 ms with the ranges copied as before; with the same build, 4.71 fps in place against 7.52 copied. An
RTX 3060 shows the same (draws 32.3 against 24.3 ms per frame), while AMD's Windows driver reads them in
place about as fast as a copy (RX 9070 XT: 69.8 against 73.1 ms), so copying there only costs CPU.
The device decides once (DrawInputsInPlaceUsable, Context::drawInputsInPlace): ranges are copied with
VK_DRIVER_ID_NVIDIA_PROPRIETARY on Windows and bound in place everywhere else. APS5_DRAW_INPUTS_IN_PLACE=1
binds them in place and APS5_NO_DRAW_INPUTS_IN_PLACE=1 copies them on any device, the second winning.
agc_draw_inputs_in_place_driver checks the decision per driver and host; agc_draw_inputs_copied checks
that an aligned imported range is copied and its read not noted when the context copies, whatever the
inherited environment.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GN8FJFTedayRXLHythXkZ4
A CPU read of DISPATCH_INDIRECT arguments waited only through the flush
hook, which waits for the ranges recorded work noted as pending writes.
An address-based store (FLAT/GLOBAL, or through a descriptor the
recompiler cannot resolve to a static buffer) is not recorded as a
pending write: its batch leases the registered allocations, and only the
guest pin waiter finished that batch. So the thread-dimension,
misaligned and disabled paths, the fill-kernel path and the device's CPU
fallback read the arguments from before an address-based producer ran.
GTA V (PPSA04264) dies loading Story on such a read: a 64-thread clear
kernel read {160, 288, 0xffffffff} as thread dimensions
(3x288x4294967295 groups), bytes its 1-thread setup kernel had not yet
overwritten with {n, 1, 1}, and threw "workgroup count
3x288x4294967295 exceeds device limits".
Every CPU read of dispatch arguments at execution now first finishes the
recorder up to the newest batch recorded with a lease
(Graphics::FinishLeaseWork). The group read-ahead still reads without
waiting; a dispatch it resolved is adopted only when the execution-time
read gives the same counts, and one that differs is dropped and counted
in the [groupcap] line. The device limit error names the argument
address and cpuReason, and the driver adds the queue, path and
read-ahead outcome. The [indirect] read time includes the lease wait,
and the [recorder] sync-site table records the offset of
FinishLeaseWork's caller. The CPU reads that still miss address-based
writes (indirect draw arguments and count, the copy kernel's count
record, the awaits-title checks) are listed in the technical debt.
IndirectArgumentsPendingProducer covers the execution-time CPU argument
reads on compute queues and the pending-label CPU fallback in the Vulkan
device. Its sixth case records a real argument label behind a host Vulkan
event in an earlier batch and an address-based producer in the later open
batch. The event releases only after that producer batch is submitted;
a bounded watchdog releases for cleanup but fails the case. It requires
a deferred producer lease, an unsubmitted producer at the argument
decision, cpuReason 2 and the fresh arguments and counter result. Small
valid stale counts keep a broken-wait control finite on every driver.
Exact CPU-reason and watchdog diagnostics identify the failing path. This
replaces a spinning workload whose earlier label could retire before
the fallback decision on lavapipe, allowing a false green with cpuReason 0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Codex <noreply@openai.com>
Image and sampler table capacity came only from the regular descriptor
limits. MoltenVK reports Metal's argument table limits there (256 sampled
images and 16 samplers per stage), below the typed heaps the tables are
reserved on top of, so both capacities were 0 and every table draw or
dispatch was refused as if the device lacked descriptor indexing. Its
update-after-bind limits are 1000000 sampled images and 500000 samplers.
- descriptorBindingSampledImageUpdateAfterBind is queried and enabled, and
the update-after-bind limits are read when either it or the storage
buffer feature is present.
- A table whose regular capacity is 0 takes its capacity from the
update-after-bind limits. Its binding is update-after-bind and its set
layout and pool are update-after-bind ones, in ShaderResources and in
DescribeSetLayouts alike. A table that fits the regular limits is
unchanged.
- An update-after-bind set layout and its allocation are checked against
the update-after-bind sampled image and sampler limits when the device
has descriptorBindingSampledImageUpdateAfterBind. Vulkan counts the
descriptors of such sets against those limits in place of the regular
ones, and requires them to be at least the regular ones only when the
feature is supported, so without it, and for storage images, the
regular limits are kept as before. Storage buffers keep their own
update-after-bind flag.
- Compute pipeline capture and replay accept update-after-bind sampled
image and sampler bindings.
Filled rectangles (VGT_PRIMITIVE_TYPE 7 and 17) use the same single-sample MSAA_ENABLE path as triangles; PPSA03541 stops on a rect-list draw otherwise.
Co-authored-by: Cursor <cursoragent@cursor.com>
Use representable viewport endpoints only when the draw has no depth attachment and its pixel shader does not read PositionZ. Preserve XY coverage, clip-space mode, depth clamping, and validation of non-finite inputs.
Balatro (PPSA21402) reaches rendering on Apple M1 with MoltenVK after this change instead of stopping at VK_EXT_depth_range_unrestricted. Depth-dependent draws retain their original behavior.
releaseTrimmed freed the trimmed import's memory at once when the
calling thread did not hold GpuMutex. It now hands the memory to the
active recorder whenever there is one, as retireImport does for the
imports importRunAt and refreshImports retire, so the memory outlives
the open batch and every batch submitted before it.
A protect or unmap strictly inside a plain host import still retired the
whole import, and the next access imported both sides of the cut again.
The larger side is now kept as a trimmed import, as a cut at the head or
the tail already is, and only the smaller side is imported again. Equal
sides keep the tail.
recordDispatch now reads its indirect offset through HostImportOffset,
which adds the import's lead. The unchecked path passes that offset to
vkCmdDispatchIndirect; the clamp kernel reads from import.address plus
the guest offset, since import.address already includes the lead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Primitive type 19 (DI_PT_QUADLIST, 0x13) is used by Unity and other engines for UI quads, sprites and font glyphs. Because Vulkan lacks native quad-list primitive topology, quad draws are expanded on the CPU into indexed triangle lists with 6 indices per 4-vertex quad, respecting the first/last provoking vertex configuration and discarding incomplete trailing vertices. Adds unit tests and documents the functional debt.
Devices with DenormFlushToZero for f32 run the mixed denormal-flush programs with and
without the hardware mode at startup; when every result matches, add, sub, mul, fma,
floor and ceil in the default rounding mode drop their software flush.
A dispatch over maxComputeWorkGroupCount was split into vkCmdDispatchBase
chunks whose base reached the limit, which VUID-vkCmdDispatchBase-baseGroupX-00421
forbids, and NVIDIA refused the split outright.
Compute modules now declare WorkgroupOffset specialization constants (default 0)
that the recompiler adds to WorkgroupId and GlobalInvocationId and keeps
unmaterialized. Each chunk is recorded with vkCmdDispatch from group 0, bound to
a pipeline variant specialized with the chunk's base. The NVIDIA throw is gone;
device-memory LDS splits still throw.
Fixes#7375
A draw on the mesh path was validated before its pipeline checked for
mesh shader support, so on a device without VK_EXT_mesh_shader (an RDNA1
RX 5700 XT) Sackboy: A Big Adventure (PPSA01289) stopped on "subgroup
capability 61 is unsupported for shader stage 128" instead of the actual
cause. ValidateShaders now takes the device's mesh shader support and
refuses such a draw first with "device does not support mesh shaders".
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A depth target's bind (storeBackClearedHtile) reads its HTILE words to find a fast clear and
stores them back expanded. When a recorded fill over the HTILE was still pending, that read
made the flush hook submit the open batch and wait for the GPU, under the GPU mutex. A title
that clears its depth targets with buffer fill kernels pays that wait at every clear.
Uniform fills now note their 32-bit word with the pending write (NotePendingWordFill; the byte
value the DCC key paths use is unchanged). When every pending write over the HTILE is such a
fill and the rest of the range already holds the same word, the bind takes the landed word
from the notes, and stores the expanded words as a GPU fill recorded behind the pending ones.
Any other pending write keeps the read. APS5_NO_PENDING_HTILE_FILLS=1 always reads.
PPSA12544 on a Radeon 780M (Windows): 1271 pending-write syncs per 10 s waited 5.5 s at the
bind, about 4.3 ms each; with this change there are none, and the scene runs at 60-61 fps
instead of 44-46.
PPSA08270 (Eternights) stopped after its story intro with "AGC graphics:
CB resolve from a target whose sample count differs from the
rasterizer's". It resolves a 4x 512x512 target into a single-sample one
with PA_SC_MODE_CNTL_0.MSAA_ENABLE off while PA_SC_AA_CONFIG still holds
2x from earlier draws. Without MSAA_ENABLE the scan converter does not
use PA_SC_AA_CONFIG's sample count, so the resolve takes its sample
count from CB0 as it already does when PA_SC_AA_CONFIG is single-sample.
Adrià