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.
This is the primary UX for Vulkan. The problem is not the API PDF for OpenGL you download from Khronos - its all the drivers that implement it. Not only do you have to support he lowest common denominator GL version and then extension-check every higher level feature you want to use with two code paths every time, you also need to work around all the driver bugs you will find across the board with every combination of platform + GPU.
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.
You can. Go ahead and do it. Mesa is likely to implement future OpenGL extensions by translating them to Vulkan rather than implementing them natively to the metal, and someone is probably going to make a libgl that targets Vulkan rather than any of the intermediary layers used around the ecosystem.
I'm really excited to play with it as a hobby developer. Simply because I like doing low-level programming/optimizing for the fun of it.
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.
I believe that newer versions of OpenCL will benefit from Vulkan due to the mutual dependence on SpirV. My biggest hope is that this will finally reduce our reliance on out of date and buggy drivers to get OpenCL support on multiple platforms.
SPIR-V will be a huge boon for everyone and everything I hope, especially given the LLVM support (Haskell or Rust compilers anyone?). But it only augments the compiler step (AFAIK). I've had plenty of bugs in the host-side code before.
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 ;)
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.
You're right about the current status, but there is no reason to believe that there is any architectural issue in the way of performance parity with DirectX. This is a necessary first step, and there is a lot of reason for optimism :-)
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. :)
There's a similar performance hit going from DX11 to OpenGL for Talos Principle. According to one developer, it has something to do with OpenGL drivers having a "weak shader optimizer" [1].
But it's still faster than if you use OpenGL. For now all they did was write a simple wrapper to use vulkan instead of opengl. They are still working on improving it just like they did with DirectX 11.
> “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]...
> Apple had to remain the jerks they are and not support Vulcan natively
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.
> Are they jerks because they didn't saddle their users with a technically inferior solution for even longer?
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.
Metal predates Vulcan by any measure. It was the first publicly available low level graphics API and once they released it that have an obligation to support it. 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.
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.
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.
Their resemblance in design is just stunning and claiming it's accidental would be stretching that chance way too far. There were some documents published which even highlighted how early DX12 documentation was almost a verbatim clone of the Mantle one with only few minor changes.
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.
Well, not by 'any' measure (as others have pointed out). Additionally, do you find Metal to be a wholly unique creation? It certainly 'borrows' ideas from other low level mobile GPU APIs out there...
What Apple are doing with Metal feels eerily similar to what Microsoft did when they launched DirectX back in the day.
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.
I really doubt Apple will ever be big enough for many big game developers to consider making exclusives for Macs. They don't even sell any computers remotely targeted at games, and often sacrifice price and cooling for prettier design.
"Of course Apple had to remain the jerks they are and not support Vulkan natively, forcing developers to write translation layers[2]..."
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 not scared about Apple getting a monopoly. They are not going to sell as much as Android because they only care about the high margin stuff.
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.
The good part is, since all of them (Vulkan as well as DX12 and Metal) have roots in Mantle, they have a lot of similarities, which makes creating translation layers easier. So I wouldn't be surprised if we'll see Vulkan → DX12 layer in addition to Vulkan → Metal one. As well as other way around.
> As though its of no cost to Apple to make Metal available on every platform, or support other products on their platforms?
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.
PS: Things like compilation of shaders really made us suffer with OpenGL/CL. Those guys did not want to do it, so simple, and they did not do it for years, because they could.
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.
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?
This is kind of turning into FUD, the problem with OpenGL is not state - that is the problem with DX11, but for OpenGL we have AZDO in theory and properly implemented you should not see more stateful overhead comparing a Vulkan vs AZDO program.
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".
It's not a FUD. OpenGL was strongly overdue to be redone from scratch completely, and it's just great that Vulkan eventually was born from this necessity.
> 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.
> Because I care about working on phones, and on crappy old video cards and iOS and OSX.
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?
More likely, they committed to Mantle and now they have have to maintain it. The manpower to maintain 3 separate graphics back ends probably wasn't worth it, especially since big portions of the OS libraries now support metal.
My first thought on seeing Vulkan is that it is basically Metal for everyone else. Is that not so? Then why would you expect Apple to support Vulkan given that they already have Metal?
It's like saying that Apple shouldn't support JavaScript in the browser and should use AppleScript or anything else as long as it's incompatible (remember browser wars?). Why they should use it is quite straightforward - because it reduces duplication of work. Why they don't use it is clear as well - because they want to tax cross platform development with that extra burden. I.e. they use development tools as lock-in tactic. That's simply crooked.
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.
Yes, the crappy OpenGL version that they ship. Which lacks things like compute shaders. We are already seeing issues because of that: even though Elite: Dangerous runs on the Mac, the expansion does not and will not, as it requires compute shaders.
No, you really can't. Not only is the version available on OS X significantly out of date, it isn't even fully functional for the level of OpenGL it claims to support.
Apple doesn't have infinite software engineering resources. In fact, given how slowly they adopt new OpenGL stuff, it's probably safe to say that they're pretty constrained on software engineering resources when it comes to low-level graphics technologies. So it's not surprising at all that they've chosen to focus on Metal instead of implementing Vulcan.
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.
> So it's not surprising at all that they've chosen to focus on Metal instead of implementing Vulcan.
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.
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.
Their hardware vendors already wrote drivers that support vulkan for other platforms. If Apple is so resource constrained (despite sitting on billions of dollars in cash) why do they insist on building it themselves when they can't keep up?
NOT a successor. It's a very different beast. It's frequently described as a "low-level" API, but "explicit API" is more correct. It gives you control (and responsibility) for things that happen behind your back in OpenGL, e.g. semantics of sharing of resources between the CPU and the GPU, explicit separate access to many GPUs, explicit separation of command buffer building and submission etc.
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).
That's a big "NOT", though, for such subtle semantics and IMO more confusing than helpful. It's by the same people, for the same thing. It's set to replace OpenGL in the long term, no? I'd say that the only reason not to call it a successor would be if OpenGL offered features that Vulkan can't provide which I don't think is the case.
Historically there's been a big divide between what the game engine vendors vs the CAD vendors want out of the OpenGL standard, so this split is a good thing for both. The existing OpenGL systems stick around without dragging game performance down with them.
Why isn't it a subset of OpenGL, then? Maybe that's what's confusing?
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?
> It sounds like the most typical usage would be to implement things in OpenGL and then do a few hardcore optimization tasks in Vulkan.
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
We took "OpenGL Successor" out of the title. That language doesn't appear on the page.
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.
FWIW, I looked at the (current) title, read the page, and thought "Oh, right, this is the OpenGL successor, finally released. Why is that not in the title? It's important context for other readers."
The Wikipedia article on OpenGL lists Vulkan as the successor, and the former name for the Vulkan project was "Next Generation OpenGL Initiative" (glNext).
"OpenGL successor" was the headline everywhere when it was announced last year [1][2]. Personally, I see nothing wrong with including it in the title, even if it's not 100% intended to be the successor, it helps provide context to people unfamiliar with the software/industry. Almost all pitch deck guides recommend using similar analogies and it's probably the only reason this is #1 on HN.
There are reasons why they named it Vulkan rather than OpenGL 5. Though, as far as I can tell, the reasons were mostly political.
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.
Titles on HN are like acupuncture needles: you want them to go in without a reaction. Actually, I just made that up about acupuncture, but I'm sure it's true about titles. There's no more reliable effect on HN than the dreaded title fever.
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.
I think that Vulkan would almost always be the wrong choice for a new project. A higher level abstraction is probably the right choice, whether that would be OpenGL or a third party game engine or CAD kernel or visualization engine etc depends on the project.
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.
Well, when you write in Haskell and compile it to x86-64 machine code, you are indirectly using x86-64 machine code. That doesn't mean a Haskell programmer would like to write x64 asm, they're on quite different levels of abstraction.
The better case is to use one of the inevitably many rendering libraries that will be developed for Vulkan that abstract away the implementation details in much the same way OpenGL did before.
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.
>> Is there any case where you would not want to use Vulkan in a new project?
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.
> 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.
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, it's not going away. Perhaps slowly fading away would be a better description. Any new projects not using Vulkan would be at a serious performance disadvantage in comparison to its competitors. The switch to Vulkan will be swift, at least, in the game development community.
There is not one idea behind Vulkan, but many. It's not just a question about performance. Vulkan should make it easier to write libraries and middleware, for example. Vulkan will make it easier to use multiple threads. Vulkan will make it easier to write shaders, because you don't have to rely on the driver's compiler as much.
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().
Personally, I would love to see a reimplementation of OpenGL on top of Vulkan that behaves more consistently and with uniform feature support vs. what current drivers offer system-by-system.
Well it may not be a successor, but since Khronos' resources are limited you can bet there will be more updates coming to Vulkan than the OpenGL standard.
Maybe not a direct successor (as in OpenGL will now be deprecated), but still a defacto successor if all game engines adopt it. The bulk of the low-level work will be done by game engines, and developers won't have to worry too much about it. So developers will get the best of both words: easy to use and higher performance.
It absolutely is a successor. What the dev space sees is "old and busted" (OpenGL) vs. "new hotness" (Vulkan), especialky when the devs have such a boner for performance as game and 3D graphics developers do. Since most devs don't actually touch the graphics API but simply use whatever engine or framework was handed to them, and since the major ones have committed to supporting Vulkan, OpenGL is bound to be phased out over the coming years, existing mainly to support legacy apps.
Those "legacy apps" are things like SolidWorks, AutoCAD, 3DSMax, et cetera. Those are multi-billion dollar markets that aren't ever going to switch away from OpenGL. I predict that in 10 years or so Vulkan gets replaced by some new hotness but OpenGL will still be around.
Autodesk went all in on Microsoft platforms some years ago. AutoCAD and 3DSMax are Direct3D-only on Windows. Their software on Mac and iOS devices uses OpenGL for now, but I think Autodesk will likely switch the back end out for Metal, given Apple's sterling reputation for OpenGL support. /s
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.
I'm glad you clarify this because I thought it was meant not to replace OpenGL but to make it easier for certain developers to optimize and override GL behavior as needed.
Vulkan is indeed intended as a replacement, but in following decade OpenGL will still have to be supported so that legacy applications can still run.
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.
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?
Apple is a major Vulkan supporter and is on the "Board of Promoters". They went for Metal because they needed and wanted better performance long before Vulkan was going to be released.
My guess is we'll see Vulkan in the next major OSX/iOS release.
PS3 and PS4 both support OpenGL ES via wrapper on top of their low-level proprietary API. Also Nintendo had OpenGL ES support on all their consoles (at least on 3Ds for sure)..
Fwiw, all it takes is an annual fee to be on that list which is insignificantly small for someone like Apple. That's by no means an indication that Apple is a supporter in any meaningful way. They have said nothing about Vulkan in public at any point.
Long before? Didn't they just adopt Metal on Mac OS mid last year? Surely they knew Vulkan is almost done.
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.
> Didn't they just adopt Metal on Mac OS mid last year? Surely they knew Vulkan is almost done.
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.
Why does everyone misinterpret my comment to mean that I was talking about iOS?
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".
> They had no good reason to adopt it for Mac OS X at that point
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.
Apple isn't usually about "locking people in" but more about controlling the experience. That can lead to the same thing, where they want everyone to use their API and not someone else's, but the difference is whether they have greedy, malicious intent or not. I don't think they do. Having good intentions means they are more likely to surprise you and do something good eventually.
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.
> Having good intentions means they are more likely to surprise you and do something good eventually.
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.
Your definition of good and mine clearly differ. As has been noted, Metal existed and shipped before Vulkan, yet you claim they are using all its ideas in their own 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.
> As was noted, it didn't exist before Mantle and before AMD decided to open it.
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?
> Long before? Didn't they just adopt Metal on Mac OS mid last year? Surely they knew Vulkan is almost done.
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.
vulcan was actually a hastily thrown together proposition in response to the shocking (to OpenGL people) announcement of Metal by Apple. it helped a lot that AMD jumped on board by donating Mantle to Khronos.
Apple was on the X consortium too and did fuckall with it. If you want to be conspiratorial, they could have been there to undermine X so more people would develop for Mac. Draw your own conclusions w.r.t. Vulkan.
Mac decided to go for Metal. That's their choice. I believe they mentioned that they have not plans to support Vulkan at this stage. They are not part of the consortium, while even Microsoft is (despite them having DirectX as direct competitor).
Uh where are you getting that? Vulcan lists them as a promoter while Microsoft is just a member: https://www.khronos.org/members/ (Image at bottom of page)
Metal was first unveiled in early June 2014[0], and thus probably in the works some time before that. AFAIK the "Next Generation OpenGL Initiative" was officially announced at SIGGRAPH 2014, in August 2014[1], and the private kickoff meeting was the month before.
edit: heh, some people really can't handle the truth.
Considering the sorry state of OpenGL on the Mac and the fact that they are throwing resources on Metal, don't expect more involvement other than the board seat.
Thank you AMD. Vulkan is essentially a development of Mantle, AMD's next-gen graphics API, and without that forward-thinking leadership, we'd still be messing with (closed) D3D on Windows, (closed) proprietary per-game drivers from greedy Nvidia, and the outdated OpenGL.
Kudos all the more deserved for the fact that AMD doesn't have the financial firepower of its competitors.
The website says it is also a compute API. I haven't heard this before; I didn't know Vulkan came with a GPGPU stack. Does anyone have any experience looking at the compute aspects of Vulkan and how it compares to OpenCL?
I wanted to take a squiz at making GPU compute code for "fun" and I'm wondering if Vulkan compute is worth looking at.
Vulkan has explicit compute command queues. It is worth noting that OpenCL 2.1 compiles to the same SPIR-V bytecode that Vulkan drivers consume, you just generate it with a C API rather than GLSL, but either turn into the same thing.
The API itself supports some very cool compute functionality, such as asynchronously scheduled compute jobs. However, this functionality only exists on AMD hardware (to my knowledge). NVIDIA doesn't support it in HW (yet), and I don't _think_ it's in Intel HW natively. I don't think I've seen it in any other compute API either.
I've seen asynchronous DMAs + command execution (copy engine) exposed in some APIs, but not asynchronous compute shaders.
The AMD drivers haven't been sent for conformance testing yet, probably due to the fact that they're very buggy. (No personal experience but somewhere in this thread someone said they're unusable).
Thanks for the link. I think that just looking at the "simple" triangle example tells quite a lot about how low-level the API is (at least for me). The source C++ file is >27kB and ~760 LOC..
Could OpenGL be implemented as a library on top of Vulkan? So that future drivers will only implement the Vulkan API and if you want OpenGL, you just use an OpenGL library?
Not to dissuade you from graphics hacking in CL (it's a lot of fun!) but this isn't what Vulkan is for.
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 would disagree. With spirv we have for the first time a proper language agnostic compilation target. Likewise we have much lower level primitives upon which we can build idiomatic high level abstractions. Existing efforts built upon OpenGL and GLSL are very hairy due to the fact that we are trying to build high level abstractions on top of already high level (and very opinionated) abstractions.
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.
Isn't CL a perfectly reasonable thing to interface with Vulcan? Given its power, and things like compile macros, it could be possible to generate versions of some functions (array-oriented ones, for example) that would run on the GPU using SPIR. Other interfaces AFAIK don't support passing code like this (CUDA likes pre-compiled code (can it receive source texts?), OpenCL AFAIK accepts source code but you have to generate text and the driver has to compile it again.).
You might want to try CEPL and Varjo for an interesting take on this in the OpenGL/CL world. Programming in CL often feels like having a powerful compiler under the hood and an amazing debugger to start with.
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.
Could Vulkan be the opportunity to build a small and simple API for people to learn graphic programming?
I did learn OpenGl 10 years ago but it was already a big mess and each time I were searching for some information I could only discover mountains of hacks. I'm quit sure it's worse now.
OpenGL is much better these days and if it's your first foray into graphics programming learning WebGL is not a bad start IMO. You might need to use a browser that can support some of the OpenGL ES features (WebGL extensions) like VBO's and such but you can get really far that way.
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).
Learning graphic programming through Vulkan is like learning to implement quick-sort using assembly language.
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
I think porting three.js over to Vulkan (and node.js if it isn't available on desktop yet) would be a big win. You probably won't see much performance gains over plain GL given that it's a javascript library, but it will be a good learning experience.
ahh, yeah i hear you. I just never got into it and I understood the Vulkan announcement to be the latest edition to what OpenGL already brought. Cool, I think I will definitely explore CL bindings with OpenGL. Thanks!
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.
That's the big question I have: how well does Vulkan seem to be bridging the divide between API and GPU semantics? Will we finally see a time where graphics drivers no longer monkey-patch per game?
(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.)
> how well does Vulkan seem to be bridging the divide between API and GPU semantics?
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).
Great news! I am waiting for the book titled "Vulkan Programming Guide: The Official Guide to Learning Vulkan (OpenGL) 1st Edition" to come out. Looks like it will be out in August 2016.
Yes, it would be great, but it is most likely not happening anytime soon. As previously discussed on the WebGL mailinglist, Vulkan is strictly (and rightfully, wrt performance) working against all the security considerations that went into WebGL by design. A "WebVulkan" would thus not be much of a benefit, or even usable, if it's severly crippeled in it's features.
Even though Vulkan for would be of little gain for the web due to all the security considerations required, a WebGL backend should still be able to benefit from being built on Vulkan instead.
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
I completely agree and one could theoretically do away with things like ANGLE! Though, I also suspect that the implementor's overhead is rather large in contrast to the current way WebGL is implemented in Chrome and FF, which is currently a relatively 'thin' layer on top of OpenGL.
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.
Does this do anything to address the difficulties of sharing the gpu resources among processes, particularly concerning untrusted code like a website? Even opengl es can crash my video driver easily under a heavy load and it's more careful than opengl.
> Even opengl es can crash my video driver easily under a heavy load and it's more careful than opengl.
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.
Would it be worthwhile to write a Golang API on top of such a low level implementation or would that just negate the reason it exists in the first place?
Quick Vulkan starter pack (if you just want to see if it runs on your system, without compiling anything).
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)
I haven't read the docs yet but I wonder if this means there could be an open source d3d or opengl implementation that uses vulkan as its backend.
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.
They support Geforce 600 and up. I don't even think Nvidia released a Geforce 800 except on mobile which is just a rebranded Geforce 700 so it's likely actually supported.
Note the 'M' at the end of the model number. The laptop GeForce models are different (and less powerful) than the desktop models. According to the website, the 840M supports "entry-level gaming", which isn't really the primary use case for Vulkan.
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.