Introducing Zink: OpenGL on Vulkan
kusma.xyz
kusma.xyz
I do feel like there ought to be something for a higher level API that is not a full game engine, is not laden with the historical missteps and anachronisms of OpenGL, and doesn't require the masochism and verbosity of Vulkan. I rather liked DirectX 9, especially with all the built-in convenience utilities in D3DX that were later dropped.
... did you use Metal ? Metal shaders are written in ≈C++14. Says so right here in the first example: https://developer.apple.com/documentation/metal/hello_triang...
When I talk about "good APIs", I'm mostly talking about the driver and CPU side of things, since that's the common bottleneck we're looking to replace with an OpenGL replacement. GPU compiler is already pretty highly optimized.
Metal Shaders are written in C++14 with a couple of language extensions.
History proves that alternatives to official APIs always follow the CoffeeScript path, the only difference is how fast they eventually die after the initial hype.
(Let's not even go into the various experimental frontends that target SPIR-V directly. Those likely aren't going anywhere, like most experimental languages.)
Here's the key difference: Vulkan doesn't specify a high-level shader language at all, even though Khronos obviously has a GLSL bias. It specifies SPIR-V, which means that WebAssembly is a better analogy in CPU space than JavaScript/CoffeeScript.
Google naturally has a vested interest in making Vulkan being adopted on Android, since it drives sales, as its proper support requires recent flaghship models.
By not being part of Vulkan standard and certification tests, basically if a driver does not handle the SPIR-V as generated by HLSL compiler, good luck with the vendor's support channels.
Also, the Vulkan Conformance Test Suite is open source.[0] Contributions of better SPIR-V tests would certainly be accepted, so Google (or anybody else, really) has an easy path towards forcing better support in drivers if they care sufficiently.
To me, OpenGL and Vulkan bear sort of the same relationship to one another that Xlib and XCB do: one is (relatively) easy to program for and lets you get good results right away. The other is much trickier to program for, but gives you much finer grained control over how the underlying layer is actually used, allowing you to get much more performance out of it. So there's room for both. And while basing OpenGL on an underlying Vulkan implementation is certainly feasible and may be logical -- as the Zink authors said, any optimization they can do can also be done by driver authors and then some, and there's still enough OpenGL stuff out there to where driver authors are going to want to make those optimizations.
I'm guessing that as more and more high-performance applications (i.e. games) migrate to the low-level APIs, other vendors will start to adopt Apple's neglect of OpenGL drivers...
Sometimes it's not a matter of what can be done rather who can actually do it so it does get done and these lower level APIs allow the general public to get it done instead of hoping vendors do.
I guess it's probably good for legacy stuff though!
Many think that OpenGL with core context is already too low level.
Which the answer is in both cases to have some kind of middleware.
I always considered a mistake that OpenInventor was never part of the standardization deal, because everyone ends up writing their own version of scene graph APIs.