WTLIntelGfx: Intel Xe graphics acceleration for macOS (Hackintosh)

Renamed from XeGfx on 2026-10-31; the driver and its kexts are still called XeGfx. Old links redirect here.

Real GPU acceleration for Intel Core Ultra graphics on a Hackintosh. XeGfx gives Meteor Lake and Arrow Lake iGPUs Metal and Vulkan on macOS, so the desktop, the Dock's Liquid Glass and your apps draw on the Intel GPU instead of the CPU. Apple's drivers stop at Ice Lake and WhateverGreen can't help on Xe, so without a driver like this these machines run macOS with no acceleration at all.

• Metal and Vulkan 1.4 on the Intel GPU. Apps see a Metal device named "Intel(R) Graphics" and a Vulkan device from Mesa's ANV.
• An accelerated desktop. WindowServer composites the whole desktop on the Intel GPU, and the Dock renders its Liquid Glass effect.
• The built-in panel at its real refresh rate. The panel is named from its EDID and runs at 165 Hz, with HiDPI modes.
• It shows up like a real GPU. About This Mac says "Intel Xe Graphics", and System Information shows 24 GB of shared VRAM.
• Hours of uptime. Sessions of 1, 2, 4 and 5.6 hours under a disk and Metal load script, on macOS Tahoe 26.7.1 and 26.7.2.

It runs today on:

• Arrow Lake (Core Ultra 9 275HX, 8086:7D67): our test laptop, a Lenovo Legion 5 15IAX10, and a second 275HX laptop (ArrowWhatever).
• Meteor Lake (Core Ultra 7 155H, 8086:7D55): a tester has Metal running on Sequoia with the XeGfx kernel driver unchanged and a few framebuffer and plugin tweaks of their own.

It's still a test driver. One kernel panic under heavy disk reads is open (see Status), so try it on a Mac you can afford to reboot, not one you depend on. Downloads are on the releases page, and the project page is labs.watchthelight.org/WTLIntelGfx.

The goal is one driver for every Xe generation, Tiger Lake through Lunar Lake plus Arc discrete cards, on every macOS from Big Sur 11 to Tahoe 26. Under the hood it runs Linux's i915 driver inside the macOS kernel (How it works).

Find your GPU's PCI ID with ioreg -l | grep -i '"device-id"' on macOS or lspci -nn | grep VGA on Linux. A report from your machine, working or not, is the most useful thing you can send (issue #3).

If your Tiger Lake, Alder Lake or Raptor Lake laptop only needs its panel to work, look at WhateverXe and NootedGreen first. They run Apple's own Tiger Lake driver on your GPU and are further along on those chips. XeGfx exists because that route does not reach Meteor Lake, Arrow Lake or Arc, and because a driver built from i915 can follow Intel's Linux support to new chips.

XeGfx is not a GPU driver written from scratch. FreeBSD's drm-kmod already runs i915 on a non-Linux kernel through LinuxKPI, a layer that implements the Linux kernel API on top of FreeBSD's. XeGfx adds a small FreeBSD-kernel-API layer for XNU underneath LinuxKPI, so drm core and i915 build as one kext with their sources almost untouched. In userspace, Mesa's ANV Vulkan driver talks to it through a patched libdrm, and a Metal-to-Vulkan plugin runs on ANV. The plugin and the Metal accelerator kext are forks of NullMoth's NVIDIA driver, carried here from WTLNvidiaGfx, so this repository holds the whole Intel driver, kernel to Metal. docs/HOW-IT-WORKS.md walks through each layer.

It works, for hours at a time. On the test laptop the Intel GPU runs real work for the kernel and for user processes, Vulkan and Metal both draw correctly, and since N-285 (2026-10-24) WindowServer composites the whole desktop on the Intel GPU through Metal and keeps it on the built-in panel, with the Dock's glass effect rendering. Since 0.0.45 that desktop stays up: 1, 2, 4 and 5.6 hours on N-296 to N-299, the longer runs under a disk and Metal load script, and 0.0.46 fixed the panic the 5.6 h run hit at restart (I-121). One panic is still open: a CPU rendezvous timeout (I-116) that comes back after hours of heavy disk reads (N-304). On 2026-10-28 the same 0.0.46 build passed N-305 on macOS 26.7.2 (25G332) unchanged: stages 1-7 and WindowServer stable on the Intel GPU. The drawing glitches on that desktop (I-119) are mostly fixed in the NvGfx xe plugin: on N-311 the cursor no longer draws as a square and Terminal text shows everywhere, after WindowServer got framebuffer fetch. What is left is bands of backdrop colour along full-width rows while typing; the fix for that is built but not yet tested on the Intel panel.

Everything below was proven on one machine: a Lenovo Legion 5 15IAX10 with an Intel Core Ultra 9 275HX (Arrow Lake-HX). Its integrated graphics are Xe-LPG, PCI ID 8086:7D67 (GMD_ID graphics 12.70, display 14), which i915 treats as part of the Meteor Lake family. It runs macOS Tahoe 26.7.1 (25G241) and, since 2026-10-28, 26.7.2 (25G332), with the BIOS in Hybrid graphics mode, so the built-in panel is wired to the Intel GPU. The boot IDs (N-xx) are test boots on that laptop.

