Releases

Tested on the Legion 5 15IAX10 (Arrow Lake-HX, 8086:7D67), macOS Tahoe 26.7.1, in N-281: stages 1-7 and the userspace checks pass (vkhost 0 of 1,048,576 values wrong, mtlbench pixel checks clean, wait timings normal).

What changed since 0.0.36:

• Timed-out ioctls return Darwin's ETIME (101). LinuxKPI's ETIME is ETIMEDOUT (60), so Mesa read a timed-out syncobj wait as VK_ERROR_UNKNOWN instead of VK_TIMEOUT.
• jiffies and ktime count from boot instead of from kext load. Before this, every timed wait from userspace ran long by the time between boot and kext load.
• Syncobj wait deadlines are rebased. Mesa sends absolute CLOCK_MONOTONIC deadlines, and on macOS that clock is calendar time minus kern.boottime, about 2.5 s behind mach_absolute_time and slewed with the calendar. Both ioctl paths convert the deadline on every call and restore the caller's struct afterwards, since libdrm retries interrupted waits with it.
• The failing-ioctl log budget (64 lines) is per process, so app probes no longer use it up before WindowServer starts.

Pre-release: XeGfx does not load at boot; it is loaded and staged by hand for testing.

Tested on the Legion 5 15IAX10 (Arrow Lake-HX, 8086:7D67), macOS Tahoe 26.7.1, in N-279: stages 1-7 and the userspace checks pass (vkhost 0 of 1,048,576 values wrong).

What changed: failing DRM ioctls now go to the kext's log ring (sysctl -b debug.xegfx_log) with the ioctl number, pid and errno. Every execbuffer failure is logged; other ioctls only the first 64; ETIME, EINTR, EAGAIN and ERESTART are skipped. Mesa's ANV turns a failed execbuffer into VK_ERROR_DEVICE_LOST and prints the errno only on stderr, which WindowServer discards, so this is how the device lost seen ~20 s into compositing on the Intel GPU gets its cause.

Normal background with ANV: I915_GETPARAM -> ENODEV and GEM_CONTEXT_SETPARAM -> EPERM while it probes.

Pre-release: XeGfx does not load at boot; it is loaded and staged by hand for testing.

Passes the full automated test in N-276, 2026-10-23, Lenovo Legion 5 15IAX10 (Arc iGPU 8086:7D67, macOS Tahoe 26.7.1, BIOS Hybrid): stages 1-7, the Vulkan and Metal checks as a normal user and in WindowServer's sandbox profile, Vulkan host import of an IOSurface (1 MB, every value right, 1.7 ms), and the NvGfx xe plugin with IOSurface textures in the surface's own memory (2560x1600 blit 0.9 ms on average, every pixel right), with no panic.

Changes since 0.0.34:

• The mmu interval notifier now holds a reference on the process's mm until i915 removes it, as Linux does. i915's userptr code keeps comparing its stored mm with the caller's, and without the reference a freed mm reused by another process could match.
• Four i915 fixes from later Linux releases go into the build overlay of NvGfx xe (gpu/xkpi): 0323a5127e7c and c557fd1050f6 (GuC deregister wakeref and G2H counter underflow), 4c71fd099513 (heartbeat park double put) and 8cadce97bf26 (GSC interrupt top half with interrupts off).

You still need the userland patches from NvGfx xe (gpu/userland/patches/) and XeGfxAccel from the same branch. This is a test build. It loads idle and does nothing until a stage is requested. WindowServer on the Intel GPU is not stable yet.

SHA-256 of XeGfx-0.0.35.kext.zip: 2252a9ef49ed0b29aa245410e6fa41dcd89ec53c6c43a944400000ec995a432d

Passes the automated test in N-272, 2026-10-23, Lenovo Legion 5 15IAX10 (Arc iGPU 8086:7D67, macOS Tahoe 26.7.1, BIOS Hybrid): stages 1-7 and the Vulkan and Metal checks as a normal user, with no panic.

The new part is user memory. ANV's VK_EXT_external_memory_host now works, because i915 userptr objects can pin pages that a process owns. A Vulkan app can import an IOSurface's pages with no copy (1 MB test, every value right, 1.8 ms), and the NvGfx xe plugin uses this so that Metal textures backed by an IOSurface live in the surface's own memory. On the test machine that cut a 2560x1600 blit from about 10 ms to 0.8 ms.

Changes since 0.0.27 (0.0.28 to 0.0.30 are in the commit log):

• 0.0.31: every lock spin has a bound (150 ms with interrupts off, 2 s on) and panics with the lock's name instead of hanging the machine (debug.xegfx_spin).
• 0.0.32: vm_fault_quick_hold_pages wires the caller's range through IOKit, plus the mmu interval notifier API that i915 userptr needs.
• 0.0.33: __get_user_pages_fast goes through the same hold. The shim has no vmspace, so i915 faulted at 0xa0 when it pinned a userptr object at execbuf.
• 0.0.34: vm_page_tryxbusy for LinuxKPI's trylock_page. Freeing a pinned userptr object hit the last generated stub.

