But at some point in the not too far future, we'll probably get there.

We're not there yet, though not all hardware has a Vulkan-driver, and some older hardware can't even support it. So my hope is that we can simplify things here, by only require things like desktop compositors to support one API down the road. It's not looking like neither OpenGL nor Vulkan is going away, and the software-world is now hard at work implementing Vulkan support everywhere, which is great. OpenGL is well-established as a requirement for applications and desktop compositors.īut since the very successful release of Vulkan, we now have two main-stream APIs for essentially the same hardware functionality. One problem is that OpenGL is a big API with a lot of legacy stuff that has accumulated since its initial release in 1992. At least as long as you don't count solutions who only implement some variation of OpenGL ES (which in my opinion doesn't solve the problem we need full OpenGL for this to be really valuable). I was waiting for someone else to do it before me, but nobody seemed to actually go ahead. I'll go through each of these points in more detail below.īut there's another, less concrete reason someone had to do this. Lessen the work-load for future GPU drivers.There's several motivation behind this project, but let's list a few: Here's an overview of how this fits into the Mesa architecture, for those unfamiliar with it:

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.

Zink is an OpenGL implementation on top of Vulkan. For the last month or so, I've been playing with a new project during my work at Collabora, and as I've already briefly talked about at XDC 2018, it's about time to talk about it to a wider audience.

Angle opengl es 2.0 download