Intel's New Jay Shader Compiler Just Merged Into Mesa — And Early Results Are Stunning

Something significant just landed in Mesa's codebase. The Intel Jay shader compiler — a ground-up replacement for the aging BRW compiler that has powered Intel's open-source Linux GPU drivers for years — was publicly announced on April 7, 2026, and merged into Mesa 26.1-devel just three days later on April 10. The early performance numbers that came with the announcement are not subtle: on a demanding real-world test, Jay produces nearly half the machine instructions of BRW and compiles them in roughly a third of the time. For anyone running Intel integrated or discrete graphics on Linux, this is one of the most consequential developments in the open-source Intel driver stack in years.

The compiler is still experimental and not ready for daily use, but the decision to move development upstream into Mesa rather than continuing to work on it out-of-tree means that progress will now happen in the open, visible and accessible to the broader Mesa developer community. Here is what Jay is, why it matters, who built it, and what the benchmarks actually tell us about where Intel Linux graphics performance is headed.

What Is the Jay Shader Compiler?

A shader compiler is the piece of software that translates the high-level shader programs that games and applications write — in languages like GLSL, HLSL, or SPIR-V — into the low-level machine instructions that a specific GPU can actually execute. The quality of that translation process matters enormously for performance. A compiler that generates redundant instructions, handles register allocation poorly, or takes a long time to compile complex shaders creates a real and measurable penalty: slower frame rates, longer load times, and the stuttering that occurs when shaders compile mid-game rather than up front.

For Intel GPUs running on Linux, the shader compiler within Mesa has historically been BRW — a compiler that has served the Intel driver stack for a very long time and been incrementally improved over the years, but which was designed around older architecture constraints and compiler design philosophies that the field has moved well beyond. Jay is built from scratch with modern compiler design principles, specifically the Static Single Assignment (SSA) form that the best GPU compilers in Mesa today are built around.

Jay targets Intel's open-source Linux drivers: specifically the ANV Vulkan driver and the Iris Gallium3D OpenGL driver. These are the drivers that most Linux users with Intel hardware are running, whether on Iris Xe integrated graphics inside a laptop or on Arc discrete GPUs. The BRW compiler that Jay is designed to replace serves both of these drivers currently.

Who Built It: Alyssa Rosenzweig and Intel's Open-Source Team

Jay was created by Alyssa Rosenzweig, who joined Intel's Linux graphics driver team last year after an extraordinary track record in the open-source graphics world. Rosenzweig is best known for leading the development of open-source drivers for Apple Silicon GPUs as part of the Asahi Linux project — work that involved reverse-engineering undocumented hardware from scratch and writing conformant OpenGL 4.6, OpenCL 3.0, and Vulkan 1.4 drivers for Apple's GPU architecture. She also has deep experience with NIR, the common shader compiler infrastructure that underlies nearly all modern Mesa GPU drivers, having been one of its primary maintainers.

Before joining Intel, Rosenzweig also worked as a contractor for Valve on the Linux graphics stack — giving her direct exposure to the kinds of real-world gaming workloads that tend to stress shader compilers most aggressively. She brings that experience directly to Jay's design.

The expertise Rosenzweig developed building the AGX compiler for Apple Silicon — a thoroughly modern SSA-based design tailored to unusual and complex hardware — maps directly to what Intel needs for Jay. Intel's GPU register architecture has its own unusual constraints around "register regioning" that traditional compiler designs struggle to handle cleanly. Jay was built explicitly to address those constraints with a modern approach from the ground up.

How Jay Works: SSA, NIR, and Modern Compiler Design

Jay's design follows the same architectural philosophy as the most successful modern GPU compilers in the Mesa ecosystem. In Rosenzweig's own words in the initial Mesa merge request: "Jay's design is similar to other modern NIR backends, particularly ACO, NAK and AGX."

Those three references are worth unpacking for context. ACO is the shader compiler AMD and Valve developed together for the RADV AMD Vulkan driver — it replaced the older LLVM-based backend and delivered major performance improvements and reduced compile times for AMD hardware on Linux. NAK is Nouveau's new shader compiler for Nvidia GPUs, built on the same principles. AGX is Rosenzweig's own Apple Silicon compiler from Asahi Linux. All three follow the same modern design pattern: fully SSA-based, clean NIR as the input representation, and hardware-specific backends that handle the unique constraints of their target GPU architectures without the baggage of older general-purpose compiler infrastructure.

