Remember Zink? The project announced in October last year from developer Erik Faye-Lund at Collabora, which provides a Mesa Gallium driver for getting OpenGL on top of Vulkan, well it's still going.
After not hearing much about it, Faye-Lund has posted a Summer Update on the Collabora blog about all the work that's gone into it. However, it's had a bit of a setback as it's been through a "pretty significant rewrite". Some design mistakes were made, so they went back and attempted to improve it. For now, it's only getting OpenGL 2.1 support with cleaning everything up and getting the code up-streamed taking precedence over OpenGL 3.0 support.
The good news is apart from that, it sounds like a lot of progress was made on it including proper control-flow, the compiler has been ported to C, the compiler no longer lowers IO, but instead process derefs directly, the compiler now handles booleans properly, occlusion queries has been implemented correctly across command buffers, support for 8-bit primitive indices has been implemented and so on. They also showed off a picture of Blender running using Zink which is a healthy milestone.
They're also going to be giving a talk at SIGGRAPH 2019, as Khronos has given them a slot in their Vulkan sessions, so that could be an interesting one to watch.
Hat tip to Mark.
But... why?
Because it can serve as OpenGL fallback for new and less supported targets. Implementing Vulkan driver for something is a lot easier than implementing OpenGL one.
I.e. imagine some new platform comes out (like Librem5 or something) using a GPU that doesn't have Mesa support yet. Someone works on Vulkan driver for it. Having such OpenGL on top out of the box is a major bonus, until someone will be able to implement the native one.
Last edited by Shmerl on 26 July 2019 at 7:26 pm UTC
But... why?
Am guessing to improve dx 9 performance on intel graphics and older amd cards
But... why?
It is funny, but I was thinking the exact same thing as I was reading. The first link to the project page provides good answers to that question. The best one is basically the same reason to continue supporting 32-bit libraries; to allow for legacy programs written in OpenGL to still function in future hardware which may only have a Vulkan driver.
*Intermediate representation is a way of reducing combinations. Every piece of hardware is different and there are many graphical APIs. Trying to implement each on each would take a lot of effore and therefore Mesa developers have used an intermediate preresentation to reduce the problem's complexity from n*m to n+m.
The why is explained in the October post: https://www.collabora.com/news-and-blog/blog/2018/10/31/introducing-zink-opengl-implementation-vulkan/Thanks! Interesting read.
See more from me