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 <[email protected]>
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 <[email protected]>
Co-Authored-By: Codex <[email protected]>
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.
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.
RADV initializes and fast-clears DCC keys with its fill_memory compute
kernel, which stores through a global address. Run as an ordinary
dispatch, its stores name no range. The DCC key tracking therefore saw
a key fill only once it had landed in guest memory, which could be
after later writes to the surface had already been recorded.
vkQuake (PPSA99010) hits this on every item pickup:
- the scene renders into a second color buffer;
- RADV's UNDEFINED -> GENERAL barrier fills color buffer 0's keys with
DCC_CLEAR_0000;
- a screen-effects compute pass writes color buffer 0;
- the UI pass draws on color buffer 0.
The keys landed while the UI pass was being recorded. The refresh took
them for a clear made after the compute pass, dropped its results and
cleared the image to black. For the length of the pickup flash the
scene was black, with only the HUD drawn.
The fill HLE now matches the 16-byte variant of the kernel as a fill of
min(threads * 16, user[4] + 16) bytes. The kernel takes its address in
user[2..3], its largest store offset in user[4] and its value in
user[5]. A key fill through it is handled where it is in the command
stream.
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 <[email protected]>
A DMA_DATA whose destination is nowhere writes no memory, so the draws ahead of it have nothing to order against. RADV issues one per draw, and each drained the pipeline and idled the queue worker until the committer caught up.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
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 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.
A radeonsi-style GL driver smooths lines and polygons by rasterizing four
samples into a one-sample color target: PA_SC_AA_CONFIG has 4 samples,
DB_EQAA.OVERRASTERIZATION_AMOUNT is log2(4), and the pixel shader reads
SAMPLE_COVERAGE to scale alpha by the covered samples. The pixel is written when
any of the four samples is covered. DecodeState refused the one-sample target as
a sample-count mismatch.
Such a draw (MSAA_ENABLE set, no depth target, no per-sample shading, every
color target one-sample, OVERRASTERIZATION_AMOUNT matching the raster samples)
now decodes with mergedCoverage. Its pipeline keeps the raster sample count,
gives the color attachments one sample (VkAttachmentSampleCountInfoNV or the
render pass) and merges coverage (VK_COVERAGE_REDUCTION_MODE_MERGE_NV). The
device enables VK_NV_framebuffer_mixed_samples and VK_NV_coverage_reduction_mode
when it reports that combination; elsewhere the pipeline throws.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The data-hit verification keeps this branch's pending-span query on its ShaderMemory and takes #5958's CaptureInvocation, which retries a capture with converted samples.
Keeps this branch's tagVariantRuns declaration next to main's dumpRequest suffix parameter in Driver.hpp, and reads #6232's pointer-chain test words from its table's snapshot, where this branch keeps them.
Adrià