FA-51949 / Raster memory layout / Member archive

Bricked Volume: Volume brick row count uses wrong footprint · case 04

The returned physical layout descriptor disagrees with the declared buffer mapping at brick_rows.

Member previewVariant 4 · 3 implementations · 6 checks per implementation

Case contract

Volume storage uses 4x2x3 bricks in x-fastest brick order. Bricks have a metadata prefix; x-fastest texels fill each brick including edge padding. Return the named intermediate layout descriptor and final address fields; all quantities are integer byte offsets unless explicitly stated.

Why this case matters

Offline raster resource, upload, readback, and storage-layout regression model.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
layout fixture 2	`{"address": 481, "allocation": 4608, "brick_columns": 3, "brick_id": 3, "brick_layers": 4, "brick_pitch": 128, "brick_rows": 3, "brick_xy": 3, "local_slice": 1, "local_texel": 9}`	`{"address": 481, "allocation": 6144, "brick_columns": 3, "brick_id": 3, "brick_layers": 4, "brick_pitch": 128, "brick_rows": 4, "brick_xy": 3, "local_slice": 1, "local_texel": 9}`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.