What each step showed on the 7D67:

• GT up (N-229). The GuC firmware mtl_guc_70.bin (version 70.53.0) loads, with GuC submission, SLPC and RC enabled. A kernel request completed on each of the render, copy and compute engines (rcs0, bcs0, ccs0), and each one wrote a dword that the CPU read back.
• Userspace (N-230). A user process opened /dev/dri/renderD128, created a context, mapped buffers and ran execbuffer on the render and copy engines, and the results read back correctly.
• libdrm (N-233). drmGetDevices2 lists the GPU as 0000:00:02.0 8086:7d67, driver i915 1.6.0.
• Vulkan through Mesa ANV (N-234). ANV creates a Vulkan 1.4 device (API 1.4.363), "Intel(R) Graphics (ARL)", and a compute pipeline on it. A draw test (tools/vkdraw on NvGfx xe, commit 9c9cbc3) cleared a 64x64 image to red in a render pass, drew a green triangle into it (exactly 512 green pixels), copied the image to a host buffer, and the CPU read back the right pixels.
• Metal (N-235 to N-238). XeGfx's stage 7 hands the GPU to XeGfxAccel, NullMoth's NMXAccel accelerator built over XeGfx (kexts/XeGfxAccel). The Metal plugin (plugin/) then runs on ANV. Metal shows one device, "Intel(R) Graphics (ARL)". An MSL compute kernel fills 1024 values correctly, and a render pipeline draws a green triangle on red that reads back exactly. Getting there took three fixes. Render nodes are world-accessible, as on Linux. GFP_ATOMIC allocations get a reserve, because i915 allocates under spinlocks. Host-visible BOs use the GPU's snooping write-back PAT, because XNU keeps RAM write-back whatever cache mode an IOKit mapping asks for, and write-combining BOs lost cache lines to CPU write-backs.
• Desktop (N-245 to N-260). WindowServer can't open /dev/dri from inside its sandbox, so libdrm now sends its ioctls through the accelerator's IOKit user client when the node is refused (0.0.28). With that, a restarted WindowServer composites on the Intel GPU through Metal. On N-258 it stayed up through the settle, put 425 frames on the panel and kept the desktop for two hours before a kernel panic (one CPU stopped answering). On N-260 the machine froze about 20 s in, with no panic report. Frames reach the panel through a copy into the firmware's framebuffer, because macOS does not yet send display-pipe transactions to this GPU, so the desktop is slow even when it runs.
• Accelerated desktop (N-285 to N-289, 2026-10-24). WindowServer now runs on the Intel GPU and stays up: on N-285 it passed the guard's settle window and served the desktop for about four minutes, with 3660 display transactions and no failed frames. The fix that got it there was in the Metal plugin: WindowServer hands it some buffers that are not all writable memory, and importing those as host pointers lost the device about 20 s in, so the plugin now copies them instead. The Dock renders its Liquid Glass effect, which needs working GPU compositing. XeGfxIntelFB 0.5 sets the GPU's model name, so About This Mac and System Information show "Intel Xe Graphics".
• What still breaks. One panic is understood and fixed: a lock that sleeps was taken inside an RCU read section on the mmap path WindowServer uses (0.0.42 takes the locks in the other order). The other is not: 15 to 45 seconds into some runs one CPU keeps interrupts off for over half a second and macOS panics because that CPU does not answer a rendezvous. GPU interrupts keep arriving and are handled right up to the end. 0.0.43 adds a watchdog that names that CPU and what it was running before macOS gives up. Turning the NVRAM trace off made it much rarer (on this firmware its NVRAM writes run in SMM, where a CPU cannot answer the rendezvous), but it came back on N-304 after 4 h 19 min under heavy disk reads with the trace off, so that was not the whole cause.

The open problems are tracked in WTLNvidiaGfx #12 and #18.

The source is at 0.0.46 (CHANGELOG), which is also the newest booted version. With the NVRAM trace off (xegfx.nvram_trace=0) the Intel desktop ran one hour on N-296, then two hours (N-297), four hours (N-298) and 5.6 hours (N-299) while a load script wrote about 225 GB to disk and ran Metal draws every 22 seconds. N-304 then hit I-116 after 4 h 19 min while another process read the kernel collections over and over, so the stall is rarer, not gone. 0.0.46 fixes the panic that N-299's restart hit (I-121). On the Intel GPU, System Information now shows 24 GB of shared VRAM, and the panel is named from its EDID and runs at 165 Hz with the HiDPI mode. The newest test build is the v0.0.46 prerelease. Desktop runs need the accelerator and plugin from this repository as well.

VedCloud's Meteor Lake port got to a GPU-composited desktop first: it runs an i915-derived driver with Metal and Vulkan on a Dell Latitude 5350 under macOS 15. XeGfx takes a different road (unchanged drm-kmod sources over its own shim) and targets Tahoe as well.

