Vulkan: One Year Later

Manufacturer: PC Perspective

Living Long and Prospering

The open fork of AMD’s Mantle, the Vulkan API, was released exactly a year ago with, as we reported, a hard launch. This meant public, but not main-branch drivers for developers, a few public SDKs, a proof-of-concept patch for The Talos Principle, and, of course, the ratified specification. This sets up the API to find success right out of the gate, and we can now look back over the year since.

View Full Size

Thor's hammer, or a tempest in a teapot?

The elephant in the room is DOOM. This game has successfully integrated the API and it uses many of its more interesting features, like asynchronous compute. Because the API is designed in a sort-of “make a command, drop it on a list” paradigm, the driver is able to select commands based on priority and available resources. AMD’s products got a significant performance boost, relative to OpenGL, catapulting their Fury X GPU up to the enthusiast level that its theoretical performance suggested.

Mobile developers have been picking up the API, too. Google, who is known for banishing OpenCL from their Nexus line and challenging OpenGL ES with their Android Extension Pack (later integrated into OpenGL ES with version 3.2), has strongly backed Vulkan. The API was integrated as a core feature of Android 7.0.

On the engine and middleware side of things, Vulkan is currently “ready for shipping games” as of Unreal Engine 4.14. It is also included in Unity 5.6 Beta, which is expected for full release in March. Frameworks for emulators are also integrating Vulkan, often just to say they did, but sometimes to emulate the quirks of these system’s offbeat graphics co-processors. Many other engines, from Source 2 to Torque 3D, have also announced or added Vulkan support.

Finally, for the API itself, The Khronos Group announced (pg 22 from SIGGRAPH 2016) areas that they are actively working on. The top feature is “better” multi-GPU support. While Vulkan, like OpenCL, allows developers to enumerate all graphics devices and target them, individually, with work, it doesn’t have certain mechanisms, like being able to directly ingest output from one GPU into another. They haven’t announced a timeline for this.

February 16, 2017 | 11:38 PM - Posted by Anonymous (not verified)

That why Nvidia updating their OpneCL drivers support... for next unreal engine vulkan games to be better than AMD :)))

February 17, 2017 | 12:14 AM - Posted by Scott Michaud

Eh... there's some cross-over, like the SPIR ingestor and command-list model, but they're different APIs. I'd expect OpenCL 2.0's for the supercomputing market, personally. I could be wrong, though.

February 17, 2017 | 07:13 AM - Posted by Titan_Y (not verified)

They are different APIs. Some random Nvidia fanboy pulling stuff out of his arse to make it look like this is all going to benefit his beloved company, hoping readers don't understand that what he wrote is completely nonsensical.

February 17, 2017 | 12:28 AM - Posted by Anonymous (not verified)

Vulkan is soon coming to Ashes of the Singularity so it will be interesting to compare it's performance to dx12 directly.

It will likely miss the mgpu support so I doubt I can change apis but single card will be interesting.

February 17, 2017 | 01:05 AM - Posted by Anonymous (not verified)

Happy birthday Vulkan, Live Long And Prosper! BUT if windows Vulkan support is only limited to windows 10 then it looks like Linux/Vulkan will be the only option come 2020.

I hope AMD remembers that Linux support is not only important for servers it's very important for some desktop/gaming/other uses after 2020 for those that will be needing Linux on the their PCs/Laptops and their choice of OS that the users themselves control.

Ryzen is going to be great for home users needing those affordable 8 core SKUs for running windows 7 locked down in its own Linux based hypervisor VM/OS instance after 2020. The more cores the better for running multiple OSs at the same time in their own hypervisor managed(Linux Kernel Based) VM/OS environment/instance.

February 17, 2017 | 05:06 AM - Posted by BillDStrong

Windows Vulkan supports Win 7 and up from the Hardware Vendors. Nothing in the Spec prevents it from working Win 2000 and later.

February 17, 2017 | 07:46 AM - Posted by Scott Michaud

They're saying after 2020, when Windows 7's extended support expires.

I'm not really sure what they're hoping Vulkan will move to, though. It sounds like the other OS they're alluding to is macOS. I'm not really sure what that would accomplish, though.

February 17, 2017 | 04:33 PM - Posted by Anonymous (not verified)

