Check out our Monthly Survey Page to see what our users are running.

OpenGL over Vulkan driver Zink gets a huge performance boost

By - | Views: 17,160

We heard you like performance and it seems the new OpenGL over Vulkan driver Zink is going to bring some FPS friends whenever the next release lands. Developer Mike Blumenkrantz who has been contracted by Valve has continued hacking away at the code, and in a new blog post detailed a massive change to the driver to improve gaming performance.

Don't know what Zink is? It's "an OpenGL implementation on top of Vulkan. Or to be a bit more specific, Zink is a Mesa Gallium driver that leverages the existing OpenGL implementation in Mesa to provide hardware accelerated OpenGL when only a Vulkan driver is available" - Collabora.

One of the improvements Blumenkrantz has mentioned in the past is getting Zink up to scratch for gaming, something that hasn't been the focus of blog posts lately. However, this latest one shows two screenshots and the difference between them with the old slow code left and new fast code right (click to enlarge):


Blumenkrantz is making use of MangoHud too, which recently added support for picking up Zink as the driver.

Going from 9FPS to 91FPS is a massive difference, as is the frametiming too so it's not just higher FPS it looks like it will be smoother overall too. How is it done? With the addition of a suballocator that was created by pinching some ready-made code from other parts of Mesa. The result is about 700 lines of code to create the performance booster. The gist of it is that Zink is now a lot smarter and knows when something is busy or can be used elsewhere so Zink can now really do its thing. The code is live in the "zink-wip" branch on GitLab if anyone wanted to be brave and try it out.

See the blog post for the full details.

Article taken from GamingOnLinux.com.
32 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
29 comments
Page: «3/3
  Go to:

BielFPs 18 Jun
Came here to see the comments and found a German class
crt0mega 18 Jun
Quoting: BielFPsCame here to see the comments and found a German class
Are you disappointed?
Lofty 18 Jun
Would this improve older earlier Linux ports that used openGL and had poor performance like DeusEX mankind divided?


excuse my ignorance on the matter, this is new to me.
CatKiller 18 Jun
Quoting: LoftyWould this improve older earlier Linux ports that used openGL and had poor performance like DeusEX mankind divided?


excuse my ignorance on the matter, this is new to me.
Not directly.

The OpenGL model is a single threaded state machine. At the time, for the uses it was created for, the hardware itself was a single threaded state machine. Fairly quickly, though, that stopped being the case - programmable shaders and multicore processors being the big deviations from that model, but others too. So OpenGL drivers lied through their teeth about what they were doing: they'd reorder instructions, and batch draw calls, and cache things or not cache things as they saw fit, for better performance; but as far as the application is concerned it was all "single threaded immediate rendering, honest guv," since that's what the spec calls for. Applications have no way of knowing WTF is actually going on.

Vulkan makes all this stuff explicit. The application has to handle the scheduling and the memory allocation and so on, and Vulkan provides the means to find out what the hardware can do and what it's actually doing. No more lies from the driver, but more work for the developer.

Automatically implementing OpenGL on Vulkan (which is what Zink does) means that the driver can provide consistent state-of-the-art lies to the application, but the application's still restricted to the OpenGL model, and was written in the context of the OpenGL driver lies of the time it was written. So Zink might make performance a bit better by providing better lies than average, but an OpenGL driver that provided the lies that the application writer was expecting and testing against would be just as good.
Lofty 18 Jun
Quoting: CatKiller
Quoting: LoftyWould this improve older earlier Linux ports that used openGL and had poor performance like DeusEX mankind divided?


excuse my ignorance on the matter, this is new to me.
Not directly.

The OpenGL model is a single threaded state machine. At the time, for the uses it was created for, the hardware itself was a single threaded state machine. Fairly quickly, though, that stopped being the case - programmable shaders and multicore processors being the big deviations from that model, but others too. So OpenGL drivers lied through their teeth about what they were doing: they'd reorder instructions, and batch draw calls, and cache things or not cache things as they saw fit, for better performance; but as far as the application is concerned it was all "single threaded immediate rendering, honest guv," since that's what the spec calls for. Applications have no way of knowing WTF is actually going on.

