Slashdot Mirror
Vulkan Graphics is Coming To macOS and iOS, Will Enable Faster Games and Apps (anandtech.com)
The Khronos Group, a consortium of hardware and software companies, has announced that the Vulkan graphics technology is coming to Apple's platforms, allowing games and apps to run at faster performance levels on Macs and iOS devices. From a report: In collaboration with Valve, LunarG, and The Brenwill Workshop, this free open-source collection includes the full 1.0 release of the previously-commercial MoltenVK, a library for translating Vulkan API calls to Apple's Metal 1 and 2 calls, as well LunarG's new Vulkan SDK for macOS. Funding the costs of open-sourcing, Valve has been utilizing these tools on their applications, noting performance gains over native OpenGL drivers with Vulkan DOTA 2 on macOS as a production-load example. Altogether, this forms the next step in Khronos' Vulkan Portability Initiative, which was first announced at GDC 2017 as their "3D Portability Initiative," and later refined as the "Vulkan Portability Initiative" last summer. Spurred by industry demand, Khronos is striving for a cross-platform API portability solution, where an appropriate subset of Vulkan can act as a 'meta-API'-esque layer to map to DirectX 12 and Metal; the holy grail being that developers can craft a single Vulkan portable application or engine that can be seamlessly deployed across Vulkan, DX12, and Metal supporting platforms.
More like its an better cross-platform open alternative to OpenGL or DirectX. Sort of a next-gen OpenGL.
Basically, Vulcan is a better and more modern alternative to DirectX than OpenGL with many of the benefits of OpenGL such as cross-platform, portable, open, etc. but easier to use than OpenGL, and better performance as good or better than DirectX.
-- Given enough time and money, Microsoft will eventualy invent UNIX.
"Metal" was the new standard that Apple was trying to push, "Vulkan" is the actual standard that got adopted by other people.
This means that people no longer need to go through the pointless process of converting their Vulkan code into Metal.
Among other things, 1) it plays nicely with machine CPU threads, 2) it supports a standardized binary intermediate language for GPU-run code, freeing you from constraints of having to use any particular language, 3) it supports both graphical AND computational tasks running such code within a single API.
Ezekiel 23:20
My recollection was they got so fed up waiting for the Khronos Group to start real discussions about "OpenGL-next gen" they just got on with it, then Vulkan turned up. The article (and a lot of people on the internet, shocking that) in part try's to re-write history so it appears Apple ignored a standard (and a complete one at that...) because there evil and not playing nice (Umm OpenCL...CUDA...anyone) but at the time it didn't exist so what were they to do?
It will be interesting to see what Apple does next.
...easier to use than OpenGL...
I only want to clarify one thing: Vulkan is not easier ot use than OpenGL.
In fact Vulkan is much much more difficult and requires much much more setup. Vulkan is capable of being faster than OpenGL because Vulkan enables multi-threading the rendering commands rather than computing all the rendering commands in a single thread as OpenGL does it.
The reason Vulkan is more difficult to use compared to OpenGL is precisely because setting up a multi-threaded renderer is much more tricky to get right and requires way more in the way of boilerplate and you-just-have-to-already-know-what-you're-doing scaffolding in order to get places. Vulkan is much lower-level than OpenGL.
This post helps explain.
That's not exactly what they were designed to do. Most of the data structures and semantics between metal and vulkan are the same or very similar, no extra state will need to be kept, and none of the heavy weight render state changes that made OpenGL and earlier DirectX's a dog will be in the way.
Of course, Apple could kill this if they release metal bindings for C/C++, rather than locking it all in to Swift.
But comparing Vulkan to OpenGL may be a little bit like comparing Xlib+X Toolkit Intrinsics against XCB. You get less stuff done for you but at least you can *finally* implement it correctly.
Ezekiel 23:20
Thanks! I looked at their website and noticed that the "supported engines" list included CryEngines, UX3D, Unity, Unreal, and Source. Does this mean these engines already use Vulkan instead of OpenGL, or that they can be configured to do so by the developer?
Configured to do so, game engines generally try to abstract away the underlying graphics system for game developers. In fact you might say the rise of a few dominant game engines is the main reason why we now make drivers with low-level access. To attempt to very briefly recap history:
1. All graphics card did their own thing
2. Some standards emerged, primarily OpenGL and DirectX.
3. Game developers built directly on OpenGL/DirectX
4. OpenGL had an early lead but Microsoft made DirectX dominant
5. Game engines increase in complexity, do much more than graphics
6. Most game developers develop on top of a game engine
7. Game engine developers want more direct access to hardware
8. DirectX12/Vulkan/Metal (and also Mantle, now dead) offer lower level access
You could say the market flipped, through most of the 90s and 00s game developers definitively wanted the OS to do more so they could do less and develop games faster. But as the market matured they didn't want just a graphics stack, they wanted a whole game engine they could fill with content. And the abstractions the OS makers had made became more of a hindrance than an aid to game engine developers, they wanted to do their own low level code and create abstractions that integrated better with their engine.
Another way of putting is also that on the CPU side you have assembler. Granted there's a few flavors like x86, ARM and PowerPC but they all have very basic operations like 2+2. Graphics never had a really low level language like that, they implemented higher level constructs all their own way. Much of that is because a lot of early graphics card was fixed function, it's only in modern times they have become programmable mini-processors. And this is kinda their assembler-level language.
Live today, because you never know what tomorrow brings
Vulkan is easier to use properly than OpenGL. OpenGL is designed around an architecture that no longer exists - no graphics chip made in the past two decades was strictly fixed-function. And because *every* modern graphics feature is an optional extension to OpenGL, every OpenGL program that wants to take advantage of, say, programmable shaders or compressed textures, has to spend a few hundred lines of code telling the drivers and runtime that yes, it knows what a fucking shader is and can you please let me use them now? Compare modern OpenGL to Direct3D 11 - features nobody actually uses (like fixed-function lighting) are removed, features everyone has (like shaders) are built-in, and while a basic demo *is* a few hundred lines of C, it's much more grokkable. And D3D11 has options for compatibility down to D3D9FL1 (GeForce 5000, GMA 900, Radeon 9000 series) hardware - you can code to D3D11 and still run on older hardware if you limit yourself to certain features or make the right fallback options.
OpenGL is easier to use for basic demos but is harder to use in practice. In particular, optimizing OpenGL is sheer madness, because everything is abstracted. You're basically just rearranging stuff to figure out how to make the drivers generate the right code. Whereas on Vulkan you actually interact with the API in the same way the hardware works - you ask a special malloc() for memory on the GPU, put some data in it, then tell your vertex shader how to interpret that data as triangles, then tell your pixel shader how to turn those triangles into pixels. It only looks like more code if you were relying on OpenGL defaults instead of explicitly coding what you're doing. Since very few apps do Gouraud-shaded, fixed-light, untextured rendering anymore except for graphics API tutorials, any practical program in Vulkan will be easier to write than the equivalent OpenGL program.
What Vulkan does is make trivial stuff harder, but hard stuff easier. You can write a multi-threaded OpenGL renderer, I believe, though I've never been masochistic enough to try. It's easier on Vulkan - still not trivial, but what multithreaded code is?
There is a famous XKCD cartoon that describes very well the need for new standards.
MoltenVK isn't a new standard, it is a mechanism for bringing the only cross-platform, open spec low level graphics API to the Mac. Nor are these APIs competing, if you use Vulkan on the Mac (via MoltenVK) you're using Metal underneath, it just means you don't have to rewrite your renderer in Metal just to be able to run it on Apple platforms.