Actually, I should clarify — if you’ve spent any time messing around with Linux on ARM devices, you probably know the pain. You buy a shiny new Single Board Computer (SBC) or a Chromebook, look at the specs, and see a decent GPU. “Great,” you probably think. “I can run a smooth desktop environment on this.”

But reality has a way of hitting you in the face. The vendor kernel is typically stuck on version 4.4 from six years ago, and the graphics acceleration relies on a binary blob that breaks every time you look at it funny. It’s been the curse of ARM Linux for a decade.

But today, the situation for Mali GPUs just got significantly less painful. The Panfrost driver stack has officially landed support for the Valhall architecture—specifically the Mali-G57. And we aren’t talking about experimental “it renders a triangle if you squint” support. This is fully conformant OpenGL ES 3.1.

Why Valhall Was Such a Headache

For the uninitiated, ARM’s Mali GPUs have gone through a few architectures. We had Utgard (ancient), Midgard, Bifrost, and now Valhall. Panfrost has handled the older stuff pretty well for a while now. I’ve been running GNOME on my RK3399 boards (Midgard) with open drivers for years, and it’s buttery smooth.

But Valhall? That was a different beast. ARM switched things up internally. They moved to a scalar instruction set architecture (ISA), which is generally more efficient for modern compilers than the old vector-based approaches. And while that’s great for performance, it meant the reverse-engineering team had to figure out a whole new instruction set. It wasn’t just a copy-paste job from the Bifrost code.

And as I was digging through the Mesa git log earlier this morning, the commit activity has been frantic. The final patches for G57 support just merged. This is huge because the G57 is everywhere — it’s in a ton of mid-range MediaTek chips found in Chromebooks and budget tablets that, until now, were basically paperweights for mainline Linux enthusiasts.

The “Conformant” Big Deal

The key phrase here is “OpenGL ES 3.1 conformant.”

In the graphics driver world, you can hack something together that runs Quake 3 but crashes if you try to open a web browser. Conformance means it passes the dEQP (drawElements Quality Program) test suite. It guarantees that the driver actually behaves the way the API spec says it should.

And ES 3.1 is the sweet spot. It brings compute shaders to the table. This opens up a lot of modern software that uses the GPU for more than just pushing pixels. If you’re trying to run a modern Wayland compositor like Sway or Hyprland on ARM, having a compliant driver prevents those weird visual artifacts — you know, the flickering textures or fonts that turn into black boxes.

Testing It Out (Don’t Panic If It Breaks)

Well, I decided to pull the latest Mesa main branch to see what’s what. And I’m testing this on a generic MT8192-based board I have lying around which uses the G57 MC5.

And here’s a quick way to check if your system is actually picking up the Panfrost driver instead of falling back to software rasterization (llvmpipe):

# Install glmark2-es2 if you haven't
sudo apt install glmark2-es2

# Run it and check the renderer string
glmark2-es2 --info | grep "GL_RENDERER"

# If you see "llvmpipe", you're still on software rendering.
# You want to see "Mali-G57" or "Panfrost"

And when I finally got the stack aligned — Mesa 26.0-devel and the patched kernel — the difference was night and day. Glmark2 scores jumped from a pathetic 120 (software) to over 1400. But more importantly, I fired up Firefox, forced WebGL, and it didn’t crash. That’s the bar we’re clearing today.

What’s Next? Vulkan.

OpenGL ES 3.1 is fantastic for desktop environments and older games. But the elephant in the room is Vulkan. The PanVK driver is the next frontier. And now that the Valhall ISA is well-understood for OpenGL, porting that knowledge to the Vulkan driver should be faster, but it’s still a massive undertaking.

I probably wouldn’t expect fully conformant Vulkan on Valhall by next week. But maybe by late 2026 or early 2027, we’ll see serious movement there. For now, though, enjoy the fact that your Mali-G57 device is finally a first-class citizen in the Linux world.

And honestly, seeing reverse-engineered drivers outperform and outlive the vendor blobs never gets old. It’s the best part of this ecosystem.

FAQ

What is Panfrost Valhall support and which Mali GPU does it cover?

Panfrost is the open-source driver stack for ARM Mali GPUs, and it has officially landed support for the Valhall architecture, specifically the Mali-G57. This isn’t experimental — it’s fully conformant OpenGL ES 3.1, meaning it passes the dEQP test suite. The G57 ships in many mid-range MediaTek chips found in Chromebooks and budget tablets that were previously unusable with mainline Linux.

Why was Valhall harder to reverse-engineer than Bifrost or Midgard?

ARM changed the internals significantly with Valhall, moving to a scalar instruction set architecture instead of the older vector-based approach. While scalar ISAs are generally more efficient for modern compilers, the switch meant the reverse-engineering team couldn’t simply copy-paste from the existing Bifrost code. They had to figure out an entirely new instruction set from scratch, which is why support took considerably longer to land.

How do I check if my Linux system is using Panfrost instead of llvmpipe?

Install glmark2-es2 with your package manager, then run `glmark2-es2 –info | grep “GL_RENDERER”`. If the output shows “llvmpipe”, you’re still falling back to software rasterization. You want to see “Mali-G57” or “Panfrost” in the renderer string, which confirms hardware acceleration is active. The author saw glmark2 scores jump from around 120 on software to over 1400 once Panfrost was working.

When will Vulkan support land for Mali-G57 via PanVK?

OpenGL ES 3.1 conformance is done, but Vulkan via the PanVK driver is still the next frontier and a massive undertaking. Now that the Valhall ISA is well-understood from the OpenGL work, porting that knowledge should go faster. The author wouldn’t expect fully conformant Vulkan on Valhall imminently, but suggests serious movement is plausible by late 2026 or early 2027.