Every import lookup walked the lease out from the containing range to find
the run of continuing registry ranges, which is linear in the run length.
That walk depends only on the lease snapshot, the containing range and the
import window block, so its first and last index are now memoized per
thread under a weak reference to the snapshot, the range index, the window
and the window's low end. APS5_NO_RUN_MEMO walks every time.
Everything that depends on other state runs on each call as before: the
largest size, the budget, the failed blocks, the remembered refusals and
the halving block search. importRunBounds returns the chosen indices, so
sameRange, runCovers and the whole-run lookup in importAllocation compare
against the lease without copying the run's range pointers.
importRunFailureShrinkTests records a failed 8 MiB block between two
lookups on an unchanged registry and requires the run to shrink to its
4 MiB blocks. importRunGrowthTests and importRunReplacedTests check that a
run grows and shrinks when its ranges are registered or replaced.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A CPU store made inside a completion action (a copied buffer's write-back)
reached the flush hook with PublishScope::None, and PublishShadow skipped
such stores anyway. Nothing was published before the store landed, and
its own stamp then made every unit it touched stale, so the next publish
dropped those units whole: the storage results the store did not cover
were lost, both those already in the unit shadow and those of a pending
image the hook had just stored into it.
The hook now publishes the units such a store covers partly, as outside
completion actions, and its full Sync inside completion actions lands
the copies before the store. PublishShadow, FlushPending and
PublishShadowsOnly take a waited flag for this; other publishes made by
completion stores are still skipped.
An address-based build binds the registered heaps in place and does not
store the storage results pending in them. With unit shadows on, a
write-back that retiled into the shadow reaches the import only through a
publish, and nothing published before such a build, so its pointer reads
saw the bytes of the last publish.
UploadFinish now publishes the fresh units over the heaps the build maps:
the address space's base on the cached path, the exempt in-place regions
on the per-build path. One AnyShadowedOverlaps check over their span
gates it, pending results stay pending, and the copies count under their
own publish reason, "address".
On Windows a thread_local destructor in a module runs after emulated TLS
has freed the object, and prx_thread_local_destructors refuses
libSceAgcDriver.prx for it. The draw pipeline of upstream PR 6946
(Raghav314, f8192a64b3) added such scratch objects:
DrawFinisher::Enqueue's and DrawPipeline::Enqueue's reclaim lists,
CachedFragmentOutputs' last key and outputs, DecodeVertexStageInfo's
attribute and buffer tables, and PrepareDrawBindings' pool size counts.
They now live in HostThreadLocal, as the driver's other per-thread
scratch does; on other hosts that is the same thread_local.
The second half of a pipelined draw (stage materialization, cache insert,
enqueue) runs on a finisher thread, overlapping the next draw's packet
work; draws whose stages could write memory are held back. Commits skip
work whose inputs did not change since the last commit, color metadata
passes are ordered through the pipeline, resource and storage-image proofs
are reused within one collect epoch until a write breaks them, and a shape
entry is refreshed in place at the second sight of the same read user words.
APS5_VERIFY_DRAW_PIPELINE checks reused proofs against a full check.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
An overrasterized draw (a multisampled rasterizer into one-sample color
targets, VK_NV_framebuffer_mixed_samples) chains
VkAttachmentSampleCountInfoNV into its pipeline. When the pipeline is
linked from graphics pipeline libraries, only the fragment output library
carried it, and the link and the background link-time-optimized relink
did not. The Khronos validation layer (1.4.363) then reports
VUID-vkCmdDraw-multisampledRenderToSingleSampled-07285 for every such
draw, as it does in agc_driver_pixel_sample_coverage, and not with
APS5_NO_GPL=1, where the pipeline is built whole.
Both links now chain a copy of the sample counts.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PPSA12361 binds color format 7 (COLOR_11_11_10, float) with COMP_SWAP 0
and stops on "unsupported color format 7 number type 7 component swap 0".
Only the reversed order (COMP_SWAP 2) was accepted.
The format keeps its 10-bit component in the low bits. The standard
swap puts red in the first slot, as Mesa pairs SWAP_STD with
COLOR_10_11_11 for R11G11B10_FLOAT, so COMP_SWAP 0 puts red there and
COMP_SWAP 2 blue. Swap 0 now decodes with the identity export mapping
0xe4 and the same packing; the other swaps still throw.
The decode test accepts swap 0 and keeps refusing swaps 1 and 3. The
execution test renders both orders into tiled and linear targets and
compares each stored word with the packing of the order. Its program
pool grows to fit the second pass. The debt entry names the accepted
orders and says the swap 0 layout is derived, not measured.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
A FLAT_SHADE input without pass-through that a pixel shader reads
through v_interp_mov_f32 P20 and not P10 stayed an explicit per-vertex
input and read vertex 2 minus vertex 0. For a flat value that is the same
on every vertex the difference is 0, and with the first provoking vertex
nothing refused it.
ps5-opengl lowers every flat input to a load of one vertex: vertex 1
(P10) by default, which #4030 reads as the provoking vertex, and vertex 2
(P20) for triangles when GL's flatshade_first is set. SuperTuxKart's
deferred point lights are drawn that way, so all twelve flat inputs of
pointlight.frag read 0, the attenuation 0 * -inf was NaN, nothing was
discarded, and the starting-line referee's light quad blacked out the
scene behind it (#8364).
A P20-only read now returns the provoking vertex's value, as P10 and P0
do. The lane was not measured on the console either, so FragmentParameter
records it and a pipeline using the last provoking vertex throws. An input
read through both P10 and P20 keeps its per-vertex differences.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A guest read over the depth or HTILE range of a native multisample depth
surface threw even when the host had not written the surface since its
import. Its samples are then still the clear value the import took from
the guest HTILE, so the guest bytes already describe it. Retire such a
surface and its guards instead, and keep the refusal for a surface the
host wrote: draws with depth or stencil writes, depth/stencil copies and
storage write-back.
Onimusha: Way of the Sword (PPSA27836) imports a 4-sample D32 target,
draws into it once with depth tests only and no color target, then reads
the memory back as a structured buffer in a compute dispatch.
Unblocks PPSA27836.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A line list or strip drawn with PA_SC_AA_CONFIG above 1x and
PA_SC_MODE_CNTL_0.MSAA_ENABLE clear threw, and METAL GEAR SOLID: Peace
Walker (PPSA18216) draws such lines into its 4x target. They now take
the path triangles already take in this state: the target's sample
count with every sample at the pixel center, or one sample under a
one-sample color target.
The refusal now reads the primitive the draw rasterizes
(RasterPrimitiveOf) instead of VGT_PRIMITIVE_TYPE: a point list that a
geometry program turns into triangles or lines is drawn as those, and
rasterized points and alpha-to-coverage still throw. No draw on main
rasterizes points in this state, because a vertex-path point list and
a geometry program's point output throw earlier; the point term takes
effect once they are drawable, as with #6801.
The new GPU test decodes a line list and a line strip into a 4x target
in this state with DecodeState, draws the decoded state, and requires
every pixel to be covered in all four samples or in none.
Co-Authored-By: Claude <[email protected]>