We are shipping an OpenGL driver with our Vulkan game. For legacy reasons, our plugin SDK requires an OpenGL contex that plugins can use for drawing. Sins of the pasts and what not. But the game itself has moved on and is now using Vulkan on Windows and Linux. At first we took advantage of the Vulkan/GL interop mechanisms exposed by the IHV drivers, which works by exporting memory from Vulkan and then importing it into GL. Unfortunately the interop path is pretty brittle, the IHVs don't care too much about it since it's rarely used and on AMD we have had huge issues with GPU barriers executing incorrectly, thrashing the result in the process and also just generally really bad performance.
So we took Zink, the Mesa OpenGL driver that emits Vulkan and slightly massaged it for our needs. I ended up having to implement a few missing GL extensions and also changing the Zink code a little bit so it would use our Vulkan device and instance instead of making its own. As far as plugins are concerned, there is still a real libGL.so/opengl32.dll just like there always was. But internally it's now emitting Vulkan calls against the device we use for our game. Solved both perf and interop issues and it's been one of my prouder achievements.
So we took Zink, the Mesa OpenGL driver that emits Vulkan and slightly massaged it for our needs. I ended up having to implement a few missing GL extensions and also changing the Zink code a little bit so it would use our Vulkan device and instance instead of making its own. As far as plugins are concerned, there is still a real libGL.so/opengl32.dll just like there always was. But internally it's now emitting Vulkan calls against the device we use for our game. Solved both perf and interop issues and it's been one of my prouder achievements.