igneum/tools/intel-arc

Intel Arc B580 on PC 1: the jobs (7 October 2026, branch intel-arc)

Plan: docs/plans/intel-arc.md. PC 1 (ae432dc7) is the project lead's desk: nothing here runs without his go for that run; every job is a signed run job through packaging/ota/publish-jobs.sh from the main checkout (its signer binary lives there), never pausing, resuming or quitting the installed app, never posting to api/cards (the RUNNER's --cards-off takes a card alone and restores it on any exit; tools/ci/playbook-quit-check.sh).

1. The driver (ran 7 October 2026)

pc1-intel-driver.ps1, elevated (one UAC prompt, the project lead's click), no --stop-miners. Downloads gfx_win_101.9034.exe from downloadmirror.intel.com/929959/ (932,631,144 bytes), checks the SHA512 Intel prints on page 785597 and the Authenticode signature, runs the installer with -s alone (silent, no -b: never reboots by itself), reads Intel's own logs under C:\ProgramData\Intel\GFXInstaller, then every adapter row, the PnP display devices, the class key's memory size and the installed worker's --list.

Run	Published	Outcome
run-ia-intel-driver-20261007	09:25:20Z	download 10 s, SHA512 equal, Authenticode "CN=Intel Corporation"; installer exit 1007 after 17 s: the bootstrapper wrapping the inner Installer.exe's exit 7 ("unsupported parameter", my -report <path>); no device check ran; the .NET Desktop Runtime it needs was installed (exit 0)
run-ia-intel-driver-20261007-b	09:43:59Z, the card in	-s alone, 203 s, exit 1014 = the inner installer's 14 wrapped (installed, restart required): Level Zero 1.32.0, the Support Assistant 26.2.0.7 and Intel Graphics Software 26.32.2604.4 went on; the display driver did NOT bind (the device sat in Code 12 on Windows' inbox 6733 at install time)
run-ia-pc1-reboot-20261007	10:00:31Z	pc1-reboot.ps1, a plain run job (the project lead's word): shutdown /r /t 20, exit 0; the PC was back at 10:02Z
run-ia-intel-readback-20261007 and -b	10:02:35Z, 10:06:11Z	pc1-intel-readback.ps1 (read only): the Arc OK, Code 0, still on 6733; the Intel OpenCL 3.0 platform lists it with 11,928 MiB, 160 compute units, 2,850 MHz, local 128 KiB, cl_khr_subgroup_shuffle; the app's row other:Intel(R) Arc(TM) B580 Graphics, 8 identities (every card faulted on "no status line from the miner for 90 s" after the restart: the miner side, not the workers)
run-ia-intel-driver-20261007-c	10:07:45Z, the device healthy	-s alone, 156 s, exit 1014: 32.0.101.9034 bound to the device, Code 12 until the restart
run-ia-pc1-reboot-20261007-b, run-ia-intel-readback-20261007-c	10:13:12Z, 10:15:22Z	restart b taken; read-back: driver 32.0.101.9034, status OK, Code 0; the Intel OpenCL 3.0 platform lists the card on 9034 with 11,930 MiB
run-ia-arc-bench-20261007	10:23:04Z	VOID: the script benched device 0 (the Ryzen iGPU gfx1036; a second -match reset the capture); fixed, the next run carries the device's name on every row

packaging/ota/publish-jobs.sh add --kind run --target ae432dc7 --id run-ia-intel-driver-<date>-<x> --elevated \
    --script tools/intel-arc/pc1-intel-driver.ps1 --timeout-minutes 60 --title "Intel Arc driver 32.0.101.9034 on PC 1" --deploy

1b. PC 1 not mining after the restart (7 October 2026, 11:2x to 11:4x UK)

Every card faulted on "no status line from the miner for 90 s" after each restart. The chain under main's words: pc1-node-wait.ps1 (read only: the node was synced with an executed tip at once), the signed restart --what miners, pc1-cards-watch.ps1 (read only, 3 minutes). The miners' own logs then said what they waited on: "template fetch timed out (5 s) for identity 1..8; mining continues on the current template" on every card, the app's export once "export-pack: no template", and from 10:39Z the app's own row message "waiting for the node to answer block templates" on all three with live pids: the node's block-template RPC, not the GPU side. pc1-export-ahead.ps1 (--stop-miners --cards-off <the Arc>) showed the export itself takes 10.7 s and the pack was sound. Found on the way: the runner's miner hold stays until the NEXT job ends (watch b read "held for a remote job" for 3 minutes); two igneum-miner.exe processes alive under --stop-miners with the app's rows at pid 0.

ONE-OFF EXCEPTION, recorded by main at 12:3x UK on the project lead's word ("im not at pc1 now you will have to fix it"): run-ia-cards-set-20261007 POSTed api/cards once from a scratchpad script (ia-pc1-cards-set.ps1, not in the tree): the 5090 and the 9070 XT enabled with 2 identities, the Arc off, persisted by the app in settings.json; then restart-ia-miners-20261007-b, then watch d. The rule stands for everything else.

2. The bench (published only on the project lead's go, after the card is in and the driver is on)

The kit first (packs only; the installed worker is the one under test):

tools/intel-arc/make-kit.sh "$TMPDIR/igneum-ia-arc-packs.zip"      # prints sha256 and bytes
packaging/ota/publish-jobs.sh add --kind fetch --target ae432dc7 --id fetch-ia-arc-packs-20261007 \
    --file "$TMPDIR/igneum-ia-arc-packs.zip" --dir jobs --extract --title "Intel Arc bench packs (class v4 and the v3 control)" --deploy

Published 7 October 2026 10:10:31Z: fetch-ia-arc-packs-20261007, sha256 2c51181b0e9e2f7b236906730f5dcc270a62caa02346e8f91e23abbf1eb12c05, 105,908 bytes (an app update wipes the jobs folder: republish under a new id after one).

Then the bench, with the live network rate substituted (the consequences line's blocks a day) and the Arc's key for the runner's --cards-off (read it from the app's Cards page or api/state: on the 0.3.18 app the Arc is other:Intel(R) Arc(TM) B580 Graphics, on an app that carries this branch intel:Intel(R) Arc(TM) B580 Graphics; the runner matches the key with or without the device index, and both can be named):

NET=$(node -e "..." )   # live_state.hashes_per_second_estimate / 1e6, or read it from the observer (docs/plans/intel-arc.md section 5: 675 at 09:34Z on 7 October)
sed "s/__NETWORK_MHS__/$NET/" tools/intel-arc/pc1-arc-bench.ps1 > "$TMPDIR/ia-pc1-arc-bench.ps1"
packaging/ota/publish-jobs.sh add --kind run --target ae432dc7 --id run-ia-arc-bench-20261007 \
    --cards-off "other:Intel(R) Arc(TM) B580 Graphics,intel:Intel(R) Arc(TM) B580 Graphics" \
    --script "$TMPDIR/ia-pc1-arc-bench.ps1" --timeout-minutes 30 --title "Intel Arc B580: first light, memprobe, class v4 and v3 benches" --deploy

What it prints (node tools/jobs.mjs run-ia-arc-bench-20261007): RESULT list ... (the Intel OpenCL platform line), RESULT device <n> name= global_mib=, RESULT app_card key= vendor= kind= state= (read only), RESULT firstlight ... (the app's own worker line for the card), RESULT memprobe | chase | 1024 | ... (the dependent-load ceiling), RESULT G1 pack=v4-devnet-epoch0 fingerprint= match=yes|no (bit-exact on the fourth vendor), the same for the v3 control, the live pack and the --exchange local row, RESULT watts not-exposed source=IGCL..., then RESULT ROW ..., RESULT PICKER ['Intel Arc B580', <mhs>] (the site/yourcard.js entry, measured so it may go on the site) and RESULT CONSEQUENCES ... (the B580 owner's sentence), and a SUMMARY {json} line. About 3 to 5 minutes: the card switch up to 150 s, the memprobe under a minute, four benches of 5 dispatches of 2^24 (about 1 s each at 15 MH/s, plus IGC's compile of a few seconds per pack).

If OpenCL fails on the Arc the RESULT G1 ... error= and RESULT buildlog ... lines carry the compiler's exact words; the fallback order and hours are in the plan's section 4.

2b. The register-trace bisect (7 October 2026, 12:0x UK, main's go)

Bench c and the two family-probe runs left one fact: every instruction family of the live hash is bit-exact on Intel's compiler (alu, rotr, shl, shr, bfe, andn, perm, popc, clz, sel, dot4, mulhi, mad and every lane exchange), and the hash is still wrong on every lane in both exchange modes. So the bisect: make-trace-pack.py appends igneum_hash_trace to a copy of the class v4 pack (igneum_hash_bound with a trace argument, lane 0's eight registers stored after the init and after every main and shadow instruction, 55,809 snapshots); proto-opencl/host.c --trace --trace-out F runs it after the pack self-test (the self-test's failure does not stop it); igneum-pow trace-regs prints the same sequence from the CPU interpreter (interpret_warp_trace, the hook form of interpret_warp_scratch); pc1-arc-trace.ps1 runs the GPU trace in both exchange modes and diffs each against the CPU trace shipped in the kit, printing the first divergence with six lines of context and which registers differ.

# the CPU trace, on the build box (igneum-pow built there): the pack's own seeds, class and era as g2-recheck.sh derives them
igneum-pow trace-regs --nonce 0 --epoch-hex <IGNEUM_SEED_BYTES_HEX> --day-hex <IGNEUM_DAY_BYTES_HEX> --class mx8+sh256x27 --era 0:<IGNEUM_ERA_SEED_HEX> > cpu-trace.txt
IGNEUM_REDIST=... tools/intel-arc/make-trace-kit.sh cpu-trace.txt "$TMPDIR/igneum-ia-trace-kit.zip"
packaging/ota/publish-jobs.sh add --kind fetch --target ae432dc7 --id fetch-ia-trace-kit-20261007 --file "$TMPDIR/igneum-ia-trace-kit.zip" --dir jobs --extract --title "Arc trace kit" --deploy
packaging/ota/publish-jobs.sh add --kind run --target ae432dc7 --id run-ia-arc-trace-20261007 --cards-off "other:Intel(R) Arc(TM) B580 Graphics" --script tools/intel-arc/pc1-arc-trace.ps1 --timeout-minutes 20 --title "Arc B580: register trace against the CPU interpreter" --deploy

2c. What the bisect found and the fix (7 October 2026, 12:1x to 12:2x UK)

Job	Result
run-ia-arc-family-20261007 and -b	every family exact on Intel's compiler, mulhi and mad included (60 rows, 0 exact=no)
run-ia-arc-trace-20261007-b	the first divergence at snapshot 7, instruction 6 rotr (r0 = rotr_var(r0, r2), r0 d1affd94, n f183b605): CPU a68d7fec = rotr(x, 5), the Arc 35ffb29a = rotl(x, 5): Intel's compiler folds rotate(x, (0u - n) & 31u) into a LEFT rotate by n; the same in both exchange modes
the fix	commit 26e135a3: proto-opencl/intel_rotr.h rewrites the one helper line to the shift form on an Intel platform before the build (host.c's buildProgram and the prepare path); proto-opencl/test_intel_rotr.c in the pre-push gate (Intel rewritten, AMD and NVIDIA untouched); taken into release-0.3.20 by the shipper as 9088293a
run-ia-arc-trace-20261007-c	with the fix, the local-exchange trace equals the CPU's in all 55,809 snapshots (the sub-group trace kernel alone diverges at a shuffle: the divergent lane-0 store before a sub-group shuffle, a trace-kernel artefact; the real kernel's vectors pass)
run-ia-arc-bench-20261007-d	self-test PASS on every pack, fingerprints equal to the Mac's and the 5090's; 11.011 MH/s on class v4, 11.019 on the v3 control, 11.002 on the live pack, 10.882 local exchange; the bench-log row and the card-picker entry

3. Dry run

The playbooks are PowerShell; this Mac has no pwsh (the Homebrew cask is gone from the tap and the Command Line Tools are too old for a cask install today), so the Mac-side dry run against the UI mock (node tools/ui-mock/server.mjs 4310 with ?scenario=intel, whose api/state carries the Intel row) is owed until a PowerShell is on the Mac (Microsoft's pkg, the project lead's word for the download). What stands in: the driver playbook ran live on PC 1 twice with the same helper shapes (Stamp, Summary, the adapter and worker-list readers), and the four CI checks pass on both scripts (kit-path-check, ps-drive-ref-check, kill-by-name-check, playbook-quit-check).