Vulkan is Here
khronos.org
khronos.org
https://twitter.com/renderpipeline/status/699346348651507713
There is no reason why any given app developer would want to talk to Vulkan directly. It's basically only suitable for a subset of engine developers and low level API programmers.
I also heard some people who were under NDA might have some disappointing things to report about the Vulkan decision process now that it's out. But the question is whether it matters at all whether it's a good API or not, given my impression that it's apparently not intended for interfacing to humans but to higher layer APIs.
It's quite a bit more positive about vulcan.
If OpenGL as of 4.5 were implemented perfectly on all hardware on all systems, we would never need Vulkan because everyone could just AZDO for optimization. Since we don't live in that fantasy world where pigs fly and Nvidia releases freedom respecting drivers, Vulkan takes responsibility away from hardware vendors who demonstrably cannot handle the work and puts the burden on the developer, who... probably also cannot handle the work, but thats a per-application problem rather than a fundamental API problem.
And I'm currently working on my Msc. in computational science (and possibly a PhD. afterwards) so I'm also going to see how easy it is to shoehorn generic-HPC into this API. OpenCL is nice (well... maybe not nice but workable) but historically the graphics APIs have had better performance for less work. But I guess you could count me as a low level API programmer come to think of it.
And of course, a newer version does not neccesarilly mean that the out-of-date implementations will suddenly become "in-date": if anything they're even more out of date now ;)
http://steamcommunity.com/app/257510/discussions/0/412447331...
TLDR: optimism for the future but right now performance is actually noticeably worse than their DirectX 11 rendering backend.
--------
A: Ok, first, in GPU-bound scenarios (ultra settings, resolution higher than full HD), you'll see lower performance, 20 to 30% lower. This is work in progress, and we (both Croteam and IHVs) are analyzing and optimizing the performance. We'll get to the bottom of this!
Q: And CPU-bound scenarios?
A: Same or a bit faster. But for now, those scenarios really have to be super-CPU-bound. Like, rendering whole levels, without any help from visibility system, frustum, distance or occlusion culling.
Let me put it this way: When The Talos Principle came out, it had a very similar frame rate in DirectX 9 vs DX 11. But then we optimized the game, and the drivers were optimized in the meantime, and now D3D11 is 20-30% faster than D3D9! I have a firm belief that this will also happen to Vulkan vs D3D11, over time However, for now you can actually expect lower frame-rate compared to D3D11. C'mon, it's brand new API, give it some time. :)
[1] https://steamcommunity.com/app/257510/discussions/0/61282346...
Note this however:
> “Vulkan takes cross-platform performance and control to the next level,” said Bill Hollings of The Brenwill Workshop. “We are excited to be working through Khronos, the forum for open industry standards, to bring Vulkan to iOS and OS X.[1]”
Of course Apple had to remain the jerks they are and not support Vulkan natively, forcing developers to write translation layers[2]...
[1] https://www.khronos.org/news/press/khronos-releases-vulkan-1...
Thats a rather immature view of the technology world that smacks of the tired old tribal warfare notions that only internet forums believe in.
Apple had a technical problem of slow, bloated and battery-draining OpenGL API and they solved it using Metal more than 18 months ago, when no other viable alternative was on the horizon. Are they jerks because they didn't saddle their users with a technically inferior solution for even longer?
Khronos has let OpenGL evolve into a byzantine beast of an API with GPU vendors effectively segmenting it into multiple complicated variants of best practices (like AZDO and others). Vulkan was announced more than two years ago, but unless you were in a select inner circle of developers, there was no actionable information available, until today.
In the meantime, major commercial engines already have official support for Metal (or Unity will have it soon). Popular games like World of Warcraft already have betas using Metal. I can download free IDE, documentation, sample profiling and debugging tools for developing Metal applications.
Sad truth is that Kronos and the Vulkan group took too long to evolve OpenGL and to give developers any actionable specifications for Vulkan.
Em no, they are jerks because they never updated OpenGL implementation on OS X (which still is generally 30% or so slower than Windows implementation on same hardware, not to mention lacking of full 4.2, 4.3, 4.4 and 4.5 OpenGL support) then implementing a new proprietary API on the desktop with huge fanfare and marketing about being "30%-50% faster" (or in other words - as fast as OpenGL is on Windows). Meanwhile, OpenGL implementation is still rotten as of 2016 at 2010 OpenGL 4.1 levels with no update.
Leaving an open implementation of a 3D standard to rot in performance limbo and then bringing in a new proprietary standard which has to be used to get competitive performance does bring the word "jerks" to mind.
And you think lock-in is a mature approach to technology? It is not. And lock-in is the only reason why Apple pushed Metal instead of joining the Vulkan effort. Unless you are trying to claim that they just couldn't plan things and ended up with their own NIH despite Vulkan emerging in the background. But that doesn't fly, since they could have corrected it when they realized where things are moving. So "no ill intent" reasoning here doesn't sound convincing.
See my answer here: https://news.ycombinator.com/item?id=11112078
This "Metal predates Vulkan" argument is getting old already since it's historically incorrect.
> It was released, what, 4 months after aMD announced mantle? That's not enough time to develop and deploy an entirely new API, from my memory Vulkan was more a response to Metal, DX12 and Mantle.
You remember it wrong. Again, see the link above.
According to Wikipedia's Vulkan article [1], "The Khronos Group began a project to create a next generation graphics API in July 2014..."
Wikipedia's Metal article [2] links to the presentation from WWDC 2014 (the first week in June 2014) where Metal was introduced. Apple doesn't ever per-announce APIs-- at this time Metal was available for developers to use.
The Mantle article [3] says AMD developed Mantle "...starting in 2013" (the referenced Forbes article is from September 2013.) I'm doubting this was ample notice for Apple to have elected to write Metal, design it, and implement it nearly completely for June 2014. However, I'd concede it is certainly possible (Apple just doesn't seem that nimble to me.)
I'd be interested in reading anything more authoritative than a comment board on the impetus behind what seems to be an industry-wide decision to create these lower-level APIs.
1 - https://en.wikipedia.org/wiki/Vulkan_(API)#History
You wouldn't find official documentation on AMD dealing with Apple and MS, because it was private. But you can clearly deduce that both Apple and MS had access to Mantle when designing their APIs by comparing them. It's even possible that AMD did some of the work for them.
Also, AMD never hid their intention to make Mantle open. They voiced it early on. So Apple and MS both new that would happen when they started working on Metal and DX12. And that's exactly what happened when AMD gave Mantle to Khronos. Vulkan essentially is an iteration over Mantle. Same as DX12 and Metal are.
Even if you assume it all happened by pure chance, and the stunning resemblance of design is just because many different people had the same way of thought - it's not going to explain why MS and Apple couldn't back Vulkan once they figured out where things are moving.
If we're lucky, it won't be as successful; decades of graphic stack fragmentation hasn't been pleasant to live through, both as a developer and a gamer.
GPU vendors don't care much about API support tooling, as long as their hardware gets sold.
We write programs that use DirectX,Metal, OpenGL/OpenCL, and now Vulkan and I disagree.
We believe competition is great. OpenGL/CL was in theory a standard but over the years we had to funnel way more resources to make that work than with DirectX or Metal combined. Why? Because of the "design by committee" mentality of OpenGL/CL.
The only reason they had to react with Vulkan was competition from private companies and even then the reaction was slow and painful for those that were forced to support the bloat software for years.
We could do the same thing in OpenGL/CL with 5 different ways,one modern way and 4 obsolete but not pruned from the standard because some company of the committee that had obsolete legacy code banned the removal.
This made the codebase so big and hard to maintain, and expensive for developers to support.
If Microsoft and Apple runs circles around those people, they are forced to act and develop a better standard.
For us it is easier to develop translation layers that support OpenGL/CL messiness.
Competition is great, sure. But Apple are anti-competition here. Competition would mean choosing between using Vulkan or Metal on their system. Where is that choice (wrapper is a workaround, but besides)?
All those lock-in proponents are actually scared of competition. So we are not in disagreement. Competition is indeed good. Lock-in however is not, and lock-in is anti-competition.
> The only reason they had to react with Vulkan was competition from private companies
It's the other way around. The only reason MS and Apple suddenly woke up is because AMD was planning to open up Mantle (which resulted in Vulkan). Except they reacted in their usual manner. Instead of helping the shared effort they pushed for more lock-in.
I am more worried about Microsoft though, with Windows and Xbox they force millions of people to use DirectX.
Yeah, we agreed on that . It took millions for our company to support OpenGL/CL only because we did not want to make our code dependent on just one provider. It was tough to justify that decision (financially). Decision that only started to pay back with Android popularity.
Not every decision has to be filled with malice, sometimes it just makes sense.
It was of no cost for them to simply copy most of the ideas from Mantle to make Metal, saving all that huge effort on initial design, isn't it? Somehow that doesn't surprise you. But when they are criticized for not doing it in the opposite direction (by sharing the effort and supporting the common API), you are surprised.
No matter what feedback from developer were, those people didn't care. But Microsoft did and forced the guys to react much later.
The same thing happened with so many things to mention here, like asserting the same quality on different machines that save millions to companies in debugging time and money.
The question is why Apple can't support Vulkan, or rather why wouldn't they. The answer is quite obvious - they like lock-in.
> If the Flowchart is true
Flowchart is not true, because using OpenGL is not a good proposition going forward. Some will develop more tools and higher level frameworks to make using Vulkan easier. But jerks like Apple, MS and others will put roadblocks for developers preventing them from using the new API on their platforms.
Why? Khronos has publicly stated that development of OpenGL will continue, and that OpenGL and Vulkan will continue to co-exist.
Because it's inherently stuck in the outdated model of using huge state machine where state is shared. It doesn't allow using parallelism efficiently.
> Khronos has publicly stated that development of OpenGL will continue
They are free to continue it, but I don't see a benefit of using it instead of Vulkan for anything new. The main drawback of Vulkan now is that it's low level in comparison with OpenGL. That gap will be filled in with frameworks on top of Vulkan which will provide higher level abstractions implementing a lot of common boilerplate while using Vulkan's approach of avoiding massive state machines. And those who need that low level directly can always go there. So why would you use OpenGL exactly?
The problem with OpenGL is that despite the official version being 4.5, and that including all the useful mechanisms to reduce overhead and make your renderer CPU efficient, only AMD and Nvidia proprietary drivers on Windows and Linux support it - which means you cannot realistically actually use it without having the same "minimum version renderer with extensions for optimization and features" model that makes writing OpenGL programs literal hell.
The point of Vulkan is less "fix a fundamental flaw in the efficiency of the OpenGL API as it exists" and more a "fix a fundamental flaw that hardware vendors don't write working OpenGL drivers that support the standard and stay up to date".
> The point of Vulkan is less "fix a fundamental flaw in the efficiency of the OpenGL API as it exists" and more a "fix a fundamental flaw that hardware vendors don't write working OpenGL drivers that support the standard and stay up to date".
It's both. AZDO attempted to fix serious deficiencies of the API without rewriting if from scratch, making it a rather awkward and not easy to use addition. Vulkan solved the same problem building it neatly from the ground up.
And of course making compliant and verifiable implementations is a great benefit of Vulkan, and it's something that OpenGL always lacked.
Because I care about working on phones, and on crappy old video cards and iOS and OSX.
Because the only times Vulkan provides any benefit over OpenGL is when I'm CPU bound, and that only happens on high end video cards, which are handling my workload without a sweat, so why would I bother optimizing those?
Because Vulkan is a low level API that's not easy to program for. OpenGL isn't exactly easy to use, but it's a heck of a lot easier than Vulkan, from what I can tell.
Because the work I do is more closely related to the CAD market than the video game market, and I know that there's enough money in CAD, and that OpenGL is not going anywhere for CAD, so I'd bet that OpenGL will be around for ~25 years in some form or another. I wouldn't place that bet on Vulkan.
Sure, OpenGL will remain useful for supporting both legacy applications and legacy hardware.
> Because Vulkan is a low level API that's not easy to program for. OpenGL isn't exactly easy to use, but it's a heck of a lot easier than Vulkan, from what I can tell.
I answered that above. It's not a reason to use OpenGL, it's a reason to write something on top of Vulkan to make things easier.
> Because the only times Vulkan provides any benefit over OpenGL is when I'm CPU bound
It provides a benefit of using your hardware to full potential. You can't even properly saturate the GPU with OpenGL with parallel workload, unless you use AZDO and other such things which turn it inside out trying to bypass its limitations.
> Because the work I do is more closely related to the CAD market
And why exactly Vulkan can't be used in the CAD market?
Longspeaks has the CAD industry to thank for.
Some history can also help. It all started from Mantle. Basically AMD grew tired of current APIs being behind the curve, and designed one from scratch that matches modern hardware approaches. Then Apple and MS used those ideas to push their lock-in off-shoots (they copied most of the ideas verbatim, working closely with AMD). Meanwhile, AMD simply opened up Mantle (they voiced this intention from the beginning) and gave it to Khronos as an initial proposal for Vulkan. The rest you probably know. So why exactly MS and Apple didn't get behind the shared effort? Because they are lock-in jerks. That's all there is to it.
So it doesn't excuse their lack of support for Vulkan in any way.
Sure, I'm not saying they are looking for excuses. They are just lock-in jerks and never really hid the fact.
As for why they did Metal, they most certainly started work on it before the Vulcan project started. Wikipedia says[1] that the Vulcan project was started in July of 2014 (and then announced publicly at SIGGRAPH, which appears to have been in August). But Apple released metal with iOS 8 in September of 2014, and they'd obviously been working on it for more than a couple of months.
In an ideal world, Apple would support both. But it's not an ideal world and supporting Vulcan would take resources away from their work on Metal, and that's not something that makes sense for Apple to do.
That's not the real reason, unless Apple will claim that they can't plan things right. They knew Vulkan was coming, so they could allocate their resources to it from the beginning. But they decided to push for Metal instead.
The history you linked to is missing important events prior to that. See here: https://news.ycombinator.com/item?id=11112078
TL;DR: Vulkan wasn't born out of nothing. Things started with Mantle. Apple didn't want to share effort in both directions joining the open API (which ended up in Vulkan), and made their Metal for themselves only, using the same Mantle as the source.
It will live side-by-side with OpenGL for the foreseeable future. It's just targeting the same general area (graphics using GPUs) and is standardized by the same folks (Khronos).
No. Not at all. That's why it's not a successor.
If you're a huge games company writing an engine, sure, it's a better fit for you than OpenGL.
If you're almost any other visualization use-case, it's too low level and you'll want to remain with the higher level OpenGL API.
It's an alternative, not a replacement. At most OpenGL might come to be a friendly API implemented on top of Vulkan, as opposed to beside.
EDIT: Some historical discussion in this reddit thread https://www.reddit.com/r/vulkan/comments/3hkdek/opengl_suppo...
It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan. Why not add that access to OpenGL and put a "use at your own risk" disclaimer in front of it? Or are they so incompatible you have to write your entire graphics code in either but never both?
No. You can't really mix the two. The semantics are wildly incompatible.
Roughly: the OpenGL API models an ideal graphical state machine and does an enormous amount of work to retain state and paper over the fact that a modern GPU works nothing like the ideal state machine.
Vulkan does literally the opposite. Stateless calls that let you control low-level GPU resources, and nothing more. You can't really make a bunch of Vulkan calls and then an OpenGL call that will blow away all your buffers, generate shader code dynamically without telling you, and do a billion other things "magically", and make it all work. The two fundamentally different approaches are in opposition.
They're implemented by different drivers, as well. The Vulkan driver is intentionally very thin, stateless, and consequently multithreading-friendly. The OpenGL driver is enormous (including everything up to and including a GLSL compiler), stateful, and consequently very hard to use from more than one rendering thread. This is a big source of performance issues, since it means draw calls are inherently limited to a single thread, which is a big limiter for games.
You can't have the two different models, from two different drivers, talking to the same hardware at the same time. It would be pointless even if you could -- you use Vulkan so you can thread draw calls. OpenGL destroys that.
I think this answers your first question, too:
> Why isn't it a subset of OpenGL, then? Maybe that's what's confusing?
You lose the thin & multithread-able advantages of Vulkan if you keep OpenGLs higher level stateful semantics around.
It's been tried, many times, in different OpenGL versions, over the years, to create a low-level performant subset. The conclusion has always been the same -- retaining compatibility with higher level calls hampers what you can do in your new low-level calls (need to constantly sync state and expect that at any time a call could have been made that changed any number of internal state variables == lots of checks and lots of locks). Your draw call ceiling is always low and CPU bound because the locks kill threadability
Submitters: the HN guidelines ask you to use the original title except when it is misleading or linkbait. Please don't add editorial interpretation—it's against the spirit of the site and often turns the discussion into a nitpicky debate about what you did to the title. In this case, the post has no obvious single title, but the subtitle "Vulkan Is Here" works fine.
The Wikipedia article on OpenGL lists Vulkan as the successor, and the former name for the Vulkan project was "Next Generation OpenGL Initiative" (glNext).
[1] "Khronos announces openGL successor Vulkan" http://www.infoworld.com/article/2892236/khronos-announces-o...
[2] "The successor to OpenGL has a name: Vulkan" http://www.gamasutra.com/view/news/237907/The_successor_to_O...
It reminds me of Nintendo releasing the Nintendo DS and calling it their 'third pillar', standing alongside their home console and Gameboy lines. They made it quite clear that despite its similar market position, the Nintendo DS was not the next Gameboy and it was not replacing the Gameboy line. Of course, the DS was incredibly successful and they never made any new Gameboy-branded handhelds ever again. (Though they did do a few updates to the existing model.)
The Nintendo DS was a Gameboy that they didn't want to call a Gameboy, and so when it succeeded the brand simply changed and things continued on as usual.
I suspect that we may see the same with Vulkan. When anyone can design an OpenGL-like abstraction as a library on top of Vulkan, the desire to make big updates to OpenGL will fade.
Even here, the discussion of how Vulkan relates to OpenGL would be better if not hung up on the word "successor", and would naturally have come up in the thread.
Is there any case where you would not want to use Vulkan in a new project?
https://twitter.com/renderpipeline/status/699501481632886786
All major engines already have announced migrating to Vulkan and/or its platform-specific counterparts (DX12/Metal), so you'd be indirectly using Vulkan anyway.
The problem with OpenGL was that it was the lowest level of access you got to the device - a high level giant API that hides the implementation behind it. Which made it a massive PITA to implement for hardware vendors, and slow to adapt to changes in the GPU landscape.
It is very likely we will see an implementation of OpenGL that compiles to Vulkan in the same way we are seeing immediate development of VK -> Metal compilers and will probably see DX12 -> Vulkan as well. You just need an API wrapper and a shader translator that takes their respective shader formats and compiles them to SPIR-V rather than the original targets.
Any project with graphics simple enough that it already easily hits the desired performance on baseline hardware?
If you don't need full control or maximum performance, something like OpenGL ES 2 will still be a lot easier to program because it does a lot of things for you that you would have to do yourself when using Vulkan. Also, the installed base of supported hardware/drivers will be much larger for the foreseeable future.
I've looked into Metal (Apple's take on an API along the same lines as Vulkan) for my simple 2D game, but for my purpose it does not offer any benefits. The same thing would hold for Vulkan, in case I would want to port to some other platform.
Which is normally done by the game engine. And the big ones are already migrating to Metal et. al.
Is the market for self-made game engines still that big? From a consumers perspective, virtually everything is on one of the "big" engines nowadays (when in doubt, Unity).
Sure, for games. Not all projects using 3d graphics are games, or use game engines.
Or is it more likely to stay as something for engine builders, and as a fall-back for the points where OpenGL performance isn't sufficient?
I think we'll have to wait and see how people actually use it. I know from answering Stack Overflow questions that a lot of people are still using glVertex().
Point being that OpenGL exists mainly to support old CAD apps. Actively maintained current apps will switch to Vulkan, or whatever API provides the best benefit on the target platform.
New game engines and other graphically intensive applications will probably target both OpenGL and Vulkan, at least until Vulkan is supported on most of hardware available.
It is intended to replace OpenGL eventually. It matches modern hardware and unlike OpenGL allows using parallelism without shared state.
Why not? It is a successor, except it's not an iterative development but rather an effort to make things from scratch (which is good in this case).
> It will live side-by-side with OpenGL for the foreseeable future.
Sure, because OpenGL is still needed for supporting legacy applications and anything that won't be rewritten to Vulkan.
If this follows the usual trajectory, we'll have a sort-of-working implementation of Vulkan 1.0 in OS X 10.13 (although it will kernel panic if you look at it the wrong way).
But maybe Apple's stance on Vulkan is different now due to their own Metal API? Is Apple involved in Vulkan at all?
My guess is we'll see Vulkan in the next major OSX/iOS release.
Console vendors are also there and they never cared about OpenGL support, regardless of urban legends.
The only console to ever support OpenGL was the PS3 with the OpenGL ES 1.0 / Cg combo that very few ever bothered to use.
Also remember that although Apple created OpenCL, their implementation leaves a lot to wish for.
Nintendo uses GX and GX2.
I think they just wanted to see if they can push major game developers to adopt Metal for Mac games early on. If they could do that - awesome for them, and they would never have to adopt Vulkan. If they can't, they'll have to adopt Vulkan.
Here's hoping the latter will happen.
Vulkan was announced in December 2014, with no significant commitment.
iOS 8 including Metal was announced mid-2014, and would have been in development for a considerable time before. By the time it was announced for OSX, Vulkan was still anaemic and not showing significant progress.
So it does make sense to keep using Metal for them.
> I think they just wanted to see if they can push major game developers to adopt Metal for Mac games early on. If they could do that - awesome for them, and they would never have to adopt Vulkan.
If that was the plan, it's probably going to fail: The developers of Unity e.g. found Metal, DX12 and Vulkan so similar that they estimate to be able to support all three with minimal development overhead.
I know Metal was announced for iOS earlier - I was talking about the support for Mac OS X. They had no good reason to adopt it for Mac OS X at that point, if they were planning on adopting Vulkan in the near future anyway. Unless, like I said, they'd prefer to keep Metal over Vulkan, and wanted to give it a head start to see if PC game developers would start adopting it.
> If that was the plan, it's probably going to fail: The developers of Unity e.g. found Metal, DX12 and Vulkan so similar that they estimate to be able to support all three with minimal development overhead.
I'm not sure how you see that as a "failure". If they are so similar that game engine developers will keep Metal around anyway, then we'll see games be built on Metal, not Vulkan, for Mac OS X. How is that a "failure"? It would mean Metal "won".
Of course they did: it was already their API of choice on iOS, platform unification alone makes it a damn good idea to adopt it for OSX: iOS is by far their most popular gaming platform, integrating the API back to OSX makes it more likely they'd get more OSX support.
Not to mention a mid-2015 release of Metal-on-OSX means they'd probably been working on it since the Metal-on-iOS release. On top of fragmenting their platforms, waiting for Metal would have meant a year-long delay.
They did have a reason, except it's nowhere good. They don't want to support Vulkan because it increases their lock-in control and puts extra tax on cross platform development. Same reason MS doesn't want to support it on Xbox. It's not a good reason, it's pretty crooked but very Apple like.
Still, I wouldn't hold my breath on Apple supporting Vulkan soon. Their OpenGL support is usually a few versions behind so if they do ever support Vulkan I would expect it to be late.
I'll agree to that when I'll see it. I.e. if their intentions are good - they'll get behind the Vulkan effort and will add native support for it on their systems. So far they clearly stayed away from it, but surely noted all its ideas to use in their lock-in variant.
Multiple people have mentioned in this thread how engine vendors have abstracted all 3 competing technologies (Metal, DX12, "Vulkan") with minimal effort.
How is there any lock in here? How is it any different from Microsoft or any other vendor deciding to, or not, implement DX12 or Vulkan?
As was noted, it didn't exist before Mantle and before AMD decided to open it. So Apple in fact knew about it all along. Again, you can't try to dismiss their lock-in attitude with the claim that they just needed something and had no alternatives. They simply made the lock-in choice.
> Multiple people have mentioned in this thread how engine vendors have abstracted all 3 competing technologies (Metal, DX12, "Vulkan") with minimal effort.
Indeed, since they share lot's of core ideas (all of them originate in Mantle). The question is not about why one can't abstract them, but why Apple and MS push their lock-in instead of collaborating. And you wouldn't like the answer.
>How is there any lock in here? How is it any different from Microsoft
Who said it's different? It's the same crooked practice. But I'm surprised you don't see the obvious lock-in issue here.
I see that claim, I don't see any evidence. The first evidence of Mantle being donated to Khronos date back to early 2015, not early 2014. Mantle was not open-source or open at initial release, and wasn't even supported on all AMD hardware.
> So Apple in fact knew about it all along. Again, you can't try to dismiss their lock-in attitude with the claim that they just needed something and had no alternatives.
Wait, so Apple's proprietary API is bad because AMD's proprietary existed before it? How does that even make sense?
> They simply made the lock-in choice.
Mantle was only available for AMD hardware on Windows, Apple's first need was ARM/PowerVR on iOS…
> The question is not about why one can't abstract them, but why Apple and MS push their lock-in instead of collaborating. And you wouldn't like the answer.
You do realise your pet conspiration theories are only answers to the question "what are your pet conspiration theories" no matter how many time you hint at them, right?
Its design was generic, and both Apple and MS used it to make their lock-in variants.
And will use Vulkan on BSD/Linux, with much less problems than you have currently.
(Complaining about a lack of open software on a proprietary operating system running on proprietary hardware is a bit silly, isn't it?)
Metal was made available in iOS8, in September 2014, almost 18 months ago. That's pretty long. In fact the first Metal public demo predates the Vulkan private kickoff meeting.
> I think they just wanted to see if they can push major game developers to adopt Metal for Mac games early on.
Mid-2015 they made their iOS graphics API — which had been available for nearly a year at this point — available on OSX. Fact remains that they realised a need for and started working on a lower-overhead API much earlier than Vulkan was conceived let alone released, likely circa 2012~2013 if they were almost done by mid-2014.
EDIT: Removed hotlink
It's a choice which predates Vulkan being even thought of though.
edit: heh, some people really can't handle the truth.
[0] http://www.anandtech.com/show/8116/some-thoughts-on-apples-m...
[1] https://www.phoronix.com/scan.php?page=news_item&px=MTc2ODQ
Kudos all the more deserved for the fact that AMD doesn't have the financial firepower of its competitors.
I wanted to take a squiz at making GPU compute code for "fun" and I'm wondering if Vulkan compute is worth looking at.
I've seen asynchronous DMAs + command execution (copy engine) exposed in some APIs, but not asynchronous compute shaders.
And credit: https://twitter.com/renderpipeline/status/699501481632886786
Err, do they? Where?
I was under the impression this isn't implemented yet and is expected to be included in Android 7.
Imagination Tech has an SDK as well. Apparently, a Nexus Player is a good device to work on with it.
https://www.reddit.com/r/gamedev/comments/463jo2/vulkan_api_...
Hopefully with lower level APIs like vulkan it means higher level APIs could be better designed than opengl perhaps?
It's a graphics API that gives you more explicit control over synchronization, buffering, and resource sharing. There's still many reasons to prefer OpenGL (for which there are good bindings in CL already and could use more contributors!).
If you're just the curious sort and want to know more then by all means... it will be a tough battle if this is your first delve into graphics programming.
I find this to be a very exciting opportunity, not just for CL but for many other languages, to have a framework that feels like belongs in the host language, not just fugly ffi wrappers.
(Note: I'm personally interested in this.)
I'm not suggesting you cannot write a Vulkan API library in CL -- work has already begun in that direction: join in on #lispgames if you're interested.
It's just not going to be the ideal API to learn if you're new to graphics programming when OpenGL is already here, is rather well understood, and has plenty of supporting libraries and extensions for most needs.
Vulkan is not the right choice if you're just getting started unless you're already motivated and intensely curious (ie: already have some decent exposure to OpenGL, multi-threading, and are curious to know more).
Sure, it can be done, but it's most likely to lead to tons of frustration and abandonment.
I was pretty good using classic OpenGL (before shaders), and writing a 100% shader based simple example was quite some work, mostly spent understanding how 4x4 matrices and graphics are related.
I expect for most typical programmers for that to be the hardest part, understanding how pixels emerge from a long pipeline of operations on 3 or 4-vectors and 4x4-matrices
You can build a better OpenGL on top of Vulkan, but until someone writes one OpenGL for average developers makes more sense.
1. Less CPU usage than an equivalent game in OpenGl. This is especially true for games which want to draw lots of different individual things to the screen, so you may be seeing more of those.
2. Smaller drivers, which means more consistently performant and bug free. There's far less of a chance of getting weird things from having an unusual operating system or graphics card setup.
3. More cross platform. There are many different pieces which change on different platforms (consoles vs desktops vs mobile), but depending on what platforms choose to support Vulkan, it's one less thing to worry about when porting over.
4. Maybe better games. There's a bunch of things which help with development, so as long as a sufficient majority of graphics cards get vulkan drivers, it may help reduce some coding cost.
Games which use common engines (ie, Unity) will likely get these features for free. Others will have to work harder for it.
(I'm still somewhat skeptical as the monkey patching is a value-add secret sauce that seems likely to continue solely because it's such a weird competitive thing between the two biggest vendors and a galvanizer for the brand loyalties they try to maintain, but perhaps I'm just feeling pessimistic about the capitalist drives here.)
That's the entire point behind Vulkan. OpenGL was created back when we still had fixed-function rendering pipelines in GPU's, and while it has evolved to support the massively parallel supercomputers GPU's have become it doesn't have much low-level control over it. Vulkan gives the engine developer the thinnest abstraction possible over a modern GPU, from everything from explicit resource sharing and even explicit access to multiple GPU's (no more relying on nVidia and AMD to add SLI/Crossfire profiles).
The end user will see better framerates, I suppose.
Spending less time in the driver generally means spending more time doing useful things.
Looking forward to seeing SPIR-V compilers in other languages...
Due to the refinement of the pipeline and memory access, etc. provided by Vulkan, there's a lot of room for optimization.
___
Though on the other hand, even with additional overhead on a Vulkan web API, the improved state management and access to command buffers may still allow for smarter rendering with negligible overhead via JS
Fun times
On the other hand the nature of implementation in Chrome, i.e. does seem to lend itself somewhat to a command buffer approach as in Vulkan.
If Vulkan as low-level as expected then it's will easily let app lockup your GPU completely. Though as drivers are they shouldn't cause troubles anymore.
Windows-centric, but many things also available for Linux and Android.
------- Drivers -------
Nvidia GPU driver: https://developer.nvidia.com/vulkan-driver (worth trying even if your GPU is not listed as supported, e.g. 900 series mobile Maxwell GPUs like GTX 970M or GTX 980M work ok)
AMD GPU driver: http://support.amd.com/en-us/kb-articles/Pages/Radeon-Vulkan...
------- Demos -------
Nvidia Vulkan Choppers demo: https://nvidia.app.box.com/s/rj9nzxkpz21qu34h8zew301kray9urb...
Nvidia Vulkan Fish demo (threaded rendering): http://developer.download.nvidia.com/mobile/shield/assets/Th...
Vulkan examples binaries by Sascha Willems: http://vulkan.gpuinfo.org/examples.php
- requires assets from source distribution (create "bin" subfolder and place binaries there): https://github.com/SaschaWillems/Vulkan
- also may need to install Visual Studio 2015 redistributables: https://www.microsoft.com/en-us/download/details.aspx?id=481...
------- Games -------
Talos Principle: http://store.steampowered.com/app/257510/ (there is a free demo available)
See how to enable Vulkan support here: http://steamcommunity.com/app/257510/discussions/0/412447331...
------- Tools -------
Vulkan HW capabilities database: http://vulkan.gpuinfo.org/
Vulkan Hardware Capability Viewer: http://vulkan.gpuinfo.org/download.php
https://01.org/linuxgraphics/downloads/intel-graphics-instal...
Also: it is a shame the API docs appear to be behind a login page. Hopefully that will change! The nice thing about opengl is it (at least when I used it) the docs were easy to get at.
The Khronos site seems to be overloaded right now.
Deleted comment
> This is not even slightly GL 3.1 hardware.
And Vulkan require 4.3 feature set.
https://developer.nvidia.com/vulkan-driver
Why is this so, any idea?
$ lspci | grep -i nvidia 03:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 840M] (rev a2)
https://www.khronos.org/conformance/adopters/conformant-prod...
I don't know why some dates are in the future..