Jay is fully SSA, meaning every value in the compiler's intermediate representation is defined exactly once. This property makes many optimization passes dramatically simpler and more effective. The compiler deconstructs SSA "phi nodes" after register allocation rather than before — a design choice that keeps the optimization pipeline cleaner for longer.

The Register Allocator

One of the technically interesting aspects of Jay is its choice of register allocator. Jay uses a Colombet register allocator, the same type used in NAK for Nvidia's hardware. This is a significant choice for Intel specifically because Intel's GPUs have complex "register regioning" rules — constraints on how registers can be addressed and combined that are considerably more complicated than what most other GPU architectures impose. Rosenzweig noted in the merge request that the Colombet allocator allows Jay to "handle Intel's complex register regioning restrictions in a straightforward way." Braun-Hack SSA construction is used for spilling logical registers, though Rosenzweig hinted that the full technical detail on how this maps to Intel's hardware will be presented at XDC (the X.Org Developer Conference), which is being held in Toronto this year — a detail she noted with a pun, since "Jay" is also a bird common in North America.

What Jay Is Written In

Jay is written in C and comes in at just over 14,000 lines of new code in its initial upstream merge. That is a compact, focused implementation for a compiler of this scope — a reflection of both the clean SSA-based design and Rosenzweig's experience writing efficient compiler backends for unusual GPU architectures.

The Performance Numbers: Nearly 3x Faster Than BRW

The benchmark Rosenzweig shared in the merge request is deliberately described as "a nasty CTS test" — CTS standing for the Conformance Test Suite, the standardized test suite that graphics drivers must pass to be considered conformant. The specific test is math_bruteforce sin, which stress-tests the compiler's ability to handle complex math shader code. This kind of test is representative of the worst-case scenarios that shader compilers encounter with demanding real-world workloads.

The results are striking:

• Jay: 6,768 instructions generated — 361 spills, 396 fills — compiled in 7.00 seconds
• BRW: 12,980 instructions generated — 578 spills, 1,144 fills — compiled in 19.91 seconds

Jay generates 48% fewer instructions than BRW on this test — roughly half the machine code for the same shader. It also produces dramatically fewer register spills and fills, which are operations that occur when the compiler runs out of registers and has to temporarily store values in slower memory. BRW generates 1,144 fill operations on this test; Jay generates 396 — a reduction of 65%. And Jay does all of this nearly three times faster: 7 seconds versus nearly 20 seconds for BRW.

Rosenzweig's comment on the result was understated: "Better code than the current compiler in a fraction of the time... the future looks bright for Mesa compilers on Intel."

It is worth noting that this is a single worst-case benchmark, not a comprehensive suite across all shader types. Real-world improvements will vary by workload. But the direction is unambiguous, and the magnitude of the advantage on a deliberately difficult test is a very strong signal that Jay's fundamental architecture is superior to BRW's for modern workloads.

What Hardware Jay Supports

In its initial upstream state, Jay targets Intel Xe2 hardware — Intel's most recent discrete GPU architecture, covering Arc B-series graphics cards like the Arc B580. This is where Rosenzweig's team has been focusing development and where conformance testing has been concentrated.

However, the Phoronix report on the Mesa 26.1 merge notes that the plan is to expand Jay's hardware support to cover Intel Skylake "Gen9" graphics and newer as development matures. Gen9 covers Intel integrated graphics going back to 6th-generation Core processors (Skylake, 2015), meaning that Jay's eventual scope will encompass the vast majority of Intel GPU hardware in active use on Linux systems today — from years-old laptop iGPUs all the way up to current Arc discrete cards.

Conformance Status

On Xe2 hardware, Jay can already pass OpenGL ES 3.0 and OpenCL 3.0 conformance testing. Vulkan conformance is still in progress. These are meaningful milestones: OpenGL ES 3.0 compliance means the compiler can correctly handle the full range of shader programs that the vast majority of OpenGL applications use on Linux, and OpenCL 3.0 covers compute shader workloads as well. Full Vulkan compliance, once achieved, will be the final gate before Jay becomes a realistic candidate for enabling by default in production driver builds.

