fix(vision): resolve #23 color misidentification + address PR #22 review

[nickfinease]

Summary

Supersedes #22. Rebased onto current upstream/master and addresses the review feedback there, plus lands the root-cause fix for issue #23 (VL model misidentifies green/blue objects).

Branch history (11 commits on top of upstream/master):

e9c50c1 fix(vision): swap G and B in preprocessing to fix color identification (#23)
4e637e8 feat(vision): log weight quant format at load time
872c5ba fix(vision): encode upload shape in elements, not bytes
6fcdddc cleanup(kernels): remove dead gemm_f16_wmma_tiled and vit_attention_flash
5f1681c fix(vision): implement smart_resize matching HuggingFace Qwen2VLImageProcessorFast
277bd6f feat(quantizer): add --vision-format bf16 flag and BF16 QuantType
c78a864 fix(vision): use group_size from file for HFQ4 dequant, convert F32->F16 for gemm_f16
6431f73 fix(vision): add HFQ4 dequant support to load_f32_gpu for norm/bias weights
e02d5a8 feat: add --vision-quant hfq4 flag for vision weight quantization
11a3740 perf(vision): revert tiled attention — L2 cache already handles tiling
fd363d1 perf(vision): remove per-layer device_synchronize barriers

Issue #23 — green/blue swap (the headline fix)

Empirical probing with pure-color PNGs, temp=0 greedy decoding, qwen3.5-9b-vl-hfq4.mq4:

input PNG	RGB-order (pre-fix)	R↔B swap	B↔G swap (this PR)
red	"Red" ✓	"Green"	"Red" ✓
green	"Blue" ✗	"Blue"	"Green" ✓
blue	"Green" ✗	"Red"	"Blue" ✓

The two wrong mappings are a classic G↔B transposition. Root cause is most likely a channel permutation in the HuggingFace patch_embed weight export (input conv channels 1 and 2 appear transposed) — I did not chase that all the way into the export pipeline, but the preprocessing swap here resolves the end-to-end symptom and matches the pure-color ground truth cleanly.

End-to-end verification

On the rebased branch with the fix applied:

$ ./target/release/examples/infer \
    /home/beans/.hipfire/models/qwen3.5-9b-vl-hfq4.mq4 \
    --image /home/beans/Pictures/pngtree-green-leaf-for-element-png-image_11934356.png \
    --no-think --max-tokens 80 \
    "What color is this leaf? Answer in one short sentence."

vision weight format: HFQ4-G256 (dequanting to F16 on load)
Prompt: 144 tokens (121 visual + 23 text)
Prefill: 1253ms (115 tok/s)
<think>

</think>

 Green.
=== Done: 7 tokens in 48ms (145.8 tok/s) ===

Pre-fix, the same image on the same model produced "Blue."

Regression test

crates/engine/tests/channel_order.rs pins the contract with pure-color + mixed-pixel fixtures. Runs without a GPU — part of the default cargo test path. If someone removes the swap, these assertions fail before any vision inference runs.

running 4 tests
test pure_blue_routes_b_byte_to_channel_1 ... ok
test mixed_pixel_round_trips_all_three_bytes ... ok
test pure_red_preserves_red_channel ... ok
test pure_green_routes_g_byte_to_channel_2 ... ok
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

PR #22 review follow-ups

The review blockers on #22 that I believe are addressed here:

• ✅ Dead kernel files — gemm_f16_wmma_tiled.hip and vit_attention_flash.hip removed. Neither was referenced via ensure_kernel dispatch; both were stale experimental variants (commit 6fcdddc).
• ✅ Shape encoding bug at qwen35_vl.rs:118 — load_f16_gpu was passing data.len() (bytes) as the tensor shape on both the F16-direct and HFQ4-dequant paths. Corrected to pass the element count n. The F16-direct path at line 110 had the same bug and is included in the fix (commit 872c5ba).
• ✅ HFQ4 vision load-path visibility — the HFQ4 auto-dequant-to-F16 transition now logs at load time (vision weight format: HFQ4-G256 (dequanting to F16 on load)) so HFQ4 and F16 models can be told apart during debugging (commit 4e637e8).
• ✅ Rebased onto upstream/master — one manual conflict in crates/rdna-compute/src/dispatch.rs where this branch's vit_attention_opt landed at the same spot as upstream's new attention_dflash_f32. Resolved by keeping both as siblings.

Outstanding from #22 review (not in this PR):

• ⚠️ gemm_f16_wmma correctness claim — the original Vision encoder: HFQ4 quantization, sync optimization, 1.5x speedup #22 description mentioned a wmma correctness fix. I couldn't reproduce a failing test against the current gemm_f16_wmma path on this branch and don't have a concrete reproducer to hand off. I'd rather retract the claim than ship it unexplained; happy to investigate further if you can point me at the failure mode you had in mind.

Gates

• ✅ cargo test -p engine --test channel_order — 4/4 pass.
• ✅ cargo build --release --features deltanet -p engine --example daemon --example infer — clean (pre-existing warnings only).
• ✅ ./scripts/coherence-gate.sh on qwen3.5-9b.mq4 — text-only reasoning path OK post-rebase (/tmp/coherence-20260420-090512.md). 0.8b and 4b skipped (not present in my models dir).
• ✅ cargo clippy -p engine --tests --features deltanet --no-deps — no new errors or warnings attributable to this PR.
• ./scripts/speed-gate.sh --fast — skipped (4B model not present locally). Expect CI / a tester with qwen3.5-4b.mq4 available to confirm no regression.

Tested on gfx1100 / RX 7900 XTX / ROCm 7.2.

Test plan

• Reviewer: cherry-pick e9c50c1 locally, re-run the pure-color matrix on qwen3.5-9b-vl-hfq4.mq4 (or whichever VL model reproduced Vision encoder color accuracy: F32 computation path to match HuggingFace BF16 precision #23 for you) — confirm red/green/blue all identified correctly.
• Reviewer with a natural photo: run a real-world image of a known-colored object through infer --image and confirm the color word is now correct.
• Run cargo test -p engine --test channel_order to confirm the preprocessing contract passes on your box.
• Optional: point the follow-up investigation at the HF patch_embed weight export to confirm (or rule out) the channel-permutation root cause, so the fix can eventually move out of preprocessing and into the weight converter.

Closes #23.