watchthelight labs

xe: 2026-10-29 (full run, window 2026-10-28 11:14 UTC to 2026-10-29)

A quiet day for Intel Xe on macOS in general, but two of the changes land right on our open plugin issues. zep245's IrisXe driver fixed its yellow Tahoe icons with the same root cause we found for I-120 two days earlier, and spotted a second latent bug that our plugin shares. metal2vulkan added a bounded wait for pipelines that are still compiling, which is the clean answer to a WindowServer watchdog kill during a cold shader compile.

Actionable

zep245/IrisXe-macos-driver 1.0.1: GPU icons on Tahoe, same cause as our I-120. Release v1.0.1, commit 66a5f72. Their DESIGN.md entries b206 to b212 walk the same path we walked: solid style-colour squares in iconservicesagent, then the log line buffer texture: refused on memory types - image types 0x7 of 0x3f. A texture over an MTLBuffer had to accept every memory type of the device, ANV's linear images accept only a few, so newTextureWithDescriptor:offset:bytesPerRow: returned nil and the icon shaders sampled a stale texture. Their fix (b211, plugin/nvmtl_vk.c) records every memory type the plugin has ever allocated from and asks the image to accept only those. Ours (NvGfx xe-2.6.2 d54b9d9, 2026-10-27) records the one type each buffer really sits in, which is tighter. They confirmed it on Tahoe (b212) and now leave iconservicesagent on the GPU by default. Their notes do not mention our fix and the two patches differ in approach, so this reads as an independent find, not a copy. High confidence on what it changes. Nothing to take for I-120 itself: our one remaining yellow Dock icon was the icon cache, not the renderer.

zep245 b210: linked functions run with the caller's function constants. Same commit, plugin/NVMTLLibraryLoad.m. Metal gives every function its own function constant index space, but nvmtl_link_stage merged the constants of the caller and of every linked function into one table by index, caller wins. A linked visible function whose constant shares an index with the caller's runs with the wrong value. Their fix folds each linked function's own constants into its own AIR first, through a new translator export nvmtl_specialize_air. They report it did not change their icons (those effects have no constants of their own) but keep it as correct. Our xe plugin has the same merge: in plugin/NVMTLLibraryLoad.m the link step copies every linked function's _fc into one dictionary and then addEntriesFromDictionary: the caller's on top. Latent, no known symptom on our side yet. Medium confidence that it can bite (it needs a linked function with its own constants at a clashing index); high confidence the code path is the same. Licence PolyForm Noncommercial 1.0.0 (checked in the 10-28 run), so ideas only, not code.

steelbrain/metal2vulkan: a bounded wait for pipelines still being compiled. d7d4870. A cold MoltenVK compile inside one command buffer took 11.59 s and tripped the guest's 10 s watchdog. The runtime now waits a bounded time (4.5 s at creation and 4.5 s at commit by default) for a pipeline still being built, then records its draws as nothing and lets the command buffer finish, announced as draw-dropped-unmade. A failed compile also drops the draw rather than failing the command buffer; a failed compute dispatch still fails. This is the same shape as our WindowServer watchdog trouble (N-307's 13 s watchdog, N-312's 45 s to first frame): one late frame with missing draws is better than a killed compositor. Companion commit 8c09b7c makes a warm pipeline creation link from cached per-stage keys instead of decoding all the AIR again. Both are in their Rust runtime, not the translator we ship, so they are design input. Licence GPL-2.0-or-later or LGPL-3.0-or-later (README and LICENSE files; GitHub shows NOASSERTION). High confidence on what it does.

Notable

metal2vulkan on ANV framebuffer fetch. Fetch on ANV goes through the pixel interlock because ANV has no multisampled storage images; 12cd153 and bd1861c fix how such a pass's sample planes merge back before a resolve, and which colours count as read for keeping samples. That is the multisample case only. Our I-119 fetch work in WindowServer is single-sample and its bands were already traced to instanced strips drawn whole (NvGfx xe-2.6.2 c29a525), so nothing here changes that. Medium confidence that it does not apply.

metal2vulkan translator changes that touch ANV. 487e23f declares a half colour output as 16-bit where the device enables storageInputOutput16, and says ANV takes that form now but was not re-measured. cdc0927 and 9afdb1e hand fast-math and many builtins to the device's own instructions; they name an intel-irisxe-anv profile among the measured ones. These change blend and rounding results on ANV when we next update the translator in the plugin, so a re-pin should be followed by a desktop check (colour bands, icons). Medium confidence.

metal2vulkan no-copy buffer import with a copy fallback. 0a18511 makes a no-copy buffer or heap over a copy of the caller's pages when the import is refused or fails, synced on commit and on completion, and 0dfdbcd frees the placed address range when that copy is refused too. This is the same problem space as our I-123 (userptr pages held past the plugin's release) and the N-307 tail-page panic, seen from the userland side. Ideas only. Medium confidence on relevance.

JulioNectar/Hackintosh-XPS13Plus-IrisXe-Tahoe issues. All are on the NootedGreen plus Apple TGL kext path, not i915: #5 gets a second real Tiger Lake-H report (i5-11300H, 80 EU, panic 72 s after reaching the desktop, wild pointer); earlier in the thread a 9A68 machine hits an MC7 machine check on writes near the DMC range and a divide by zero in Apple's Metal driver. #8 gets a second machine (Alder Lake 46A0, eDP) with the same pure-virtual panic in AppleIntelPort::probePortState(), so it is not HDMI-only. #17 gets a log upload only. #23 is an installer hang, not graphics. #24 was closed by its author with no comments. Nothing bears on XeGfx, and none of our findings apply directly. High confidence.

b00t0x/WhateverXe-Graphics #1. Two new reports: an Alder Lake-HX 468B Lenovo laptop in Hybrid mode with an NVIDIA dGPU, internal panel black while ioreg looks healthy; and a Tiger Lake 9A49 on 26.7.2 with the framebuffer up but no accelerator node. The first one is close to our Legion experience: on these Lenovo hybrid laptops the panel can end up on either GPU from boot to boot (our I-037), so it is worth checking which GPU owns the panel before debugging the Intel side. Low confidence that this is their cause.

Noise

  • Mountainatic/ArrowWhatever #1: our thread, opened 2026-10-28. No reply, no reaction, and no commits to the repo since 2026-10-27. No reply is owed; we are waiting for them. We did not ask for permission to apply patch 0001 (we fixed the same race ourselves in 0.0.46), so there is nothing to wait on there.
  • samranahmad09/WhateverXe-RaptorLakeP 498a10e: a docs correction of probe counts; results unchanged.
  • zep245 470c78f: "Quiet commit logs after display handover" turns off the per-commit log lines once the boot screen has been handed over, because on Sequoia WindowServer never calls enableController. A logging change. The same commit series keeps the hung boot's last step in a separate NVRAM key so the next good boot cannot overwrite it, a habit worth copying in spirit, though our own NVRAM trace was a stall suspect (I-116).
  • The rest of metal2vulkan's 111 commits are conformance re-blessing, precision notes and Apple M3 Max or MoltenVK specific work.

Discovery

Web sweep

Five web searches (Meteor Lake acceleration, Arrow Lake iGPU, Intel Xe Metal on Tahoe, XeGfx, InsanelyMac Iris Xe) and GitHub repository searches updated since 2026-10-27 found nothing new. The only GitHub hits for XeGfx are our repo and ArrowWhatever; the only fork is the known one from 2026-10-23.