Hopefully if so, without any of the old legacy crap, if it is intended to be actually used to write new code. If it is just a shim to let old OpenGL code run on Vulkan drivers, which appears to be more the point, then I expect that is unavoidable, as long as we do want to be able to keep running older software down the line.
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.
Metal is very close to that "perfect layer" in my opinion. I would love to see a portable Metal built on top of Vulkan, rather than the MoltenVK we're getting (an insane idea, in my opinion). Perhaps the Dash/NXT thing that Google is building would be an OK substitute?
The purpose of Metal is the lock-in by the vendor of the OS. We may start thinking about other things after we properly overcome this by having Vulkan or GL over it.
? There's no C++ in Metal, it's Objective-C. You can build C or C++ bindings for Metal if you want ( as has been done by https://github.com/recp/cmt ), the binding language is not really a concern.
Oh, sure, the shader language. That part doesn't really matter to me, it all gets compiled to some GPU-specific machine code in the end. Write it in GLSL, HLSL, SPIR-V, C++, who cares really. And shader cross-compilers are already incredibly common in the industry (most write in HLSL, then translate with HLSLParser, or glsl-optimizer, or spirv-cross, etc.).
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.
Shaders are part of the API, they define what the GPU is supposed to do with a bunch of points and textures.
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.
Considering that there are already multiple frontend languages for Vulkan shaders - both GLSL and HLSL are supported, and not via cross-compilation - you're quite likely to be proven wrong.
(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.
HLSL support is a kind of Google driven effort without being part of official Vulkan specification, due to many devs stating them they wouldn't care about Vulkan without such support, given their amount of DirectX shaders.
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.
It's clear that vendors do have a serious interest in supporting SPIR-V as specified, not just SPIR-V as produced by glslang. I can assure you that I have reliable sources for that, though obviously it's up to you whether you want to believe a random internet person.
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.
Or not, in the case of some vendors. MoltenGL claims their OpenGL-on-Metal implementation is faster than Apple's official OpenGL drivers.
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...
OpenGL has some really non-perf friendly design choices. You could optimize the driver. You could also just not support the edge cases that are needed for 100% spec compliance but not needed for 99% of apps and then either print a warning or let the user compile in the slow code that covers those edge cases.
There is a reason most browsers on Windows run WebGL through OpenGL and it's not because the driver support has been amazing. Same with MacOS which has deprecated OpenGL in favor of Metal.
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.
Did you mean to write "not" though OpenGL? Most WebGL on Windows run through DirectX via OpenGL emulation using the ANGLE Project. Both Chrome and Firefox do this and I'm 99% sure Edge doesn't use OpenGL either so not sure why you thought browsers were using OpenGL on Windows.
Isn't it solving a different problem? My understanding of gfx-rs is that it implements vulkan on top of X, where X is direct3d, metal, opengl, or vulkan. (It also implements a high-level graphics api in rust, but exposes a vulkan implementation to c programs.)
Not everyone is willing to jump into low level 3D APIs, the traditional CAD/CAM vendors for example.
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.
Farenheit, Inventor, VRML, every so often one comes out with "the scene graph to rule them all". Turns out writing a high-performance renderer (and you do want that) is quite challenging. There are so many different rendering techniques and the scene graph is really not the hard part...
I do agree, the thing is 90% of the API users just want to render a mesh of some sort and not write a high performance render engine able to sustain 90 FPS under all conditions.