Jay vs. Intel's Other Shader Compiler: Why Not IGC?

One question the announcement raises for anyone familiar with Intel's software ecosystem is why Jay is being developed at all when Intel already has a highly capable shader compiler in IGC — the Intel Graphics Compiler. IGC is the compiler used by Intel's Compute Runtime for OpenCL and Level Zero on Linux, and it is also the shader compiler that Intel uses on Windows for graphics workloads. It is a sophisticated piece of software that works well in its domain.

Phoronix's Michael Larabel notes that Intel had previously explored the possibility of using IGC for their Mesa drivers — replacing BRW with the same compiler that powers their Windows graphics stack. The decision to develop Jay instead reflects a deliberate choice to have a compiler designed specifically for Mesa's architecture and idioms rather than adapting an external compiler stack. IGC carries significant complexity and dependencies from its Windows lineage and compute focus. Jay is designed from the ground up as a Mesa-native NIR backend, sitting comfortably alongside ACO, NAK, AGX, and the other modern Mesa compilers in the same architectural family.

This is the same reasoning that led AMD and Valve to build ACO rather than continuing to rely on LLVM for RADV. The Mesa-native approach gives developers more direct control over the compiler's behavior, makes it easier to optimize for Mesa's specific needs, and reduces external dependencies. Jay follows that established pattern.

Why This Matters for Linux Gaming and Intel GPU Users

For practical purposes, what Jay's development means for Linux users running Intel hardware comes down to three things: fewer shader compilation stalls, better frame rates, and improved stability from cleaner code generation.

Shader compilation stalls are one of the most visible quality-of-life problems in Linux gaming. When a game encounters a shader it has not compiled before, the GPU stalls while the CPU compiles it — causing the characteristic frame drops and micro-stutters that Linux gamers know well, particularly on the first run through a new area or after a game update. A faster compiler reduces the duration of these stalls. A compiler that generates fewer instructions produces shaders that run faster once compiled, improving baseline frame rates and frame consistency.

The spill/fill reduction is particularly relevant for complex shaders. Register spills cause the compiler to store data in slower GPU memory when it runs out of registers, and fills retrieve it when needed — both operations incur real performance costs at runtime. Jay's dramatic reduction in spills and fills on the test case Rosenzweig shared suggests that shaders generated by Jay will be not just faster to compile but faster to actually execute on the GPU.

Intel's Arc discrete GPU lineup has had a sometimes mixed reputation on Linux in terms of driver maturity compared to AMD and Nvidia, though the situation has improved considerably over the past two years. Jay represents one of the most significant architectural investments Intel has made in its Mesa driver stack and is a strong signal of long-term commitment to making Intel graphics on Linux a first-class experience.

When Will You Be Able to Use Jay?

The honest answer right now is: not yet, and not soon. Rosenzweig's own message in the merge request was explicit: "It isn't ready to ship, but we'd like to move development in-tree rather than rebasing the world every week. Please don't bother testing yet — we know the status and we're working on it." Moving development upstream into Mesa 26.1 is about enabling faster iteration with the broader Mesa community, not about putting Jay in users' hands.

The path to Jay being usable by regular Linux GPU users will require at minimum: completion of Vulkan conformance testing, expansion of hardware support beyond Xe2 to older Intel generations, substantial additional testing and bug-fixing, and ultimately a decision by Intel's Mesa team about when Jay is ready to be offered as an opt-in or default compiler. Given the scope of those steps, it would be realistic to expect Jay to reach experimental-opt-in status sometime in 2026 or 2027 at the earliest, with default enablement following after sufficient validation.

In the meantime, the fact that development is now in-tree in Mesa 26.1 means that anyone building Mesa from source can follow Jay's progress directly, and the Mesa community can contribute reviews and fixes as the compiler matures. That is exactly how ACO went from early experimental code to the default AMD compiler in Mesa — a process that took about two years from initial merge to widespread default enablement, and that ultimately transformed AMD Linux gaming performance. Jay has every reason to follow a similar trajectory for Intel.

Want more coverage of Linux graphics, open-source driver development, and GPU performance on Linux? Browse our other posts for the latest.