Since Kopper got merged today upstream I wanted to write a little about it as I think the value it brings can be unclear for the uninitiated.
Adam Jackson in our graphics team has been working for the last Months together with other community members like Mike Blumenkrantz implementing Kopper. For those unaware Zink is an OpenGL implementation running on top of Vulkan and Kopper is the layer that allows you to translate OpenGL and GLX window handling to Vulkan WSI handling. This means that you can get full OpenGL support even if your GPU only has a Vulkan driver available and it also means you can for instance run GNOME on top of this stack thanks to the addition of Kopper to Zink.
During the lifecycle of the soon to be released Fedora Workstation 36 we expect to allow you to turn on the doing OpenGL using Kopper and Zink as an experimental feature once we update Fedora 36 to Mesa 22.1.
So you might ask why would I care about this as an end user? Well initially you probably will not care much, but over time it is likely that GPU makers will eventually stop developing native OpenGL drivers and just focus on their Vulkan drivers. At that point Zink and Kopper provides you with a backwards compatibility solution for your OpenGL applications. And for Linux distributions it will also at some point help reduce the amount of code we need to ship and maintain significantly as we can just rely on Zink and Kopper everywhere which of course reduces the workload for maintainers.
This is not going to be an overnight transition though, Zink and Kopper will need some time to stabilize and further improve performance. At the moment performance is generally a bit slower than the native drivers, but we have seen some examples of games which actually got better performance with specific driver combinations, but over time we expect to see the negative performance delta shrink. The delta is unlikely to ever fully go away due to the cost of translating between the two APIs, but on the other side we are going to be in a situation in a few years where all current/new applications use Vulkan natively (or through Proton) and thus the stuff that relies on OpenGL will be older software, so combined with faster GPUs you should still get more than good enough performance. And at that point Zink will be a lifesaver for your old OpenGL based applications and games.
You guys really need to work on your naming conventions. Names like “GL On Vulkan”, “GLVk” or so would tell clearly what the projects are about.
The former was already taken (as ‘GLOVE’), but there are also trademark issues associated with generic naming like you suggest.
I will continue using OpenGL as I do not intend to write 3000 lines of boilerplate to draw a triangle, thank you very much.
Look at the `vulkano` Rust crate; it reduces your boilerplate to almost nothing
WebGPU is an even easier to use wrapper on top of Vulkan (or Dx12/Metal/etc). Despite the name, it is a perfectly capable graphics API for native apps.
https://wgpu.rs/
wgpu != webgpu
WebGPU is a web standard for browsers. wgpu is a rust implementation of this webstandard for desktop
Rust’s ecosystem often reminds me of the NPM clutter of 200 microdependencies hosted by random personal github repositories with communities centered around proprietary “gamer” chat applications, so I’d rather not dabble in this, even if I know that I’ll likely end up having to use Rust at some point in my life eventually. Checking Vulkano’s dependencies and their dependencies, it doesn’t look too bad there though, so at least there’s that. (lol at the rand crate still not being part of the standard library though, also lol at this requiring pseudo random number generation somehow?)
OpenGL’s core profile as well as OpenGL ES are perfectly fine and remain perfectly fine for a vast number of new applications, which often do not have a bottleneck within the graphics driver, so would get minimal benefit from Vulkan. Zink reaching performance parity with a gallium implementation of OpenGL is in my eyes essential before anyone embarks on their GNOMEian endeavor of removing working code (e.g. throwing out radeonsi for no good reason).
Having to bring my own shader compiler (at least from GLSL to SPIR-V) is another unpleasant side effect I’d rather avoid, especially since apparently glslang still hasn’t figured out this whole “don’t use locale dependent functions for string processing” concept last I heard.
No disrespect to Zink’s authors, I think it’s a great piece of software and cool solution going forward because it will definitely be crucial to OpenGL’s future, I just don’t like the portrayal of OpenGL as this legacy thing to be left behind. It’s the only reasonably cross-platform high level graphics API we’ve ever had, with a diverse set of implementations that all had their own bugs, and now we’re moving away from OpenGL implementations to different Vulkan wrappers which all have their own APIs (and, once again, their own bugs).
‘Zink reaching performance parity with a gallium implementation of OpenGL is in my eyes essential …’
Well, good news. For the usecases you’ve stated you care about (where the driver isn’t even close to the bottleneck), then you’re already there. For high-performance usecases where the driver bottlenecks, they mostly already ported to Vulkan to avoid the bottlenecks. For high-performance usecases who haven’t ported to Vulkan, Zink is closer than you think and even sometimes – as the post says – faster. Mike Blumenkrantz’s development blog at https://www.supergoodcode.com/ has a lot of details which might interest you.
‘before anyone embarks on their GNOMEian endeavor of removing working code (e.g. throwing out radeonsi for no good reason)’
No-one has ever mentioned deleting radeonsi.
Zink and Kopper need to be pushed for the OpenGL 4.7 Khronos Group specification so that every OS can benefit here. Making a compatibility layer to run it all on Vulkan is nice, but making it standard is another.