Would it make sense to write an OpenGL driver on top of Vulkan?

[M1kkko]

Imagine an OpenGL implementation that works by making calls to Vulkan (at program run-time). This driver would implement the OpenGL "state machine" and GLSL to SPIR-V compiler etc. It would be platform agnostic and could potentially provide a uniform, high-quality implementation of OpenGL for all hardware that can support Vulkan. (And since an open-source Vulkan driver is easier to write than an OpenGL driver, it could also allow us to replace some proprietary drivers entirely on some platforms *cough* Nvidia *cough* Android)

My question is, are there any obvious downsides to this approach? Would implementing OpenGL on top of Vulkan have some noticeable performance overhead, compared to a traditional driver that implements OpenGL in a way that is "native" to a specific GPU architecture?

[haagch]

There has been a video of a (proprietary) OpenGL ES implementation on Vulkan a while ago:

https://www.youtube.com/watch?v=I64SCDfCjmo

[VikingGe]

There's been some talk about that and I'm pretty sure it is going to happen sooner or later.

The biggest pain would probably be to wrap OpenGL context creation (you'd have to provide an own GLX/WGL implementation as well), and the to wrap the OpenGL state machine on top of the new pipeline concept which consists of mostly immutable state objects. An OpenGL application can be in a virtually infinite number of disjoint states and still do the same thing - like, sometimes it doesn't even make a difference if the depth mask is enabled or not - and since changing global state is the easiest thing to do in OpenGL, applications tend to do it rather rapidly.