You still need the userland patches from NvGfx xe (gpu/userland/patches/) and XeGfxAccel from the same branch. This is a test build. It loads idle and does nothing until a stage is requested. WindowServer on the Intel GPU is not stable yet.

SHA-256 of XeGfx-0.0.34.kext.zip: 7fe4462f71d918574a8c93e9258958c24bffaeb721f6eb3c3148e7e029f43e32

First build that passes the whole automated test on its own: N-240, 2026-10-22, Lenovo Legion 5 15IAX10 (Arc iGPU 8086:7D67, macOS Tahoe 26.7.1, BIOS Hybrid). That covers stages 1-7, Vulkan device, compute and draw, Metal compute and draw as a normal user, and WindowServer stable for 120 s afterwards, with no panic.

Changes since 0.0.25:

• 0.0.26: clone lookups of /dev/dri nodes older than 5 s are recycled when free instances run low. Every stat holds one until devfs reclaims the vnode.
• 0.0.27: a contended mutex inside a critical section now spins instead of blocking. LinuxKPI's spin_lock pins the thread with preemption off, and Linux nests spinlocks. N-239 panicked when uncore->lock blocked under the GuC CT lock.

You still need the userland patches from NvGfx xe (gpu/userland/patches/) and XeGfxAccel from the same branch (build/nvgfx/build_nvaccel.sh xegfxaccel). Nothing is drawn to the screen through the Intel GPU yet. This is a test build that loads idle until a stage is requested.

SHA-256 of XeGfx-0.0.27.kext.zip: 4d2ec1dd394349fc37763308021e799c0cf7462f06a89ac92ec7ac2b3ea3d33f

Metal runs on the Intel GPU. Tested on the Lenovo Legion 5 15IAX10 (Arc iGPU 8086:7D67, macOS Tahoe 26.7.1, BIOS Hybrid), boots N-235 to N-238, 2026-10-22.

What this build does there, on top of 0.0.22:

• Stage 7 hands the GPU to XeGfxAccel, the NMXAccel accelerator built over XeGfx (NvGfx xe, build/nvgfx/build_nvaccel.sh xegfxaccel; not attached here because it is NvGfx code under PolyForm Noncommercial). The NvGfx Metal plugin then runs on ANV.
• Metal shows one device, "Intel(R) Graphics (ARL)". An MSL compute kernel and a render pipeline that draws a triangle both come back correct, run as a normal user.
• Render nodes are 0666, as on Linux, so apps can reach the GPU.
• GFP_ATOMIC allocations come from a reserve. i915 allocates under spinlocks, and before this an app's execbuffer panicked the kernel after a few minutes (N-237).
• 8192 node instances, plus debug.xegfx_fd and debug.xegfx_mem for diagnostics.

It needs the userland patches from NvGfx xe commit 42c941d (gpu/userland/patches/). In libdrm, a Darwin devfs clone minor maps to its DRM minor. In Mesa, host-visible BOs use the snooping write-back PAT (XNU keeps RAM write-back, so write-combining BOs lost cache lines), and anonymous files go in the per-user temp dir.

Known problem: every stat of /dev/dri/* holds a node instance until devfs reclaims the vnode, so a long session can run out. 0.0.26 on main recycles stale lookups; it has not been booted yet.

Nothing is drawn to the screen through the Intel GPU yet. This is a test build that loads idle until a stage is requested.

SHA-256 of XeGfx-0.0.25.kext.zip: ea5ca356afdeb073f307f17c4155dda98ef9df4a328917adbf42f3983c50f9f1

First XeGfx build that passed a full test boot (N-234, 2026-10-22, Lenovo Legion 5 15IAX10, Arc iGPU 8086:7D67, macOS Tahoe 26.7.1, BIOS Hybrid).

What it does on that machine:

• i915 attaches, loads the GuC (70.53.0, image linked into the kext) and enables GuC submission, SLPC and RC.
• A kernel request completes on rcs0, bcs0 and ccs0, and each engine writes a dword the CPU reads back.
• User processes get /dev/dri/renderD128 and card0: context create, buffer mapping and execbuffer work.
• With the patched libdrm (gpu/userland/patches/libdrm-xegfx.patch on NvGfx xe), Mesa's ANV creates a Vulkan 1.4 device and a compute pipeline.

What it doesn't do yet: draw anything or drive the display. WindowServer stays on the other GPU.

This is a test build. It loads idle and does nothing until a stage is requested through debug.xegfx_stage (see the README), and it is meant to be run by a guard like xe-guard that can restart the machine. mtl_guc_70.bin comes from linux-firmware under LICENSE.i915, which is included in Contents/Resources.

SHA-256 of XeGfx-0.0.22.kext.zip: c99794551e9c78825bdff780e8af03750649c2ef130747e6973320a6cd9422ca