Hacker News new | past | comments | ask | show | jobs | submit login
Vulkan is Here (khronos.org)
903 points by ekianjo on Feb 16, 2016 | hide | past | web | favorite | 201 comments



This chart sums it up pretty well:

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.


A more recent version of the chart from the same source: https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig

It's quite a bit more positive about vulcan.


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.


Why couldn't someone write a "Vulkan backend for OpenGL" that combined proper standards conformance with actual hardware acceleration?


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 ;)


For reality check read "Talos Principle" FAQ on their Vulkan port (probably the most complex non-toy Vulkan application you can try today):

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.


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 :-)


Indeed, from their Q&A http://steamcommunity.com/app/257510/discussions/0/412447331...

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].

[1] https://steamcommunity.com/app/257510/discussions/0/61282346...


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.


Congratualations! It's a major step forward.

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...

[2] https://moltengl.com/metalvk/


> 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.


> Thats a rather immature view of the technology

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.


> Metal predates Vulcan by any measure.

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.


I'm not seeing a timeline in your 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

2 - https://en.wikipedia.org/wiki/Metal_(API)

3 - https://en.wikipedia.org/wiki/Mantle_(API)


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.


Then it is up to the community/Khronos to provide the same tooling and support games developers enjoy from Apple, Microsoft, Sony and Nintendo.

GPU vendors don't care much about API support tooling, as long as their hardware gets sold.


"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.


> We believe competition is great.

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?

Not every decision has to be filled with malice, sometimes it just makes sense.


> 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.


This is really more a case of fragmentation than it is of competition.


"They have every logo on here except Apple," was the first thing I thought upon seeing the page.


You can still use OpenGL on OSX / iOS. If the Flowchart is true, then it wouldn't matter for 80% of people, for the rest, there is Metal.


> for the rest, there is Metal.

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 using OpenGL is not a good proposition going forward."

Why? Khronos has publicly stated that development of OpenGL will continue, and that OpenGL and Vulkan will continue to co-exist.


> Why?

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.


"So why would you use OpenGL exactly?"

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?


> OpenGL is not going anywhere for CAD

Longspeaks has the CAD industry to thank for.


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.


This seems cognate to "Web standards are basically an alternative to the way IE 6 works, so why would you expect Microsoft to support Web standards?"


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.


That's crass: Apple has Metal, and has had it for a few years now, so perhaps a healthier attitude is to give it time.


Apple knew where things are going all along. See my other answer: https://news.ycombinator.com/item?id=11112078

So it doesn't excuse their lack of support for Vulkan in any way.


They don't need excuses when they don't behave as you wish, as they aren't subject to your whims.


> They don't need excuses

Sure, I'm not saying they are looking for excuses. They are just lock-in jerks and never really hid the fact.


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.

[1] https://en.wikipedia.org/wiki/Vulkan_(API)#History


> 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.

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.


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.


> It's set to replace OpenGL in the long term, no?

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.


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.

EDIT: Some historical discussion in this reddit thread https://www.reddit.com/r/vulkan/comments/3hkdek/opengl_suppo...


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).

https://en.wikipedia.org/wiki/OpenGL#Successor


"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.

[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...


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.


OpenGL is not going away (huge existing code basis etc.), but I'm not sure how much continued development it's going to see.

Is there any case where you would not want to use Vulkan in a new project?


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.

https://twitter.com/renderpipeline/status/699501481632886786


> or a third party game engine

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).


> Which is normally done by the game engine.

Sure, for games. Not all projects using 3d graphics are games, or use game engines.


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.


Is the idea people will build higher level API's on top of Vulkan which will rival OpenGL?

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?


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.


To make a networking analogy, Vulkan/SPIR-V is an ideal thin waist with drivers and hardware below, and engines and games above.


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.


> 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.

It is intended to replace OpenGL eventually. It matches modern hardware and unlike OpenGL allows using parallelism without shared state.


> NOT a successor.

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.


As usual, not available for Mac.

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.


Being on the board means zero.

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.


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)..


Keyword being a wrapper, so no native support.

Nintendo uses GX and GX2.


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.

Here's hoping the latter will happen.


> 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.


> Of course they did

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?


> Metal existed and shipped before 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?


> Mantle was only available for AMD hardware

Its design was generic, and both Apple and MS used it to make their lock-in variants.


> 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.

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?)


> 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.


Perhaps you missed this: https://moltengl.com/metalvk/


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)

EDIT: Removed hotlink


That link gives a "please do not hotlink our files" error.


Image at bottom of page https://www.khronos.org/members/


That's a list of members of Khronos. Apple is there because of OpenGL. It doesn't say anything about Apple being involved in the Vulkan effort.


> Mac decided to go for Metal. That's their choice.

It's a choice which predates Vulkan being even thought of though.


Not sure about that, there were mentions of OpenGLnext (the former name of Vulkan) for a while already.


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.

[0] http://www.anandtech.com/show/8116/some-thoughts-on-apples-m...

[1] https://www.phoronix.com/scan.php?page=news_item&px=MTc2ODQ


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.


