GFX11 renumbers the image formats past 29, so the raw codes 10, 37 and 1
read as other formats on the console's GFX10 numbering (37 is
11_11_10_UNORM there, 2_10_10_10_SNORM on gfx1100). Name them, and say
why the TYPE 9 depth compare control only answers at 32_FLOAT: gfx1100
compares 16_UNORM and 32_FLOAT only and answers zero for the others.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The entry recorded TYPE 1 only from a gfx1010 measurement with format 22 and left other formats and
depth-compare reads open. Measured on a gfx1100 with the hardware oracle: image_sample_lz,
image_sample_b, image_load, image_sample_c_lz and image_get_resinfo return zero and no fault for
TYPE 0 and TYPE 1 over formats 22, 10, 37 and 1, with a nonzero base over readable memory and with a
zero base. A TYPE 9 control in the same kernel returns the stored texel, the raw dword, the declared
64 and 32, and 1.0 from image_sample_c_lz with an ALWAYS depth compare and format 22.
Co-Authored-By: Claude Opus 5 <[email protected]>
Encode and EncodeFloat run the decrypted-module measurements: the null
state +0x01, null samples +0x02 before the state marker, a markerless
state +0x16/+0x15, null data +0x04 before the frame check, maxDataBytes
0 +0x05 and frame sizes outside the accepted durations +0x03, while a
negative maxDataBytes reaches the backend as it reaches AJM on the
console. Create zero-fills the state and writes the measured word and
bitrate tables, Destroy clears the 0x17B2 marker leaving the other
bytes, the encoder registry keys on the instance id at +0x00, and
EncodeFloat aborts for a stack reservation that cannot fit, matching
the console process death. The tests byte-check the measured layout
with the per-rate bitrates and the new check orders behind both
libraries' Api.hpp, and the debt notes carry the module runs with the
remaining AJM gaps.
The [gputime] line printed a draw's range key with the draw flag still set, so an ordinary variant id 0x2 appeared as 0x8000000000000002 next to [drawvariant] 0x2. A draw's key now comes from Recorder::DrawTimingKey and the line prints it through Recorder::TimingKeyLabel as "draw 0x2", the id [drawvariant] names.
The [drawvariant] line was only printed when a draw was recorded inline, so a queued draw's first-seen variant had a timing range with no address line. It is now printed before the draw is handed to the pipeline.
The APS5_PROFILE_GPU_DRAWS row states the label, the shared per-batch query cap and that draws using a recipe are not timed.
NVIDIA's proprietary driver flushes f32 add, multiply and fma denormals by default but not the inputs of floor and ceil, so its startup probe failed only on those two. Drop their software flush only where the device declares DenormFlushToZero 32.
The driver declares no shaderDenormFlushToZeroFloat32, so every f32 add, mul and fma kept the software flush. Run the same probe as on MoltenVK and use the driver's default handling when it matches the emulated flush.
Pixel-stage ballots and EXEC reads count only lanes that are not helper
invocations, so a waterfall loop over a saved whole-quad EXEC picks and
clears live lanes only. In programs that execute s_wqm on EXEC, writing
EXEC from a value keeps a helper invocation active while a live lane of
its quad is, so implicit-LOD sampling after a save/restore still has its
helpers.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Opt-in with APS5_PROFILE_GPU_DRAWS=1 together with APS5_PROFILE_GPU=1: a [gputime] range around each recorded draw command keyed by the fragment program's variant id, and a [drawvariant] line naming the code address behind each variant id once.