Vulkan makes all this stuff explicit. The application has to handle the scheduling and the memory allocation and so on, and Vulkan provides the means to find out what the hardware can do and what it's actually doing. No more lies from the driver, but more work for the developer.

Automatically implementing OpenGL on Vulkan (which is what Zink does) means that the driver can provide consistent state-of-the-art lies to the application, but the application's still restricted to the OpenGL model, and was written in the context of the OpenGL driver lies of the time it was written. So Zink might make performance a bit better by providing better lies than average, but an OpenGL driver that provided the lies that the application writer was expecting and testing against would be just as good.

Thank you for the explanation.

In the case of DeusEX i guess the point is probably moot as it should run on Proton and probably faster and smoother too. Then again i can't try this as i have the game but it's enormous & my internet is too slow to bother downloading it
BielFPs 18 Jun
Quoting: crt0megaAre you disappointed?
I'm überrascht
mirv 18 Jun
View PC info
  • Supporter Plus
Quoting: Lofty
Quoting: CatKiller
Quoting: LoftyWould this improve older earlier Linux ports that used openGL and had poor performance like DeusEX mankind divided?


excuse my ignorance on the matter, this is new to me.
Not directly.

The OpenGL model is a single threaded state machine. At the time, for the uses it was created for, the hardware itself was a single threaded state machine. Fairly quickly, though, that stopped being the case - programmable shaders and multicore processors being the big deviations from that model, but others too. So OpenGL drivers lied through their teeth about what they were doing: they'd reorder instructions, and batch draw calls, and cache things or not cache things as they saw fit, for better performance; but as far as the application is concerned it was all "single threaded immediate rendering, honest guv," since that's what the spec calls for. Applications have no way of knowing WTF is actually going on.

Vulkan makes all this stuff explicit. The application has to handle the scheduling and the memory allocation and so on, and Vulkan provides the means to find out what the hardware can do and what it's actually doing. No more lies from the driver, but more work for the developer.

Automatically implementing OpenGL on Vulkan (which is what Zink does) means that the driver can provide consistent state-of-the-art lies to the application, but the application's still restricted to the OpenGL model, and was written in the context of the OpenGL driver lies of the time it was written. So Zink might make performance a bit better by providing better lies than average, but an OpenGL driver that provided the lies that the application writer was expecting and testing against would be just as good.

Thank you for the explanation.

In the case of DeusEX i guess the point is probably moot as it should run on Proton and probably faster and smoother too. Then again i can't try this as i have the game but it's enormous & my internet is too slow to bother downloading it

I runs well enough (shader compilations notwithstanding) from GOG with wine+dxvk. I never could get the Windows version running through Steam, whichever base of wine I used. DRM was in the way I believe.

Native version I never could get to run either, but was a system library incompatibility. Possibly fixed by now, but the brute force needed to make it run ok through OpenGL isn't something my rig would enjoy anyway.

OpenGL was a great design feat, and lasted far longer than it really should have, but it's no longer applicable to modern hardware architectures. Some of the ideas developed along the way with OpenGL have carried on however, and Vulkan wouldn't be nearly as powerful without that foundation of experience that came from OpenGL's history.
TheRiddick 19 Jun
TR2013 native always gave me significant slowdowns in several areas in the game to the point of making it not enjoyable. Yes the benchmark doesn't show these slowdowns.
F.Ultra 19 Jun
Quoting: Purple Library Guy
Quoting: Eike
Quoting: tuubiLegacy baggage and technical debt are related (and depressing) terms that spring to mind.

I like "Legacy baggage"!
(I always take this with a bit of understanding/sympathy - it's not like I haven't produced similar baggages... ;) )
As a rule without the old stuff, the new stuff could never have come into being, so. And all new stuff will at some point become legacy baggage. If you're lucky. If you're not lucky it won't because it wasn't relevant enough to create a legacy . . .

Absolutely, or to quote the old TV series Crocodile Shoes: "Remember that Has-beens, Has Been".
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.

Livestreams & Videos
None currently, submit yours here!