The console's DCC of a single-level 4-byte SW_64KB_R_X surface is
ceil(W/512) * ceil(H/512) * 4096 bytes, 49152 for 1920x1080, but the
driver stored and read one key per 256 surface bytes (34560).
PPSA26344 retiles its render DCC into the displayable copy it
registers (cs_dcc_retile_32bpp); a retile of the stale tail gives the
mixed keys PPSA12544 stops on.
DccKeyCount gives that extent. Color target and storage image key
stores cover it when the DCC is pipe-aligned (CB_COLOR_ATTRIB3 bit 30,
T# word 6 bit 19), whose CB keys reach its last meta block, and throw
where it is not writable; unaligned DCC keeps one key per 256 bytes,
as do texture and color target key reads. DisplayBufferKeys reads the
display DCC over the extent, presents only when every key agrees,
names the first differing key's pixels and checks a pending image
against those keys.
Treat equal BASE_ARRAY and DEPTH as a six-face cube. Measured with image_load, image_sample and image_get_resinfo on RX 6600 gfx1032 using base slices 0, 5 and 6. Partial cube ranges still throw because filtered sampling differs from load bounds.
Graphics tests and GPU snapshot/storage sampling tests pass for all six faces at each tested base.
Assisted-by: OpenAI Codex
Textures in SW_256B_D, SW_4KB_D, SW_64KB_D, SW_64KB_S_T, SW_64KB_D_T,
SW_4KB_S_X and SW_4KB_D_X (tile modes 2, 6, 10, 17, 18, 21 and 22)
threw while their T# was decoded. They are detiled with address
equations generated from AMD addrlib's GFX10 swizzle patterns for the
same 16-pipe non-RB+ configuration as the 64 KiB XOR table, and share
the block shape and mip tail placement of the standard mode of their
block size. The pipe/bank XOR base check of the XOR and T modes now
uses the block size.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The hardware addresses a 1D array in the S and D swizzles differently
from a height-1 2D array, and addrlib allows only linear, Z and R
swizzles for 1D resources, so the other tile modes are rejected instead
of being sampled with a 2D array layout.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A T# of type 12 (1D array) threw while decoding. It now decodes to a
1D array dimension, checked like a 2D array with a height of one, and
holds depth + 1 layers laid out as a 2D array's. Its Vulkan image is
1D with that many layers, viewed as VK_IMAGE_VIEW_TYPE_1D_ARRAY for
sampling and storage, and the recompiler declares a 1D array shape for
arrayed 1D image resources instead of failing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PPSA21564 ends each of its two 1920x1080 RGBA16F bloom downsample
chains (MAX_MIP 5) with a compute pass that stores level 6 through a
view of levels 6..6, every frame from the PS logo on. The descriptor
decode threw for such a view.
GFX10 uses MAX_MIP only to place the levels: a level's address comes
from the levels below it, and a level in the mip tail is a fixed slot of
the tail block counted from the first tail level. A level past MAX_MIP
is addressed the same way, so when the chain extended to the view's last
level keeps every allocated level, the tail and the surface size
unchanged, the view reaches that slot inside the surface's allocation.
addrlib (GFX10, Navi10 with 16 pipes) computes the same 0x1640000-byte
layout for 6, 7, 9 and 11 levels of this surface, with level 6 in the
tail at (0, 32). The view then decodes with the extended chain over the
same guest bytes. Views whose extra levels would move the allocated
ones, such as linear chains or chains without a tail, still throw.
T# word1 MIN_LOD (unsigned 4.8, in levels of the whole surface) was
rejected. Sampled views now chain VkImageViewMinLodCreateInfoEXT
(VK_EXT_image_view_min_lod, enabled when the device offers the minLod
feature). Its minLod counts levels of the whole image exactly as MIN_LOD
counts levels of the whole surface, because the image holds every mip and
the view starts at BASE_LEVEL.
- A clamp at or below BASE_LEVEL cannot change which level a sample reads
and is left off; one past the view's last level is bounded by it (the
view selects that level anyway, and Vulkan requires the bound).
- A clamp that binds on a device without the feature throws.
- The texture cache already keys by the eight descriptor words, so views
with different clamps are not shared.
- Storage views address one level: a clamp at or below that level is
accepted, one above it still throws.
Only the lines this branch added lose their comments; the commits before
keep them, with the reasoning behind each change, for whoever digs into
that code later.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both suites stopped at their first stale expectation, so nothing after
it ran; the BDA device tests did not link.
- the BDA device tests define the one recorder entry Resources.cpp
reaches (no recorder) and fail loudly on the others
- Buffer::Invalidate refuses memory that is not host mapped again (lost
in 8a69fef); the device tests expect it for a device-local buffer
- APS5_PIN_WAIT_MS (60000 by default, unchanged) bounds the wait before
a mutation of a leased range is refused, and the refusal names it; the
graphics tests set 200 ms, as they expect about a dozen refusals
- the expectations follow the behaviour the code chose since: a buffer's
four-DWORD V# is refused as a T#, a sampler exceeds the mock's zero
sampler slots, a V# at unmapped memory binds its committed pages only,
a rect-list fragment input without a vertex export reads as zero,
detiled rows span the padded block width, mip ranges are checked in
address order, block-compressed and 128/129/132 formats use render
target tiling, an XOR swizzle is refused only over a base that is not
64 KiB aligned, DCC and partial mip chain views decode, a cube reads as
a 2D array, the sampler fixture's max LOD fits the 4.8 field, a BDA
program with barriers is accepted, a tessellation control stage is
refused, a corrupt request fails on its signature and a newer one on
its version
- the DCC comment in the texture decoder no longer claims metadata
compression is refused
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Replaces the synchronous per-command execution model, and with it the
upstream render-target, pipeline-cache, tile-buffer, batched-draw and
memory-ownership commits (5a280ce, 7ed5a0b, 46c799d, 598caac, 40df528),
whose files are removed.
- Recorder: one open command buffer per device; dispatches, resident
draws, uploads, write-backs, labels, fills and copies record into it;
timeline-semaphore serials let drains wait without the GPU mutex;
completions run in order at reap.
- one worker thread per PM4 queue; labels and stores written by the GPU
into the host import; GPU-side DISPATCH_INDIRECT; the buffer-fill
kernel replaced by vkCmdFillBuffer; a dispatch cache validated by
write watch; filler packets tolerated; rejected submissions dumped.
- guest memory: page-state cache, 64 KiB write generations, host imports
with VK_EXT_external_memory_host, persistent mirrors of the executable
image, GPU copies of misaligned sub-ranges.
- textures: shader-written images stay resident with deferred
write-back (adjacent-generation rule for packed video planes), sampled
views of storage images, DCC key handling, addrlib swizzle equations,
bidirectional detiler.
- draws: MRT, more formats, dynamic viewport/scissor, cached pipelines,
resident 64 KiB targets, draws recorded into the recorder.
- ShaderResources: two-stage build, descriptor and sampler caches, a
content-keyed resource cache; presentation from the resident image.
- a label deferred behind a completion is no longer re-stored by the
CPU at reap time unless a write-back overwrote it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0177gthrWEBBfBu5xJDXgBfo
Celegans12
TibixDev
Claude
Chad
Dean Galvin
STL1te
devilismyfriend
boykopovar