Vulkan Graphics is Coming To macOS and iOS, Will Enable Faster Games and Apps (anandtech.com) 94
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.
Thy could call it Adobe Air (Score:1)
Oh joy another layer that runs everywhere. Now only 13 standards to unify. Perhaps adobe AIr can incorporate this.
Re: (Score:1)
Oh joy another layer that runs everywhere. Now only 13 standards to unify. Perhaps adobe AIr can incorporate this.
That's what I was thinking.
While the CONCEPT of "One API to Rule Them All" is always tempting, weren't DirectX, Metal, etc. created SPECIFICALLY to REDUCE the number of "Layers" between well, the Software and the "Metal"?
Re: (Score:3)
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.
Re: (Score:2)
I'll stick to OpenGL.
Then you'll be limited to version 3 on Apple platforms. Sorry.
Re: Thy could call it Adobe Air (Score:2)
Re: (Score:2)
That's what I was thinking.
While the CONCEPT of "One API to Rule Them All" is always tempting, weren't DirectX, Metal, etc. created SPECIFICALLY to REDUCE the number of "Layers" between well, the Software and the "Metal"?
DirectX12 (the Direct3D bit), Metal and Vulkan were designed to expose more of the driver details to the developer so we could get away from these monolithic drivers that contained application-specific code in them. It also offered a clean break from many of the legacy baggage carried through from older versions of APIs. The problem is that Metal and Direct3D are closed source and proprietary so in order to do cross platform applications you generally need a rendering backend layer that sits between your AP
Re: (Score:2)
That's what I was thinking.
While the CONCEPT of "One API to Rule Them All" is always tempting, weren't DirectX, Metal, etc. created SPECIFICALLY to REDUCE the number of "Layers" between well, the Software and the "Metal"?
DirectX12 (the Direct3D bit), Metal and Vulkan were designed to expose more of the driver details to the developer so we could get away from these monolithic drivers that contained application-specific code in them. It also offered a clean break from many of the legacy baggage carried through from older versions of APIs. The problem is that Metal and Direct3D are closed source and proprietary so in order to do cross platform applications you generally need a rendering backend layer that sits between your API-agnostic engine/application and the graphics API that the driver exposes.
With Vulkan drivers (and therefore API) available on Windows, Linux and Android that makes application portability much simpler and more efficient. The implementation of Vulkan (MoltenVK) sits atop the Metal driver and the concepts don't map exactly so Vulkan on Apple isn't going to perform as well or be as flexible as Vulkan on other platforms.
You sound just like the HiTech Complier people, who argued that C Compilers and microcontrollers in general had gotten to the point where even in time and performance-sensitive portions of real-time embedded code, there was absolutely no need for Assembly Language coding.
Anyone who has been an embedded dev. for more than a few years knows how laughable that is, given thei right circumstances.
My point is, Just like tightly-hand-coded Assembly Language is likely to beat even the best Compiled code, as far as
Re: (Score:2)
You sound just like the HiTech Complier people, who argued that C Compilers and microcontrollers in general had gotten to the point where even in time and performance-sensitive portions of real-time embedded code, there was absolutely no need for Assembly Language coding.
Then you missed the point, in fact I wasn't arguing anything at all. But if anything my advocacy is for lower level APIs being available rather than that functionality being hidden in the driver.
My point is, Just like tightly-hand-coded Assembly Language is likely to beat even the best Compiled code, as far as raw performance goes, it is also true that you will NEVER increase performance by adding interposing "translation" API layers to time-sensitive code.
Then you misunderstand the point of MoltenVK completely, it isn't about improving performance over Metal, it is about enabling portability in a more performant way than OpenGL. Vulkan on top of Metal has lower overhead than OpenGL (and Apple didn't manage to support OpenGL very well even before Metal anyway) because
Re: (Score:2)
You sound just like the HiTech Complier people, who argued that C Compilers and microcontrollers in general had gotten to the point where even in time and performance-sensitive portions of real-time embedded code, there was absolutely no need for Assembly Language coding.
Then you missed the point, in fact I wasn't arguing anything at all. But if anything my advocacy is for lower level APIs being available rather than that functionality being hidden in the driver.
My point is, Just like tightly-hand-coded Assembly Language is likely to beat even the best Compiled code, as far as raw performance goes, it is also true that you will NEVER increase performance by adding interposing "translation" API layers to time-sensitive code.
Then you misunderstand the point of MoltenVK completely, it isn't about improving performance over Metal, it is about enabling portability in a more performant way than OpenGL. Vulkan on top of Metal has lower overhead than OpenGL (and Apple didn't manage to support OpenGL very well even before Metal anyway) because many of the concepts do map between them (lots of discussions on this around webgpu as this needs to be an abstraction for all the low level APIs).
Well, in that case, I agree completely.
BTW, your arguments are entirely too rational. Are you new here? ;-)
Re: Thy could call it Adobe Air (Score:1)
Can someone explain Vulkan? (Score:2)
Is it an API akin to CryEngine/Unreal/Unity? If so, why is it better than the ones we already have? Google provided a lot of information, but I'd like a Cliff's Notes.
Re:Can someone explain Vulkan? (Score:5, Informative)
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.
Re: (Score:2)
Thanks! I looked at their website [khronos.org] 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?
Re: (Score:3)
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
Re: (Score:2)
Vulcan is [...] easier to use than OpenGL
Can you expand on that? My impression was that it is considerably harder to use correctly than OpenGL.
From wikipedia article (emphasis mine),
"NVIDIA notes that OpenGL is still a great option for a lot of use cases, as it does come at a much lower complexity and maintenance burden than Vulkan"
Re: (Score:2)
Vulkan is good if you're writing an engine. And most apps are using an engine rather than doing all the low level details themselves. This makes sense because at some layer what you really want is game logic that plugs into a scene graph, not game logic jumping directly to rendering.
What news about Vulkan really translates to is that Unity, Unreal Engine, etc are going to be faster on platforms that support Vulkan. Games that use these frameworks benefit. The developers who roll their own engine probably wo
Re:Can someone explain Vulkan? (Score:4, Insightful)
...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 [khronos.org].
Re:Can someone explain Vulkan? (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
A great analogy. For the 20 or so people on /. that program xlib, Xt, and XCB. (I think Xt is throughly dead, and I should probably send my book collection to recycle)
Re: (Score:2)
Re: (Score:2)
Motif is alive and kicking, especially in commercial engineering software. Ever used ANSYS?
Re:Can someone explain Vulkan? (Score:5, Informative)
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?
Re: (Score:1)
Multithreading is hard to implement, but you don't need to use multi-threading to get better performance. Draw calls have much lower overhead and then validation is done in a layer that is swiched off in release. That alone will get better performance. There are a lot of hidden work getting OpenGL to get performance. For instance, batching - I spent so much development time on this it's unreal. Those problems disappear in Vulkan, because of the low overhead.
Re: (Score:2)
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.
It's certainly not easier to use than OpenGL, with Vulkan you must do a LOT of the things yourself that OpenGL does for you. Just writing a simple 'hello triangle' example in Vulkan is massively more complex than OpenGL: think of the OpenGL versions as a simple C hello world, you end up using a printf to write to the screen but behind the scenes that printf does a massive amount of stuff. Writing a Vulkan version is like having to write all that stuff that printf does.
Re:Can someone explain Vulkan? (Score:4, Informative)
Re: (Score:1)
Is it an API akin to CryEngine/Unreal/Unity? If so, why is it better than the ones we already have? Google provided a lot of information, but I'd like a Cliff's Notes.
Oh, GOOGLE. Nevermind.
It won't be around long enough to get out of Beta.
Re: (Score:2)
Re: (Score:2)
Vulkan, DirectX 12 and Metal are low-level APIs compared to OpenGL or DirectX 11. They remove aspects of hardware abstraction, exposing more of the structure of the hardware, allowing the resources to be used more efficiently.
The downside is that they are harder to write software for. Most games are running on top of a ready-made game engine anyway and that could have been targeted to the low-level API.
Vulkan is the successor to AMD's proprietary Mantle [wikipedia.org] API which is now deprecated in favour of Vulkan. That
Re: Can someone explain Vulkan? (Score:2)
CryEngine/Unreal/Unity?
Dude, those aren't API's; those are game engines/development kits.
Re: (Score:2)
no, it is low level
vulkan, metal and direct3d12 are almost the same in the way they work, this mostly maps the differences between then (translate vulkan calls to other calls) , so you can build in vulkan and run vulkan, metal and direct3d12 (probably mostly for xbox, as you can run vulkan directly in windows)
IF only they had better hardware (Score:2)
The imac pro is ok but to much workstation and at a price where it smoked by gaming pc's at more then half the price.
Mac pro old and high priced with video cards that are limited by small cooling.
Mini old hardware and capped at duel core
imac $1,299.00 for a system with an 5400RPM HDD and an low end video card.
Re: (Score:2)
If you are a games vendor, you don't ask, "How many people will buy a Mac to play my game?"
You ask, "How many people with a Mac will buy my game?"
Re: (Score:2)
Exactly, thus my comment. The game companies don't care why you bought a Mac, just that people with Macs buy their games. I have no idea what the Venn diagram looks like for "people who buy Macs" and "people who will buy Vulkan-enabled games", but clearly someone thinks it's a good business move. Mac owners in general are more willing to buy software, so there's that.
Re: (Score:2)
Exactly, thus my comment. The game companies don't care why you bought a Mac, just that people with Macs buy their games. I have no idea what the Venn diagram looks like for "people who buy Macs" and "people who will buy Vulkan-enabled games", but clearly someone thinks it's a good business move. Mac owners in general are more willing to buy software, so there's that.
I think the bigger draw is not OSX compatibility per-say; OSX compatibility is all but a happy accident. Right now, desktop gaming is largely the realm of DirectX. You've got a few early adopters and a few more OpenGL-based games, but a whole lot is tied to a proprietary MS technology. This is helpful if you're designing a AAA game intended to be compiled for the Xbox as well, but with all the stuff Microsoft is doing with Windows 10, there's some genuine FUD going on. There is a very-rational concern that
Re: (Score:1)
I'm not convinced,
Sure you save 200-300 on the system maybe, but depending on how many games you buy, there's a chance for saving on the PC vs the Console overall.
What about the iMac 5k (Score:2)
at a price where it smoked by gaming pc's at more then half the price.
First of all, that is simply not true [pcgamer.com], building your own system saves a few hundred $.
But secondly - what about the iMac 5k? That is a pretty modern system, the CPU specs are almost as good, it just has a lower end video card. But you could also attach an eGPU via the Thunderbolt 3 ports, and it starts at $1799.00.
The cooling is not as good in the iMac 5k but if you are leaning on an eGPU card that doesn't matter as much as the GPU can
good deal for a workstation system (Score:2)
good deal for a workstation system and why buy apple keyboard and mouse for a PC?
egpu $250-$300+ for the case for pci-e X4 (Score:2)
egpu $250-$300+ for the case for pci-e X4
Yes, but still cheaper than iMac pro and custom (Score:2)
egpu $250-$300+ for the case for pci-e X4M
Yes but the iMac 5k + eGPU case plus a REALLY good video card will still be less than the iMac pro, and now you have a system optimized for gaming more than the iMac Pro is - the iMac pro is more about having a lot of cores, as noted it's more of a workstation than specifically made for gaming.
I'm just saying there are other ways to arrive at a good gaming Mac that do no cost as much as an iMac Pro, which was brought up as the only example.
Re: (Score:2)
war thunder run in the pst with opengl in mac and the performance was bad... they reported that the opengl in mac was somewhat lacking features and performance optimizations, (because apple didn't care) so it was hard to fix
they then ported the game to metal and performance increased a lot, specially in lower end machines... and this was not a full port, is just changing some parts to use metal, to solve the performance problems.
So yes, this is something users want. The major pain is that apple didn't suppo
Re: (Score:2)
The Vulkan platform is decent, but it isn't the card gamers want, nor is it particularly well made for it. I doubt Vulkan alone will win gamers over to the Mac. It seems like a classic chicken egg situation. Games will likely run better on the Mac than they did before, but unless the developers see demand from Mac users they simply wont take the time to port anything meaningful.
That's part of why Vulkan is important, previously porting to the Mac would require re-writing the rendering engine in Metal (or going back to OpenGL 4.1 with Apple's poor OpenGL support) whereas now you can run your Vulkan renderer on OSX/iOS.
Another new standard (Score:1)
There is a famous XKCD cartoon that describes very well the need for new standards.
https://xkcd.com/927 [xkcd.com]
Re: (Score:2, Informative)
There's absolutely nothing new about Vulkan though.
Re:Another new standard (Score:4, Insightful)
"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.
Re: (Score:2)
Re: (Score:2, Interesting)
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 ne
Re: (Score:2)
The actual history had a number of people also writing their own API because Khronos was too slow. ATI had mantle, NVidia had CUDA (which is perhaps similar but not exactly the same), and even MS was pushing some DirectX changes all with the same concept. It's not a surprise Apple made Metal at all, OpenGL was not keeping up with games or low power designs.
But they got a kick in the pants, and Vulkan got fast(er) tracked. Now it seems like those other APIs are redundant, I'm not sure yet if that's true, but
Re: (Score:2)
But they got a kick in the pants, and Vulkan got fast(er) tracked. Now it seems like those other APIs are redundant
Vulkan is basically Mantle. When it got standardised, work on mantle stopped.
Re: (Score:2)
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.
But they kept it closed and proprietary rather than just releasing it as open so others could implement it on other platforms.
Re: (Score:2)
Did Apple ever try to portray metal as a standard? My recollection is they just created the API for iOS and eventually ported it to OSX, not that they tried to get anyone else interested.
Exactly.
I never have heard anyone discuss Metal as an industry-standard.
Re: Another new standard (Score:2)
Did Apple ever try to portray metal as a standard?
LOL, as a standard for what? Apples?? That would be a contradiction, unless "proprietary standard" means anything (it doesn't).
Re: Another new standard (Score:2)
"Metal" was the new standard that Apple was trying to push, "Vulkan" is the actual standard that got adopted by other people.
When has Apple "pushed" Metal as a standard? In June 2014, Apple released beta versions as a low level graphics API to their iOS devices. Later macOS was added. It was never released as a standard for any other system.
This means that people no longer need to go through the pointless process of converting their Vulkan code into Metal.
"No longer" isn't quite accurate because just because a system supports more than one standard does not mean that all work stops on one of the standards. For example, game developers didn't stop coding Direct X because the game also supported OpenGL. Indeed, it means that developers may have t
Re: (Score:2)
Now they can just write in Vulkan and it is supported everywhere rather than having to write a special version just for Apple. If you're only targeting Apple then sure, write in Metal but if not then write in Vulkan.
The problem is that Vulkan, for now, isn't supported by Apple. So the Khronos Group is fully responsible for it working on all versions of iPhone for all versions of iOS. Then there are optimization issues which might occur on iOS as it might "run" but not be great which is not something you want in a graphics API. While you can write in Vulkan it may or may not work well on an iOS device especially in the beginning which you will probably need to keep a Metal version for a while. Also bear in mind that App
Re: (Score:3)
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.
Re: (Score:1)
If I may quote your own words:
> cross-platform, open spec low level graphics API to the Mac
A "low level graphics API" sounds suspiciously like a standard to me. Doesn't it sound like a standard to you?
> Nor are these APIs competing,
I'm very confused how you might think such a thing. As I understand it, "Vulkan" is competing with "Metal", the Apple published, closed source API. Both compete for market share and developer time with DirectX on Windows based machines. Even if you consider Vulkan to be the
Re: (Score:2)
If I may quote your own words:
> cross-platform, open spec low level graphics API to the Mac
A "low level graphics API" sounds suspiciously like a standard to me. Doesn't it sound like a standard to you?
No. First of all something that is a "low level graphics API" most certainly does not sound like a standard, nor has it got anything to do with whether or not it would be a standard. But the point is MoltenVK is not even that, it is just an implementation of the Vulkan API on top of the Metal API so no, MoltenVK is most certainly not a standard.
> Nor are these APIs competing,
I'm very confused how you might think such a thing. As I understand it, "Vulkan" is competing with "Metal", the Apple published, closed source API. Both compete for market share and developer time with DirectX on Windows based machines. Even if you consider Vulkan to be the software successor to OpenGL, it's competing with the older versions of OpenGL.
Vulkan isn't competing with Metal, in the only situations where you can run both Metal and Vulkan code (on iOS and OSX) the Vulkan code you run is running Metal code
There's always a but (Score:2)
That's a pretty neat idea, but since a lot of Macs only have the intel integrated GPU I don't see how it will help.
Re: (Score:2)
There are still gains. Everything is relative. Remember, Intel's integrated graphics of today is good enough to run Crysis. ;)