Support us on Patreon
PayPalWe 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.
Quoting: LoftyWould this improve older earlier Linux ports that used openGL and had poor performance like DeusEX mankind divided?Not directly.
excuse my ignorance on the matter, this is new to me.
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.
Quoting: CatKillerQuoting: LoftyWould this improve older earlier Linux ports that used openGL and had poor performance like DeusEX mankind divided?Not directly.
excuse my ignorance on the matter, this is new to me.
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
TheRiddick Jun 19, 2021
Quoting: Purple Library GuyQuoting: EikeAs 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 . . .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... ;) )
Absolutely, or to quote the old TV series Crocodile Shoes: "Remember that Has-beens, Has Been".
See more from me