No they are not, and yes you are very afraid of even discussing Vulkan on windows 7 or 8.1 for fear of offending M$! The only reason for using 7 after 2020 is for legacy usage of any applications that will not be supported on Linux after 7's EOL. And that after 2020 usage referred to is only for windows 7 safely locked down in a Linux Kernel based Hypervisor managed VM/OS instance. So where is any news or benchmarks for Vulkan under windows 7 or 8.1. M$ appears to not be wanting that to happen or any reporting done if someone has in fact gotten Vulkan up and running under windows 7 or 8.1. The M$ Fix is in to only discuss Vulkan under windows 10 and who wants forced windows 10 usage under Vulkan any more than the forced windows 10 usage under DX12.

They want Vulkan under windows 7 and 8.1 now and even after 2020 for those legacy application uses. Having actual running Vulkan under windows 7 or 8.1 would be great to allow better gaming for those that will be using their current ->NON windows 10<- windows OSs until their EOL. Also Some CPU/SOC hardware makers are trying to use limited Vulkan support to intentionally obsolete older hardware that could support Vulkan just to get more hardware sales.

Linux is going to be very important the closer it gets to 2020 for more tan a few who do not want to be pushed beyond the garden gates of any closed OS/Hardware ecosystem. I’d like to see a RADV(Open Source Vulkan implementation) like project for windows 7 and 8.1 to bring Vulkan to windows versions other than windows 10, but hopefully the Linux gaming ecosystem will be able to by 2020 to make that unnecessary.

February 17, 2017 | 05:45 PM - Posted by pessimistic_observer (not verified)

The day linux outside of android becomes important in consumer gaming is the day consumers stop buying full computers. I guess that days is now then ;}

February 17, 2017 | 07:59 PM - Posted by Anonymous (not verified)

It's bad for Vulkan also as even at GDC there will be not be much AMD discussion of any VULKAN explicit GPU multi-adaptor in games usage but there will be for DX12 and Explicit GPU Multi-adaptor. I'd rather they not talk about only Vulkan's one year birthday and keep up with Vulkan's developments like Explicit multi-GPU adaptor support. Such as asking games developers and the Khronos Group the status of Vulkan's Explicit GPU Multi-adaptor support. will that full support have to wait for Vulkan/Next or is Khronos working to get that support fully implemented currently. AMD's presentations do have some Vulkan usage discussions planned.

Vulkan will have that larger Mobile market usage for sure, and desktop Linux may not have much of a market share but Desktop Linux only need a small amount of the total PC/Laptop market share to survive. Valve is sill going to be hedging its bets with its Steam OS distro as will many of the games developers that do not want M$ to ever be in a position to cut them out of the loop. Desktop Linux support is an Insurance Policy against Redmond's historical OS market nefariousness! There are still billions of PCs/Laptops out there, new and used, that will be useful beyond 2020 running a Linux Distro so only a small percentage can add up to millions of users.

As far as windows 2023 is windows 8.1’s EOL and with the proper 3rd party software windows 8 can be made tolerable for some windows 7 users while allowing them to avoid windows 10 even longer if necessary. So a lot more Linux Gaming support can evolve in 7 years. Windows 7 can still be used productively locked down in a Linux Kernel based Hypervisor VM/OS instance and run safely from there in an isolated manner.

February 19, 2017 | 11:30 PM - Posted by Scott Michaud

Wait, what? You think I'm afraid of offending Microsoft?

February 17, 2017 | 01:30 PM - Posted by gamerk2 (not verified)

"AMD’s products got a significant performance boost, relative to OpenGL, catapulting their Fury X GPU up to the enthusiast level that its theoretical performance suggested."

It's worth noting the AMD/ATI OpenGL driver path has been in disrepair for decades; anyone remember the X1950 versus the 6800 GTX in Doom 3?

Mobile will use it as it replaces OpenGL-ES. Windows will not, for the same reasons OpenGL on Windows is a rarity: Performance. A tightly integrated API will always outperform.

February 17, 2017 | 08:17 PM - Posted by Anonymous Nvidia User (not verified)

Happy birthday Vulkan. Keep up the smashing success. After all Rome wasn't built in a day. 4 whole games in a year.