If you bought a Mac and you want to play games, just reboot to Windows using Bootcamp


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.


Cool. Makes sense, doesn't it, it would be a bit silly to expose a new GPU API in this day and age and not include a compute interface.


This is not really surprising, OpenGL got compute shaders in 4.3.


And here's a chart on whether or not you should switch to Vulkan:

https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:large



Someone should make charts like these for new js frameworks.


Dont notice any AMD products at https://www.khronos.org/conformance/adopters/conformant-prod... even though AMD already has drivers out. Whats up with that?


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).


> Google gives you everything you need to incorporate Vulkan into your Android games and other apps where graphics performance is key

Err, do they? Where?

I was under the impression this isn't implemented yet and is expected to be included in Android 7.


Yeah, I am also wondering. All I see is the same ol' link to half-outdated NDK documentation.


Nvidia has an SDK today for Sheild devices https://developer.nvidia.com/vulkan-android

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_...



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?


I was thinking the same thing. Seems like that could have a lot of neat applications as afar as porting and keeping existing software working.

Hopefully with lower level APIs like vulkan it means higher level APIs could be better designed than opengl perhaps?


A video showing the dramatic performance difference between Vulkan and OpenGL on an Android TV device:

https://www.youtube.com/watch?v=P_I8an8jXuM


Can anyone explain (or at least provide a glimpse to) why the difference is so huge?


It's described in the link: http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-a..., the code doesn't use any batching but each gnome is a unique draw call, which is a worst-case scenario for OpenGLES2.


This is finally my chance to delve into graphics hacking. I'm interested in bindings to Common Lisp with this >:)


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.).

(Note: I'm personally interested in this.)


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.


Yes, it is, but it takes someone who knows what they are doing to abstract the hardware for the user.

You can build a better OpenGL on top of Vulkan, but until someone writes one OpenGL for average developers makes more sense.


Nope. Using a"simple" API is exactly what you don't want when dealing with graphics hardware, because then the burden is on you.


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!


The CEPL [0] project could be of interest to you! Pretty great approach to OpenGL from CL.

[0] https://github.com/cbaggers/cepl


Dumb question: what will change for end-users ?


I think that's quite a reasonable question.

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).


Should get better Linux drivers, since the GPU driver will be a much thinner layer.


IMO, even more important than better performance is more predictable performance.


Better multithreading => better performance => more CPU for other tasks (AI for example).


AFAIK it's mostly a performance booster in some niche cases where low level GPU access is the bottleneck. I've seen VR mentioned, for example.

The end user will see better framerates, I suppose.


Any CPU-bound application should see benefits as far as I understand it.

Spending less time in the driver generally means spending more time doing useful things.


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.


I think what's most interesting is strong multi threading support in conjunction with an intermediate representation.

Looking forward to seeing SPIR-V compilers in other languages...


I am seeing forward to a possible "WebVulkan" analog to WebGL.


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

Fun times


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.


The reason I have been waiting for Vulkan is to get rid of OpenGL driver bugs. I hope that being closer to metal means less bugs.


It is rare to see a cross platform release with so much collaboration behind the scenes. Extremely exciting!


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.


* Ooops, as drivers are tiny.


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)

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


Nvidia also just put out a C++ API as well:

https://github.com/nvpro-pipeline/vkcpp


Why did they call it vk_cpp.h and not vulkan.hpp? Why???


Intel also released experimental driver for Linux: https://01.org/linuxgraphics/blogs/jekstrand/2016/open-sourc...


Sadly, it appears that the Intel drivers do not support Ubuntu 14.04 due to a packaging issue with LTS releases.

https://01.org/linuxgraphics/downloads/intel-graphics-instal...


Someone has to tell that to the xorg-edgers PPA maintainer


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.


Quick Reference: https://www.khronos.org/registry/vulkan/specs/1.0/refguide/V...

The Khronos site seems to be overloaded right now.


It will be interesting to see the adoption rate for games and other applications now that it has been released.


Too bad the sample code linked to from multiple locations is empty... only a README.md: https://github.com/KhronosGroup/Vulkan-Samples



[deleted]


Mac Support is coming: https://moltengl.com/metalvk/


This is not going to work on Raspberry Pi 2 at this stage. I could not see any drivers for it.


According to Eric Anholt (VC4 developer) RPi:

> This is not even slightly GL 3.1 hardware.

And Vulkan require 4.3 feature set.



Apparently the GeForce 800 series doesn't support Vulkan :(

https://developer.nvidia.com/vulkan-driver

Why is this so, any idea?


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.


on my laptop:

$ lspci | grep -i nvidia 03:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 840M] (rev a2)


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.


Here's a full list of conformant products:

https://www.khronos.org/conformance/adopters/conformant-prod...

I don't know why some dates are in the future..


They want you to buy new hardware ;)


So many teasered demos, but no video to look at...


Vulkan remains, and will only ever be, the Primarch of the Salamanders for me. Sorry, I guess my gamer culture overrides my tech nerd culture.


Where is Apple on that page?


I have dream to see such a master piece enabled on web browsers through javascript.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: