[samucarre]

Problem. The G15 stamps step by 0x100 per job from fixed seeds, so they wrap after a fixed count since the driver loaded: the TA stamp after 0x860000 renders (about six hours of desktop), the compute stamp after 0x3f0000 computes (4,128,768: about 390 image generations with ggml-vulkan at one node per submission). On a J516C, with the stamp_seed() from before 7ccdfe8 (which skipped zero), the TA stamp wrapped at render 8,781,824 and the firmware stopped with DAG: Non Sequential Stamp Updates seen ... stampValue 0x100; the GPU was lost until reboot. 7ccdfe8 now wraps the stamps through zero; I have not tried whether the firmware takes that wrap.

Change. Renumber the stamps from their seeds while the GPU is idle, shortly before they would wrap, so they never reach the wrap whatever the firmware does there. Four commits:

1. TA/FS: at the first publication with nothing in flight within g15_stamp_reseed_margin renders of the TA wrap, write the seeds to the user and firmware stamps, reset the engine targets and move an offset, modulo the 2^24 period of stamp_seed(), so the next render is ordinal 1, as after boot.
2. Inside that margin nothing is published behind a flight, so a client that keeps the GPU busy cannot hold the renumbering off until the wrap. A non-zero margin is clamped to at least one prefix and at most half the stamp range.
3. The same for the compute stamp, with g15_compute_reseed_margin: the stamps go back to what ComputeGraph::init() writes with no stamp base (user COMPUTE_SEED, firmware 0).
4. A stamps: line in asahi-g15/stats: computes and renders left before each wrap, and both margins.

g15_stamp_base and g15_compute_stamp_base (testing only) start the counts near the wraps, so this can be tested in seconds. Independent of #261: it applies to integration/aurora as it is and merges cleanly with it and with #258.

Enabling it. Every new parameter defaults to 0, and with both margins at 0 nothing changes: no offset, no hold, the same stamps as now. I run both margins at 100000:

options asahi g15_stamp_reseed_margin=100000 g15_compute_reseed_margin=100000

(or asahi.g15_stamp_reseed_margin=100000 asahi.g15_compute_reseed_margin=100000 on the kernel command line). They are read when the module loads; asahi-g15/stats shows them (render_margin, compute_margin) with what is left, and the kernel logs G15: TA/FS stamps renumbered ... or G15: compute stamp renumbered ... when it happens, with these margins about once every 8.7M renders or 4.0M computes.

Checked on a MacBook Pro 16" M3 Max (J516C, 64 GB), always on top of local patches, among them HDMI on dcpext0 and J516C panel brightness:

• compute stamp, integration/aurora 2f72554 with this series, plus AVD AV1, soc: apple: report the T6031 GPU to the PMP #258, drm/asahi: g15: allow 8 prefixes in flight per VM (was 2), tunable with g15_max_inflight #261, the sleep work of Make M3 Pro sleep use 1.4 W instead of 2.6 W, and add the RTC wake alarm #274 ported to the J516C, the drm/sched free_guilty fix of Fix the G17 late-completion Oops in drm_sched_job_done() aurora-silicon/linux#381 and an AFK logging change: from g15_compute_stamp_base=4023768 (105,000 computes before the wrap) with a margin of 100000, G15: compute stamp renumbered from the seed at compute 5000 (ordinal 0x3d7960); compute work (test-backend-ops perf -o ADD, one node per submission) went on to 159,899 computes, with compute_left 3973869 at the end, and a FLUX.3 1024x1024 image generated fine afterwards. The same on 30a6518 (159,890 computes).
• TA/FS stamps, commits 1 and 2 before 7ccdfe8, with the offset modulo 0xffffff, the period of stamp_seed() there. On 8b88dfc: from g15_stamp_base=8779824 with a margin of 1000, renumbered at render 1000 and 3,003 renders retired; from g15_stamp_base=8281824 with a margin of 100000 and the GPU kept busy (286,875 publications behind a flight), renumbered at render 400,000 and went on to 526,113, past render 500,000, where the TA stamp would have wrapped. On 937b727, also with AVD AV1 and drm/asahi: g15: allow 8 prefixes in flight per VM (was 2), tunable with g15_max_inflight #261, in desktop use: one boot renumbered at renders 8,681,824 and 17,363,648. No Non Sequential, firmware crash or GPU fault in any of them.
• TA/FS on this base, modulo 2^24: not reached on hardware yet. The model below of the TA targets over 26M renders with a margin of 100000 gives none out of sequence, and two modulo 0xffffff (the renders after the first and the second renumbering).
• drivers/gpu/drm/asahi/asahi.o builds on 2f72554 at every commit (arm64, clang 21, rustc 1.98; the CI compile check does not build Rust), with no new warnings; the G15 host selftests pass.

