Performance Research G08 Native BC DXT Textures

Native BC/DXT textures

G08 — Implementation and validation notes

Field	Value
Evidence state	Native-path research already exists; alignment and sampled output remain independent gates
Inspected source	322986f4c5502b3fa887a9605ac8cd88e9b2c579
First experiment	Native-versus-decoded sampling with valid per-format staging layout
Scope	Addendum dated September 15, 2026; not a current-main benchmark or implementation status

Unproven performance research · Performance research — common test protocol · Performance research — reproducible checks

Evidence and implementation reasoning

Mechanism and quantitative limit. Native block-compressed sampling can avoid CPU decode and expanded uploads. Relative to RGBA8 payload, BC1 uses 8 bytes rather than 64 bytes per 4×4 block; BC2/BC3 use 16 rather than 64. The corresponding 8×/4× payload ratios exclude padding and tiny mip effects and are not FPS multipliers. Microsoft block-compression reference.

Existing status distinction. The repository's historical native-BC work already separated layout arithmetic from unproven native-versus-decoded sampled output. A later tracker, #109, specifically addresses compressed-block staging alignment. Reuse that context instead of proposing native BC as though no implementation exists. Research history, tracker clarification.

Implementation issues. Verify format/usage/filtering support; honor compressed block dimensions and offsets; handle mip tails and partial uploads; preserve swizzle, channel/alpha conventions, and synchronization. A byte count being correct does not prove that the GPU is allowed to read from that staging offset.

Acceptance. Sample known blocks containing endpoint and alpha edge cases, compare native and decoded paths with justified hardware expectations, test small/odd mip extents, and exercise all allocation alignments. A decoded path is a useful comparator but may itself contain approximation choices.

First patch boundary

Qualify layout arithmetic, buffer offsets, transfer legality and sampled codec behavior separately. Do not infer sampled equivalence from byte counts.

compressed source + validated layout -> native upload/sample; unsupported format/layout -> decoded fallback

Locate the inspected seam before editing; names or ownership may have changed since the pinned review:

git grep -n -E 'BC1|BC2|BC3|DXT|compressed|bufferOffset' -- hw/xbox/nv2a/pgraph

Proposed focused tests

These are implementation gates to add or exercise, not claims that production tests already exist or passed. Retained standalone checks are on the checks page.

Test ID	Setup / deliberate control	Required oracle
G08.01	Supported BC variants with mip dimensions 1, 2, 3, 4, 5 and larger edges, including mip tails and valid partial uploads.	Block extents/offsets obey format/API requirements; no out-of-range copy or VUID.
G08.02	Alpha/channel edge cases and representative blocks sampled through native and decoded routes.	Compare using exact output where promised or a documented codec-rounding oracle; no ad hoc tolerance after failures.
G08.03	Unsupported device format feature or rejected native layout.	The decoded fallback stays functional and preserves rendering.

Counters and rejection criteria

Collect: native_uploads, decoded_fallbacks, decoded_bytes, uploaded_bytes, cpu_decode_ns, upload_ns, sample_mismatches, validation_errors. Keep exact counts separate from sampled durations; use an uninstrumented build for performance qualification.

Reject or hold: Reject alignment, transfer or sampled-output defects. Do not relabel previously implemented native BC work as a new unimplemented feature.

Follow the common protocol for source identities, previous-main/fixed-baseline controls, raw results, confidence and retail/XISO qualification. No gain becomes proven from a model, cache hit, local operation count, or shifted wait label alone.