SNA vs. UXA: A 2025 Guide to Intel’s 2D Acceleration on Linux

TL;DR: SNA is a faster 2D acceleration architecture for Intel graphics on X.org that replaced the older UXA. While benchmarks proved SNA’s superiority, it could be unstable. Today, this choice is mostly irrelevant, as the recommended approach for most Intel GPUs is the generic modesetting driver, which uses Glamor acceleration.

If you’re digging through configuration files to optimize your Linux desktop, you’ve stumbled upon a classic, almost legendary debate: SNA vs. UXA. For years, choosing the right 2D acceleration method for your Intel graphics card was a critical step for getting a snappy, responsive desktop.

This choice defined an entire era of Linux tweaking. But this is 2025. Is it still relevant?

Let’s dive into what SNA and UXA are, which one won the performance crown, and—most importantly—what you should actually be using on a modern system for the best performance and stability.

🧐 What Are SNA and UXA? A Quick History Lesson

Both SNA and UXA are 2D acceleration architectures. Their job is to offload simple drawing tasks (like rendering windows, text, and interface elements) from the CPU to the Intel GPU. They both live within a specific driver package for the X.Org display server called xf86-video-intel.

The xf86-video-intel Driver

Think of this as the specialized, hand-tuned driver for Intel GPUs on X.Org. For a long time, if you had an Intel chip, this was the driver you wanted. It contained several acceleration methods that evolved over time, with UXA and SNA being the most prominent.

UXA (UMA Acceleration Architecture)

For many years, UXA was the reliable workhorse. It replaced an even older method (EXA) and was the default choice on most Linux distributions. It was known for being incredibly stable and compatible across a wide range of Intel hardware. Its performance was decent, but as desktop environments became more graphically demanding, it started to show its age.

SNA (Sandy Bridge New Acceleration)

SNA arrived as a complete, ground-up rewrite by an Intel developer. As the name implies, it was optimized for the “Sandy Bridge” generation of processors and beyond. Its goal was simple: raw speed. SNA was designed to be much more aligned with how modern GPUs work, leading to a dramatic increase in 2D rendering performance. It was more complex, but the promised speed-up was huge.

🚀 The Verdict: Performance vs. Stability

The battle between UXA and SNA was essentially a trade-off. Do you want rock-solid stability or bleeding-edge speed?

Speed Tests: No Contest

On the performance front, it wasn’t even a fair fight. SNA was significantly faster than UXA in almost every measurable way. Benchmarks from sites like Phoronix in the early 2010s consistently showed massive gains.

A simple gtkperf test, which measures the performance of standard GTK interface elements, tells the whole story. Here are some results from a Core i5 “Sandy Bridge” laptop:

As you can see, SNA delivered a much snappier experience, especially for drawing-heavy tasks.

The Other Side of the Coin: Glitches and Bugs

This speed came at a cost. SNA’s complexity meant it was more prone to bugs. Users frequently reported issues like screen tearing, graphical artifacts, and, most commonly, a system that wouldn’t wake up properly after being put to sleep (suspend/resume).

For many, UXA’s reliability was preferable to SNA’s sometimes-unstable speed. This led to years of forum posts and wiki articles guiding users on how to switch back to UXA to fix these kinds of problems.

🔧 The “Legacy” Method: How to Switch Between SNA and UXA

Insight: Heads Up! This configuration is primarily for older systems (think pre-2015) or for very specific troubleshooting. For most users, the next section on the modesetting driver is the correct path forward.

If you’re running an older distribution or have a specific need to force one method, here’s how it’s done.

Step 1: Check Your Current Method

First, see what your system is using. The X.org log file will tell you. Open a terminal and run:

grep -i "AccelMethod" /var/log/Xorg.0.log

You’ll likely see a line indicating that SNA or UXA is the chosen acceleration method.

Step 2: Create a Config File

You can override the default by creating a small configuration file.

Create the file /etc/X11/xorg.conf.d/20-intel.conf. You’ll need root privileges to do this (sudo).

[IMAGE: A screenshot of a terminal editing the 20-intel.conf file.]

To force SNA for maximum performance, add this content:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "sna"
EndSection

To force UXA for maximum stability, use this instead:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "uxa"
EndSection

Save the file and reboot your computer. Your system will now use the acceleration method you specified.

✨ The 2025 Recommendation: Forget SNA/UXA, Use modesetting

Here’s the real takeaway: the SNA vs. UXA debate is history. For almost any Intel-powered machine made in the last decade, you shouldn’t be using the xf86-video-intel driver at all.

Why the xf86-video-intel Driver is Fading

Development on this specialized driver has effectively stopped. While it was once essential, the Linux kernel and the generic drivers have become so good that it’s now considered a legacy package. In many cases, it can cause more problems than it solves on modern hardware.

The Modern Champion: The modesetting Driver

Today, the best performance and stability come from the modesetting driver. It’s not a separate package you install; it’s built directly into the X.org server itself. It works directly with the graphics components of the Linux kernel (known as Kernel Mode Setting or KMS) to provide a streamlined, stable, and performant experience.

Meet Glamor: The New Acceleration Engine

The modesetting driver uses its own acceleration technique called Glamor. It cleverly accelerates 2D drawing operations by translating them into 3D operations (using OpenGL). Since all modern GPUs are highly optimized for 3D, this approach is both fast and robust. It avoids the pitfalls of specialized 2D methods like SNA and UXA.

How to Use the modesetting Driver

The best part? Using it is incredibly simple. The goal is to make X.org fall back to the modesetting driver automatically. You do this by simply ensuring the old Intel driver is not installed.

For Debian/Ubuntu-based systems:

sudo apt remove xserver-xorg-video-intel

For Arch Linux-based systems:

sudo pacman -Rns xf86-video-intel

After uninstalling the package, reboot your computer. X.org will not find the intel driver and will default to modesetting. You’ll get modern, maintained, and performant graphics without any configuration files.

❓ Frequently Asked Questions

So, is SNA better than UXA?

Yes, from a pure performance perspective, SNA was much faster. But it could be less stable. However, the question is largely academic now, as neither is the best option for modern systems.

What is the difference between Glamor, SNA, and UXA?

UXA and SNA are 2D-specific acceleration methods within the old xf86-video-intel driver. Glamor is a more modern acceleration method used by the generic modesetting driver that translates 2D operations into 3D (OpenGL) ones.

Is there any reason to still use xf86-video-intel (SNA/UXA)?

Very rarely. You might need it for some very old Intel hardware (pre-2007) that doesn’t work well with the modesetting driver, or to work around a specific bug. For 99% of users, modesetting is the superior choice.

Does any of this matter on Wayland?

Not at all. SNA, UXA, xf86-video-intel, and the modesetting X.org driver are all components of the X Window System. Wayland is a completely different display server protocol with its own architecture. This entire debate is irrelevant in a Wayland session.

Sources

Intel Ivy Bridge Acceleration Of UXA vs. SNA

Intel Ivy Bridge: UXA vs. SNA – Updated Benchmarks

Intel Graphics – ArchWiki