Not checked. Whether the firmware takes the wrap through zero: with a margin of 0 and a stamp base near the wrap this series makes it a test of seconds, but a stop costs a reboot and I have not run it. Other boards; this branch alone on hardware.

Model of the TA targets

# TA stamp targets with the renumbering of this series, over 26M renders with a margin of 100000,
# renumbering at the first idle publication inside the margin (prefixes of 8 renders).
TA, M32 = 0x7a000000, 1 << 32
RENDER_WRAP = 0xffffff - TA // 0x100 + 1  # 0x860000


def stamp_seed(seed, n):  # as in encode.rs: seed + (n as u32) * 0x100, wrapping
    return (seed + (n % M32) * 0x100) % M32


def run(period, renders=26_000_000, margin=100_000, prefix=8):
    draw, base, prev, bad, renumbered = 0, 0, TA, 0, []
    while draw < renders:
        if (draw + base) % period + margin >= RENDER_WRAP:
            base = (period - draw % period) % period  # renumber_render_stamps()
            prev = TA  # the seed written to the firmware stamp
            renumbered.append(draw)
        for _ in range(prefix):
            draw += 1
            t = stamp_seed(TA, draw + base)
            if (t - prev) % M32 != 0x100:
                bad += 1
                print(f"  render {draw}: target {t:#010x} after {prev:#010x}")
            prev = t
    print(f"period {period:#x}: renumbered at {renumbered}, targets out of sequence: {bad}")


run(1 << 24)    # this series
run(0xffffff)   # the period of the earlier stamp_seed()

period 0x1000000: renumbered at [8681824, 17363648], targets out of sequence: 0
  render 8681825: target 0x7a000000 after 0x7a000000
  render 17363649: target 0x79ffff00 after 0x7a000000
period 0xffffff: renumbered at [8681824, 17363648], targets out of sequence: 2

🤖 Generated with Claude Code

[chriskearney]

Reviewed all six changed files at exact head c3fad65647f0e46223b91fb7a562d2f1a7c3e945, the drain/retirement and failure paths, and the independent exact-method host controls (26M renders and 10M computes, two renumberings each, default/boundary/write-failure cases and five caught semantic mutants). No blocking source finding for landing this as a default-off experimental facility: all four new parameters default to zero, preserving current stamp generation and publication policy.

This approval does not qualify enabled firmware reseeding or a new board/firmware cohort. The current modulo-2^24 TA/FS path has not reached the wrap boundary on hardware; older TA/FS and compute observations are on different/local stacks. Before calling enabled behavior qualified or making it default-on, run a bounded near-wrap qualification on an already-supported/admitted G15 stack with the existing stop/restore route. A wrap-to-zero crash control or new Max/firmware admission is not required.

Current required CI and full merge-group CI remain required. The C compile job skips Rust; the actual queue-tree package build must retain enabled RUST/DRM_ASAHI/G15 config and successful aarch64 Asahi module build evidence. Normal full packaging can provide that native build; an earlier package run is evidence of the mechanism, not a build of this head.