The Talos Principle – The first game with Vulkan rendering support.
Dota 2 – Vulkan support released in May 2016.
Doom – Vulkan support released in July 2016. [42]
vkQuake – A Vulkan Quake port was released in July 2016.

And people are trashing on Nintendo Switch for only having around 80 planned for a year. Hypocrites. Or just haters because there's a green iGPU in it.

Here's a clue Vulkan. Get your drivers fixed for Pascal asynchronous compute if you haven't done it already. Might just help speed up the adoption rate getting the #1 market leader for dgpus on your side.

February 19, 2017 | 08:52 PM - Posted by Anonymous (not verified)

You do know that nVidia is the one responsible for Vulkan drivers for Pascal, right? Not "Vulkan" or the Khronos Group.

February 20, 2017 | 01:13 AM - Posted by Anonymous (not verified)

Don't let reality get in the way... XD

February 20, 2017 | 03:43 PM - Posted by Anonymous Nvidia User (not verified)

It has to be coded by both sides for it to work. Hint that's why asynchronous for Pascal will probably never be supported in a Gaming Evilved game.

Timespy and Gears of War 4 have working asynchronous compute for Pascal because they support it in their applications. See how that works.

Vulkan even said that they were working on an update for the Nvidia cards back when Doom was new.

My view of reality is intact. You must live oblivious to everything unless you're spoon-fed it.

February 20, 2017 | 11:58 PM - Posted by Scott Michaud


The Khronos Group doesn't publish software; they publish specifications. Do you mean id Software?

Also, asynchronous compute is a bit of an umbrella. Depending on how the GPU is designed, certain parts of async compute will have more benefit than others, which will also depend upon what the game needs. For instance, IIRC, NVIDIA was first out of the gate with asynchronous compute/memory access ("concurrent copy and execution") back in the GeForce 8 days. As far as we can tell, AMD's architecture is still better able to overlap graphics and compute tasks than Pascal, and that has nothing to do with "Gaming Evolved".

It's kind-of like when people assumed Crysis 2 was artificially harming AMD cards because there was an ocean under the level that stressed tessellation units, which NVIDIA had better capacity for. It now seems that, because of some design decisions that Crytek hard-coded in, the engine couldn't not have an ocean in every level... and even Amazon, after forking the whole engine, still has that constraint (even though it's not rendered unless you can see it now, so there's no performance concern anymore -- but it wouldn't surprise me if that optimization wasn't able to make it into Crysis 2 for completely benign, mundane reasons that had nothing to do with NVIDIA).

(See: "Remove Ocean")

And yes, this probably means that, when playing Star Citizen, there should be a space-ocean within a couple hundred kilometers of you at all times.

Note that this is just my interpretation of things based on work I've done in the past. I don't have official statements backing this up.

February 21, 2017 | 09:04 PM - Posted by Anonymous Nvidia User (not verified)

Scott. Yes Bethesda said they were working on it. You are right about Khronos only publishing specifications. Maybe from the original article I read it wasn't written very clearly or my recall might be the culprit. Thanks for clearing that up about Vulkan.

Maybe to be fair maybe the engines used in most AMD titles are old and need updated to take advantage of asynchronous for Pascal.

The crysis 2 tessellated ocean myth has been debunked but was not widely publicized as the scandal. AMD users can play the game with zero Tess as they have a slider in CCC don't they.

Not like AMD acquiring Warhammer Total War for evolved two months before release. Why is there no investigation? They just changed things to suit the AMD cards better right?

Here a link for the dx12 patch performance.

It does everything you'd expect. Nerfs Nvidia performance but AMD sees large gain.

Nvidia shouldn't lose performance ever. There must be something coded into dx12 that hampers Nvidia's performance then. Why does it always seem to be an evolved game when this happens.

On Nvidia's gameworks dx12 Nvidia don't lose performance; not much benefit for sure but AMD doesn't lose you see. In fact they still have large gains.

I enjoyed Warhammer games in the past but I vote with my wallet. If a game doesn't perform well on my card it doesn't get a sale from me. Maybe when it's in $10 bargin bin I might consider it.

So far I haven't bought an AMD Evolved title and won't be playing on dx12 unless dx11 isn't supported and my win 8.1 is no longer supported.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote><p><br>
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.