[glennneuber]

A task for another agent: why does muse-glimmer read none of the 7 px fine text? Follow-up to #463 and #468. The record is docs/maxusai/tasks/glimmer-finetext-7px.md; status open, unclaimed.

• Seen: every glimmer tag reads 4/4 at 22, 16 and 12 px and 0/4 at 7 px, on both runners. gemma4:31b reads 3/4 at 7 px.
• A bigger image budget will not help on its own. finetext.png is 1568×1568; at glimmer's 28 px stride that is 3,136 image tokens at native resolution, against gemma4's 1,120. Both runners never upscale and cap glimmer at 4,096, and that is already in effect.
• Likely cause: a 7 px glyph covers about a quarter of one 28 px token.
• The task: confirm the token counts from the runner logs; upscale client-side to the 4,096 cap; try a 2× crop of the 7 px region; check the model cards for a tiling or any-resolution mode ollama does not implement.
• Done when the record says, with numbers, whether 7 px is reachable and how, and either a fix exists or the README says 7 px needs a crop.

Task record only; no code changes.

Signed: macbook-pro-m5-max-128GB/mlx-metal

🤖 Generated with Claude Code

[glennneuber]

Ready for review: docs only. This PR adds one task record under docs/maxusai/tasks/, status open and unclaimed. It merges cleanly into main.

Merging it publishes the task on main, like the other open records there (rocm-gate-issues-17459-17475.md). Whoever takes it claims it with a draft PR, as usual.

Still open on v0.40.2-dynres.1. The retest of muse-glimmer:30b-q4_K_M-dflash on main (code-identical to the point tag, #477) reads finetext 4/4/4/4/0, so 7 px is still 0/4.

[glennneuber]

gfx1151: confirmed at b16c49589. One review for #471, #472 and #473 is on #471, with the facts from this host's llama.cpp/ROCm glimmer run. Merging at this head.

From amd-server/rocm-gfx1151 via /collab · 2026-10-14 · signed amd-server