Although I’m in danger of repeating myself a little, there’s a lot of excitement in the air for Microsoft’s DirectX 12 and for good reason too. The new API has a lot of benefits over the old guard (DX11), including far greater multi-threading support, increased draw calls, large performance improvements and also improved compute support – in short, great news for both developers and gamer’s. But the API is pretty much tied to a specific platform – and that is where Kronos groups (the folks behind the OpenGL standard) Vulkan API comes in, a natural evolution of both Mantle and OpenGl.
Developers currently face many challenges if they’re targeting releasing their software across multiple platforms (even say Linux and Windows, which are two desktop platforms running the same hardware, let alone mobile and desktop) and this is where Vulkan comes in. It’s been designed from the ground-up to handle both the graphics and compute tasks on a wide variety of devices, including desktops and laptops, but also phones and even consoles (should they embrace the standard). The industry has known that OpenGL needed a reboot, and when one considers OpenGL dates back twenty-two years, it’s of little surprise Khronos decided it was best to wipe the slate clean and build anew.
If you cast your mind back when AMD first announced their Mantle API you’ll recall a mixture of both skepticism, excitement and perhaps even a little hostility at their decision to release their own API. Veteran gamer’s and developers perhaps remember the days of Glide, the proprietry API from 3DFX (the company behind the Voodoo chipset who went bankrupt in 2002 and their intellectual property was gobbled up by rival Nvidia,) Glide led to a lot of frustration from non Voodoo owners (requiring wrappers, or native but poorly optimized DX or OpenGL renderers), and in a modern development environment, how much support would AMD really get for an API which would only be applicable for less than half of PC gamer’s (if you take Nvidia and Intel’s GPU’s into account)?
Well, as it turns out – AMD’s work probably kick-started the move to lower level API’s for the PC. While there has been a lot of speculation and rumors regarding how much Microsoft’s DX12 benefited from AMD’s work, Vulkan are completely blunt – it isn’t just ‘based’ on Mantle, it’s supposed to its successor. It builds on Mantle’s low level characteristics – low abstraction, high control and a push towards compute (with some changes, which we’ll get into in just a moment). So from June to August the Vulkan project officially got underway, and immediately received a huge (unprecedented) amount of industry support from platform vendors, GPU vendors, game engine developers and software developers.
DirectX 11 (and previous versions) certainly had their faults, but they were also a familiar friend to developers – the abstraction made them fairly easy to work with (across a wide variety of hardware on the largest OS base). Vulkan is still in development (so some ‘parts’ of the API’s design are fluctuating) but Khronos are designing the API to work in a similar manner to both DirectX 12 and Mantle.
So, we’re clear that Vulkan is an ‘evolution’ of sorts for Mantle, so how much of the API has actually changed and what’s been made different? Well, think of Mantle as the bootstrap process and Khronos refined what they felt worked for their vision and goals and thrown out the rest (so, HLSL was one such thing which didn’t survive, and anything that was specific to the GCN architecture – because that would go against the point of the API).
Naturally the GPU not only works across different vendors (so Nvidia, AMD and others in the mobile market… for example) both also will happily handle multiple discrete GPU’s which are present in a single system. The GPU’s are able to support resource sharing too – what this means is that if you’re planning on crossfiring or SLIing a couple of GPU’s in the same system, Vulkan will handle the GPUs perfectly, and with lower overhead than current traditional APIs manage too.
The thinner abstraction layer also should reduce the overhead (and size) of drivers, which is a major positive in the mobile market. Developers are also pointing out that we should see better quality drivers too. Vulkan also has no runtime error validation, which is something which crept into D3D more and more as the versions progressed. Back ‘in the day’ when video card drivers were lower level there were very little usage hints and if incorrect formats were being used the driver would try and fix the issues the best it could. While that sounds great, it also gobbles up a lot of performance and also leads to a lot less flexibility – and ensures you’ve got to setup a lot of resources early on.
There’ll be robust tools to help developers… errr… develop code and applications for the API, but there will be a lot more burden on them. Because they’re operating at a lower level there’s also greater scope for an “oops”. For example, synchronization between the GPU and CPU (ensuring that they’re both working on the right data… it basically ensures that the job has been finished before further commands are being issued) is left in the hands of programmers rather than an API
Naturally, multi-threading is also high on the list of Vulkan’s selling points, the multiple threads on the CPU can construct multiple command buffers – all in parallel. In other words, if you’ve got 4 CPU cores (for example – it’ll scale based on the CPU in question) you won’t have DX11’s one core at a time approach. As we’ve discussed in our 3DMark API overhead testing, DX11 is a serial API, and while it can technically handle parallel draw calls (for example) it does so in such a poor way that the performance is often the same or even lower than a single thread.
It’ll be interesting how Vulkan dears with Asynchronous Shaders too, considering the rather beefy performance claims AMD are making of their hardware in comparison to that of Nvidia. As we saw in our analysis, it’s clear that asynch shaders are going to be a ‘thing’ AMD are pushing.
Vulkan support Explicit GPU control, so much like Mantle and D3D12 the developers have to be a little more careful with what they’re doing. The application (and therefore the developers who’d programmed it) are responsible for both the memory management and also the command buffers too,
During the GDC 2015 presentation, Oxide Games point out that GPUs are growing in speed much quicker than CPUs, and that CPU performance is really growing thanks to a higher core count rather than faster performance per core. Back in the late 90’s to early 2000’s – the MHZ race, this wasn’t so much the case, with major increases in both CPU clock speed and also IPC (Instructions Per Clock) performance too. Look at benchmarks of the Pentium 2 to Pentium 3 performance jump (450MHZ) and you’ll see what we mean.
Now this isn’t so much the case, while there are small improvements in performance on a clock for clock basis (Sandy bridge to Ivy bridge for instance) as the graph below demonstrates. CPU performance now heavily requires multi-threading (for a variety of reasons…) and thus the importance of software actually using multiple cores is crucial.
Vulkan is a layered API, the bottom layer is the driver (that’s kinda needed to do anything as you can imagine) and at the very top of the layered stack is the application itself. There are also other layers, for example: the Loader, Validation and RefCounter which are optional and can be enabled or disabled at the request of the developer. This is important, because if a layer is disabled it doesn’t effect performance – so for instance, if you’re not running Validation you won’t find it eating up RAM or CPU performance.
Third party software can also ‘inject’ its own layer too – an example would be say a frame rate counter, or if you were running the steam overlay. In other words, it’s not something that the game (for example) itself asked for the API to do, but a third party software requested it to be included. We’ll be taking a look at the layers when we look deeper into the inner workings (and compute) side of Vulkan over the next few days.
So, what does all of this mean? Well, firstly in terms of industry support – they’ve got a lot. From the console point of things things are a little trickier, android and SteamOS based systems are a certainty, but Microsoft and Sony are less set in stone. The PS4’s API is still lower level than either DX12 or Vulkan, and so it probably won’t benefit Sony to use it as a ‘main’ API, or for developers to embrace it if they’re looking for the best performance possible. But let’s say you’re a smaller indie studio (you’ve developed something like say Limbo) and you’ve developed the game on SteamOS and want to easily port it to Sony’s machine if it did support Vulkan you’d more easily be able to do so. If Linux and that ecosystem of games becomes large enough, it would certainly be a tempting move for Sony to embrace the API on their console. For reference, they are actually contributing to the Vulkan Project, but likely their primary concern is smart devices.
From the PC point of view, especially Linux, things are quite interesting – they (Khronos) have a lot of industry support for games developers, not least of all Valve, who’ve confirmed that their Source 2 engine will natively support Vulkan. The main problem with Linux gaming has been quite simply developers aren’t too willing to write code for a smaller portion of sales, and while it’s certainly true Linux versions of games exists, the market is smaller. If Linux could be pushed into a larger ‘bucket’ of other platforms, the chances of more Linux games is obviously increased.
Developers such as Frostbite (and EA as a whole), Oculus VR, Blizzard, Oxide, Unity, Apple and even Lucas have all jumped on the Vulkan bandwagon too. How it will compete in the Windows desktop (or laptop) space when DX12 remains to be seen – from a gamer’s (and IT press) point of view, I’d prefer the better performing API to ‘win’. But then DX12 does have some benefits too – including easy porting of Xbox One titles.
That’s all for now folks – as you’d expect we’ll be delving into the more technical aspects of the API over the next few days and going into performance, memory management, compute and all of the other shiny bits and bobs that you’d expect. Hopefully you’ll join us then, and if you could share the article with your friends we’d greatly appreciate it!
