Bannerlator · 3.1.4 · October 2026

OpenGL games now run 4 to 5 times faster

Older games that use OpenGL, and old DirectDraw games, used to run slowly in Bannerlator's normal display mode (X11). Now they run several times faster, on every Wine version. It's on automatically. You don't have to do anything. And as a bonus, a fix in the Turnip driver makes DirectX 12 games faster too.

5×faster on Wine 9.5386 → 1989 fps
5×faster on GE-Proton 10381 → 1906 fps
4×faster on Proton 11 x86_64390 → 1502 fps
3–4×faster on Wine 11 / Proton 11364 → 1239–1455 fps
Question 1

Do I need to do anything?

No.

The new setting is called Fast OpenGL and it's on by default. The app picks the right method for your Wine version by itself.

The only thing it needs is a Turnip graphics driver, which most people already use. With the Qualcomm or System driver it stays off.

If one game ever acts strange, you can switch Fast OpenGL off for just that game: game settings → OpenGL card → Fast → Off.

Question 2

Which games get faster?

Games that use Vulkan or DirectX 8–12 don't change. They were already fast (more on that below).

Question 3

Why was it slow before?

Think of each frame of a game as a painting. The graphics chip is the painter, and your screen is the wall it hangs on.

Before: after every painting, the painter had to stop. Someone took a photo of the painting, carried the photo over, and hung the photo on the wall. That happened hundreds of times every second, so the painter spent most of its time waiting.

Now: the painting goes straight onto the wall. No stopping, no photo.

BeforeGame draws→Stop and wait→Copy the picture→Send the copy→Screen
NowGame draws→Straight to the screen

Vulkan and DirectX games always went straight to the screen. Now OpenGL games do too.

Question 4

How much faster is it?

These are frames per second (fps). Higher is better. Orange is before, blue and green are after. Tap a bar to see the exact number.

OpenGL test, every Wine versionSame phone, same day, Fast OpenGL off vs on
Old DirectDraw game testSame phone, same day, Fast OpenGL off vs on
See it for yourself

Before and after pictures

Real screenshots from the tests. Left is before, right is after. Look at the big number: that's frames per second. Tap the arrows or swipe to see the next one.

  • Wine 11 arm64ecOpenGL cubeWine 11 method×3.4
    Wine 11 arm64ec, OpenGL cube, before, averaging 364 fps
    Before364 fps avg
    Wine 11 arm64ec, OpenGL cube, EGL road, averaging 1239 fps
    After1,239 fps avg

    Before at 9:00, after at 9:56, same container.

1 / 8
Question 5

Does it work with my Wine version?

Wine versionFaster?Tested
Wine 11 / Proton 11 (arm64ec)
GE-Proton 11.0-7, Proton 11.0-2 and others		✓ YesYes, on the phone
Proton 11 x86_64✓ YesYes, on the phone
Proton 10 / Wine 10
GE-Proton 10.0-34 and others		✓ YesYes, on the phone
Wine 9.5 x86-64✓ YesYes, on the phone
Wayland mode (any version)✓ Always was fastYes
Question 6

Will it change my other games?

No.

Vulkan and DirectX games run exactly the same. We tested every Wine version with Fast OpenGL off and then on:

Wine versionVulkanDirectX 11DirectX 12
Wine 111686 → 16962172 → 21562385 → 2356
GE-Proton 102116 → 21302365 → 23542406 → 2457
Proton 11 x86_641442 → 14382036 → 20382244 → 2238
Wine 9.51994 → 20092187 → 21812269 → 2267

The numbers move up and down by 1 or 2 percent, which is normal from one run to the next.

Will my game run in fast-forward? No. More fps means smoother motion, not a sped-up game. A few very old games tie their speed to the frame rate; use the FPS limiter for those.

Question 7

What about Wayland mode?

Wayland mode never had the slow photo-copy step, so OpenGL was always fast there. We still fixed three things that held it back:

Question 8

Did you need freedreno for this?

No.

Freedreno is a separate OpenGL driver that some other apps (Ludashi, for example) use to make OpenGL fast. We didn't add it.

Everything here runs on Turnip, the same driver your Vulkan and DirectX games already use. A translator called Zink turns OpenGL into Vulkan. So you keep one driver for everything, and nothing extra to install.

We haven't tested freedreno side by side, so we're not saying we beat it. Only that we didn't need it.

Bonus

DirectX 12 got faster too

While testing, we found a bug in the Turnip graphics driver itself that held back DirectX 12 games. We fixed it.

The bug in plain words: many times every frame, a DirectX 12 game asks the driver a quick question: "is the graphics chip done yet?" The answer should come back instantly. Instead, Turnip passed the question to Android's Adreno driver in a way that it read as "wait until it's done". So the processor sat and waited for the graphics chip, every frame, instead of getting the next frame ready. The two took turns instead of working at the same time.

The fix: for those quick questions, Turnip now just reads the chip's "finished" counter and answers right away. Nothing else changes.

TestX11Wayland
DirectX 12 demo378 → 1422 (×3.8)588 → 3449 (×5.9)
DirectX 12 Hello Triangle264 → 451 (×1.7)566 → 880 (×1.6)