• drm-kmod never turns the GuC on in FreeBSD builds, and Meteor Lake and Arrow Lake cannot submit work without it, so XeGfx sets enable_guc=3 by default.
• OSKextRequestResource does not serve the Resources of a kext that lives in the auxiliary kernel collection, so the GuC firmware is linked into the kext binary. That is also why other generations need their own firmware linked in before they can be tried.
• XNU devfs clone nodes give every stat and open its own minor number, so libdrm could not match an open file to its /dev/dri node. The patched libdrm matches nodes by slot instead.
• WindowServer's sandbox refuses /dev/dri, which is why the desktop path goes through IOKit instead.

XeGfx is built on other people's work. Thanks to all of them.

Code XeGfx builds or ships (their licences apply to their files):

Projects we studied (ideas, findings and warnings only; no code copied):

Testers (reports from machines other than ours; every result counts, working or not):

A broken GPU driver can stop a machine before anything reaches the disk, so the kext is built to be harmless until asked:

• It never loads at boot. Its only IOKit personality waits for a resource the kext publishes itself, after kmutil load -b org.watchthelight.XeGfx. If a test crashes the Mac, it reboots into a system where XeGfx is not loaded.

• It runs in stages, one sysctl write at a time:

  debug.xegfx_stage	What runs
  1	the shim's own state (clock, threads, VM, tunables, task queues)
  2	a read-only look at the GPU: IDs, BAR sizes, GMD_ID, stolen-memory base, pipe A registers, the GGTT entry behind the panel, PCH watchdog registers, published as the XeGfxProbe registry dictionary
  3	newbus over every PCI device, the DMA layer
  4	the drm and i915 init routines, i915 display disabled, then a check that the panel still scans out the same memory and pipe A still counts frames

• A stage that runs longer than debug.xegfx_wdog seconds panics on purpose, so a stall becomes a panic report and a reboot instead of a frozen screen.

• debug.xegfx_log returns the last 64 KiB of the driver's own console output, and debug.xegfx_results the result of each stage.

• debug.xegfx_env sets tunables for the next stage (compat.linuxkpi.i915_enable_guc=3 and the like), so one boot can try several settings.

• The link fails if the kext redefines any symbol the kernel exports (tools/shadow_check.py). That bug class killed the first two hardware tests.

You need the Xcode Command Line Tools (clang and the macOS SDK; the scripts are tested with SDKROOT set to the 15.5 SDK) and Python 3. Third-party sources are not in the repository:

• ~/src/xe-src: sparse clones of linux (the Linux kernel), freebsd (LinuxKPI lives in sys/compat/linuxkpi), drm-kmod (commit c16de0f, Linux 6.14 level) and linux-firmware (mtl_guc_70.bin and LICENSE.i915, linked into the kext)
• ~/src/deps/open-gpu-${NVRM_TAG:-615.78.08}: NVIDIA's open-gpu-kernel-modules, whose headers XeGfxAccel compiles against
• ~/src/deps/Vulkan-Headers: Khronos Vulkan headers for the plugin
• rustup stable for the translator, and the Mesa and libdrm trees userland/BUILD.md lists

build/build_xegfx.sh          # XeGfx.kext into out/: objects, licence gate, link, KPI / shadow / kcabi checks
build/build_xegfxaccel.sh     # XeGfxAccel.kext, the Metal accelerator
build/build_xegfxintelfb.sh   # XeGfxIntelFB.kext
build/build_xegfxagdc.sh      # XeGfxAGDC.kext
build/build_nmintelfb.sh      # NMIntelFB.kext, the boot framebuffer on the iGPU
build/build_plugin.sh         # the Metal plugin, NVMTLDriver (RELEASE=1 for a release build)
build/build_xlate.sh          # libnvmtl_translate.dylib, Metal AIR to SPIR-V
userland/scripts/build_*.sh   # libdrm, Mesa ANV and the Vulkan loader
sudo tools/install.sh         # into the auxiliary kernel collection (XEGFX_MODE=uninstall to remove)

Kexts and the plugin land in ~/src/XeGfx-build (OUTROOT, XEGFX_OUT). build/xeaccel-pkg and build/xeintelfb-pkg hold install scripts that swap one kext in the auxiliary collection and keep a backup. tools/kpi_split.py and the link check use WTLKcAbi, expected in ~/src/kcabi.

Until 2026-10-30 everything outside shim/, harness/, tools/ and docs/ lived in the NvGfx fork (branches xe and xe-2.6.2); its history is there. Fixes to the shared Metal plugin are ported between the two repositories.

Testers with any Intel Xe machine are the most useful thing right now, and so is anyone who knows XNU, IOKit or i915 internals. See CONTRIBUTING.md and the open issues.

Mixed, by folder. The kernel shim, the build scripts and the tools are under the BSD 2-Clause license (LICENSE). The Metal plugin, the accelerator, XeGfxAGDC and NMIntelFB are forks of NullMoth's driver and stay under PolyForm Noncommercial 1.0.0 (licenses/): no commercial use. The translator is LGPL-3.0. NOTICE has the full table.