ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

bfc_distance is not the control region's length; the AD-GIF is not in the packet

Browse Source 
Follows 9bb04cc. The control region is now characterised, and the second half of
the answer is a correction to a field doc that has been wrong since the record
was first parsed.

WHAT THE CONTROL REGION IS

Per-record, not shared state. 12,294 distinct blobs across 13,042 records, mixed
within 2,410 of 3,549 classes, and different between LOD 0 and LOD 1 on all 500
classes that have both. It varies per primitive.

Partitioned by its own length, it is not uniform in character, and the pooled
count hid that:

    vert_ofs  48 bytes  (3 qw)      5 distinct blobs
    vert_ofs  64 bytes  (4 qw)  3,175
    vert_ofs  80 bytes  (5 qw)  4,309
    vert_ofs  96 bytes  (6 qw)  3,281
    vert_ofs 112 bytes  (7 qw)  1,523
    vert_ofs 128 bytes  (8 qw)      1

The shortest and longest are effectively constant -- five blobs, and one -- while
everything between is per-record unique. That is a shape, not a noise floor, and
it is invisible unless the measurement is partitioned by length.

THE CORRECTION

bfc_distance == 5 * shader_count holds on every record, and the field doc has
always read "quadwords of ad-gif data" -- which read as a packet-relative length
would make it the control region's size.

It cannot be that. bfc_distance is 5..20 quadwords; vert_ofs, the control region,
is 3..8.

Pooled, they overlap on 9,315 of 15,219 records -- 61%, a number describing
nothing. Partitioned by shader_count, as AGENTS 3a requires, it is exact:

    shader_count 1: 2,772 of 8,676 exceed  (32%)
    shader_count 2: 4,649 of 4,649 exceed  (100%)
    shader_count 3: 1,729 of 1,729 exceed  (100%)
    shader_count 4:   165 of   165 exceed  (100%)

Without exception for two or more shaders. For one shader it exceeds exactly when
vert_ofs is below 5, which is that 32%.

**The AD-GIF is not stored in the tie packet.** The packet is control, vertices
and scissor, in that order. bfc_distance is a per-record quantity tied to the
shader count whose meaning is still not established, and the "quadwords of ad-gif
data" reading of it is wrong. The doc now says so and says why, rather than
carrying a plausible description of a field whose meaning nobody has established.

This is the fourth retraction today and the second today found by partitioning
rather than by a test failing. The pooled number was not merely less precise than
the partitioned ones -- it pointed the other way, because 61% looks like noise and
100% looks like a boundary. Had I accepted the pooled figure I would have written
"sometimes" and moved on.

59 disc tests, 278 total across 23 + 19 + 59 + 156 + 22 with the disc present
(disc binary 35.31s), clippy clean.
This commit is contained in:
ReaperOfVeriod
2026-10-14 04:57:41 +02:00
parent 9bb04cca7b
commit f43a1c2e6e
4 changed files with 151 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/level-assets.md
+42 -3
View File
@@ -1807,6 +1807,45 @@ the packet. The field name is left alone because the on-disc order is fixed and
everything already written about this record says `vert_ofs`, but the doc now
says what the value is.
**Still not known:** what the control region actually contains. It is not
standard VIF or GIF DMA tags. It may be pre-merged GS register writes in a
different framing, or per-class state rather than per-primitive draw data.
**What the control region is:** per-record, not shared. 12,294 distinct blobs
across 13,042 records, mixed within 2,410 of 3,549 classes, and different between
LOD 0 and LOD 1 on all 500 classes that have both. It varies per primitive.
Partitioned by its own length it is *not* uniform in character -- the pooled
count hid this:
vert_ofs 48 bytes (3 qw) 5 distinct blobs
vert_ofs 64 bytes (4 qw) 3,175
vert_ofs 80 bytes (5 qw) 4,309
vert_ofs 96 bytes (6 qw) 3,281
vert_ofs 112 bytes (7 qw) 1,523
vert_ofs 128 bytes (8 qw) 1
The shortest and longest are effectively constant -- five blobs and one -- and
everything in between is per-record unique. That is a shape, not a noise floor.
## bfc_distance is not the control region's length
The other half of the answer. `bfc_distance == 5 * shader_count` holds on every
record and has always been documented as "quadwords of ad-gif data" -- which, read
as a length within the packet, would make it the control region's size.
It cannot be. `bfc_distance` is 5..20 quadwords; `vert_ofs`, the control region,
is 3..8.
Pooled, the two overlap on 9,315 of 15,219 records (61%) -- a number describing
nothing. Partitioned by `shader_count`, as rule 3a requires, it is exact:
shader_count 1: 2,772 of 8,676 exceed (32%)
shader_count 2: 4,649 of 4,649 exceed (100%)
shader_count 3: 1,729 of 1,729 exceed (100%)
shader_count 4: 165 of 165 exceed (100%)
For two or more shaders it exceeds on every record, without exception. For one
shader it exceeds exactly when `vert_ofs < 5`, which is the 32%.
**So the AD-GIF is not stored in the tie packet.** The packet is control,
vertices, scissor. `bfc_distance` is a per-record quantity relating to the shader
count whose meaning is not established, and the "quadwords of ad-gif data" reading
of it is wrong. The field doc said so in terms before this measurement; it does
not now.