Who gets it

Anyone using Banners-Turnip v26.3.0-20260929-r4 or newer, on X11 and Wayland. On Wayland, Bannerlator 3.1.4's built-in adapter also applies the fix to any Turnip you pick.

Which games gain

DirectX 12 games, most of all ones that run at high frame rates or lean on the processor. Heavy games that already max out the graphics chip gain less: one player's game went from 94% to 99% GPU use, 47 to 50 fps.

What it doesn't touch

DirectX 8–11 (DXVK) and Vulkan games don't ask that question every frame, so they run the same. We checked: no slowdown anywhere else.

For the technical reader: in Turnip's KGSL backend, a timeline poll with a zero timeout was sent as IOCTL_KGSL_DEVICE_WAITTIMESTAMP_CTXTID with timeout 0, which the kernel treats as "wait forever". The patch answers polls with IOCTL_KGSL_CMDSTREAM_READTIMESTAMP_CTXTID instead. Full write-up: KGSL_ZERO_TIMEOUT_POLL.md.

  • DirectX 12 demoX11×3.8
    DirectX 12 demo on X11, before the fix, 378 fps
    Before378 fps
    DirectX 12 demo on X11, with the fix, 1422 fps
    After1,422 fps

    Old driver (r2), then the fixed driver, a minute apart.

1 / 5
For the curious: how it works under the hood

Bannerlator's normal display mode, X11, has a small built-in "X server" that puts windows on screen. Here are the four ways a frame can reach your screen:

Old · GLX copy roadX11, every Wine version, before this work
GameDraws with OpenGL
Zink + TurnipGPU paints the frame
WaitProcessor stops and waits for the GPU
Copy backFrame copied from GPU memory to the processor
Send as pictureHanded to the X server as a plain image
ScreenShown

The old OpenGL library (libGL.so.1.5.0, "XMesa") had to do this because the app's X server didn't understand GLX, the language OpenGL normally uses to talk to an X server. Three orange steps, every frame.

New · EGL roadX11, Wine 11 (arm64ec). Part of "Fast OpenGL" in 3.1.4.
GameDraws with OpenGL
Wine 11 EGL switchWine talks EGL instead of GLX
Our EGL libraryMesa EGL built for X11, ships in the app
Zink + TurnipGPU paints, Vulkan swapchain presents
ScreenShown

Wine 11 has a hidden switch (WINE_USE_EGL=1) to use EGL, a newer way to hook OpenGL to a window. EGL doesn't need anything from the X server, so the app's X server stays exactly as it was. Only Wine 11 has this switch, so Wine 9 and 10 couldn't use this road.

New · GLX roadX11, Wine 9, Wine 10, x86_64 and third-party layers. Device-tested on four layers. Released in 3.1.4.
GameDraws with OpenGL
Wine (any version)Talks GLX, like it always did
New GLX libraryMesa libGL.so.1 in "DRI" mode, ships in the app
Updated X serverNow answers GLX, DRI3 and Present 1.2
Zink + TurnipGPU paints, Vulkan swapchain presents
ScreenShown

Instead of teaching old Wine a new language, we taught the X server the old one. Wine keeps talking GLX, but now a modern OpenGL library answers, and the X server understands it. The copy-back steps are gone.

Wayland · EGL road, alwaysWayland, every Wine 11 layer
GameDraws with OpenGL
winewaylandWayland only speaks EGL
Layer's EGLMesa EGL built for Wayland, inside the Proton layer
Zink + TurnipGPU paints, Vulkan presents
Our compositorHands the frame to Android

Wayland never had the copy road, because Wayland has no GLX at all. That's why OpenGL was always much faster on Wayland. The X11 fix gave X11 the same road Wayland already had.

The new method for older Wine versions needed two pieces, and neither works alone:

PieceOldNewWhere it lives
OpenGL library (GLX)libGL.so.1.5.0, XMesa. Copies every frame.libGL.so.1, Mesa GLX in DRI mode, hands off to ZinkBuilt in Banners-Turnip, ships inside the app
EGL libraryWayland-only build, can't open X11 windowsMesa EGL built for X11 and WaylandSame build, ships inside the app
App's X serverNo GLX. DRI3 1.0, Present 1.0.Answers GLX (incl. modern contexts), DRI3 1.2, Present 1.2Bannerlator app. Switched on only for GLX-road sessions.
Fast OpenGL switchGreyed out unless Wine 11Works on any layer. Picks EGL or GLX by itself.Container and game settings, OpenGL card
Proton / Wine layersNo change. Nobody needs to rebuild or redownload a layer.—

One set of libraries serves both methods. On Wine 11: EGL 1596 fps, GLX 1649 fps, DirectDraw through EGL 1623 fps.

OpenGL test cube, Wine 11 and Wine 9.5GPU at full speed · 1 Oct, 09:00
Wine 9.5 x86-64: real programsGPU at full speed · 1 Oct, 09:10
Wine 11, the tests behind pre-release 2GPU held at 310 MHz, so lower numbers than the rest
Wayland, same programsSame 310 MHz GPU · vsync off
Question 9

Something not right?