This is the first in a series of blog posts that aims to discuss what was revealed at SIGGRAPH about Vulkan in a bit more depth. I won’t be revealing any new information – I’ll leave that to Khronos official announcements! What I will be doing however, is explaining the implications of what has been announced, and how that affects everyone up and down the chain of delivery – from us as IP vendors through device vendors and developers, all the way to consumers.

I’ll be taking a look at everything I talked about during the Khronos BoF at SIGGRAPH 2015 over this series, as well as touching on information that others may have spoken about. This week I’ll begin by talking about what it means for Vulkan to be one API designed for all platforms.

What does One API mean?

Vulkan is able to cover a wide range of platforms and hardware with vastly different form factors and power envelopes. Vulkan can run on a smart watch or a high end workstation, or anything in between. These platforms are going to have completely different capabilities and for good reason – they have different use cases in mind.

If the API was completely identical across all of these platforms, you wouldn’t be able to distinguish them, and you’d end up trying to run Maya on a smart watch – which doesn’t make a huge amount of sense. Now obviously Vulkan isn’t an Operating System, so you could argue that there’s other ways to distinguish a platform, but Vulkan still needs to distinguish the graphics hardware it’s running on top of in some way.

So there are going to be differences in implementations – so what are they, and what stays the same?

Consistencies

Coding to the API

The main point of Vulkan being one API is that you can link to the same library, with the same header and the same code on all targeted platforms. There is a path through the API that will draw triangles on the screen in the fashion you want, and you can use that path everywhere. There should be no need to deal with pre-processor defines embedded deep in your code to deal with the subtle differences between OpenGL and OpenGL ES, for instance.

Performance

As well as providing a consistent coding experience, you should get consistent performance. There are about a thousand* ways to do anything in OpenGL, and only one or two of them are fast on each vendor’s hardware – and which ones are fast often differs between vendors.

In Vulkan, we’ve trimmed the fat and there’s only a few ways to do anything. For every path that remains, it has been pored over by every member of Khronos, in order to make sure that it works for them and, more importantly, it works well. In fact for a lot of features the aim is to ensure that the fast path is the same for everyone – e.g. clearing via Render Pass load operations.

So for the most part you’ll be able to get very good performance from an application without having to resort to hardware-specific optimizations. There are undoubtedly still a few bits that some vendors may want you to avoid or use sparingly – but there should be a singular fast path that works everywhere. Vendor specific optimizations will still be relevant, but less so than OpenGL.

I’ll cover more about how Vulkan does this in a future post on being Architecture Positive.

Differences

Capabilities

There are certain pieces of functionality that draw a lot of power, take up a lot of area in a GPU, or are not universally supported for other reasons. These are not fundamental to creating a good graphics application, and are thus not necessarily present in all platforms – there’s still a core set of features you can rely on. For instance – you’re unlikely to see tessellation in a smart watch in the near future; and who actually needs it on a smart watch anyway**?

These optional features are captured as capability flags in the Vulkan API, each a bit that may or may not be present on the implementation. Each such feature must be queried and explicitly enabled at device creation in order to be used, so that you can’t use such features by mistake.

Limits

Even more fine grained than actual feature support, are limits on values that can be used or passed to the API. These are so that you know what the maximum amount of anisotropy you can use is, or how many uniform buffers can be referenced by a shader etc. Vulkan does guarantee minimum values for all of these, so that it’s possible for a developer to rely on consistent support here, whilst still allowing vendors to express additional capabilities.

Extensions

Despite the name not being particularly related, Vulkan has an OpenGL heritage, and is very much part of Khronos. One of the most successful features of OpenGL is the extension model. Whilst there are some shortcomings, extensions are very successful for prototyping new features and exposing interesting parts of various vendors’ hardware. Vulkan will expose extensions for exactly the same reasons. As with optional features, extensions need to be explicitly enabled at initialization time so they can’t be used accidentally.

Feature Sets

Whilst no feature sets exist today, we’ve committed to the idea of packaging up sets of functionality into well-defined chunks – making guarantees about feature support, the presence of extensions and various limits. The idea here is to be a useful guide to the sets of functionality that you might want to look for in a device. For instance, there may be a feature set defined for workstations used for CAD/CAM work which may include higher limits to denote extremely beefy, resource hungry desktop cards in the machine – and conversely there may be a slimmer profile to denote a power-efficient solution that gives excellent bang for your buck. Any feature sets defined by Khronos are intended to be used as a guide when designing or buying a product – more features does not mean better! For example, a workstation feature set in a phone would likely mean a power hungry device that approaches thermal limits quickly, which is usually not desirable!

There’s also scope for platform vendors to define their own feature sets, much like the Android Extension Pack for OpenGL ES 3.1. This allows them to differentiate, or provide a more consistent experience for their users if an existing feature set doesn’t quite match their needs, or they want to guarantee a selection of platform-specific extensions.

Platform Support

Vulkan is designed to run on any platform, but we specifically expect implementations to show up on Android™, Tizen™, many various flavours of Linux® (Ubuntu®, Red Hat® Enterpise Linux®, Steam® OS) and desktop versions of Windows® (courtesy of GPU vendors, rather than as a commitment from Microsoft). Google in particular have made very clear statements of support for Vulkan for Android, and it is pegged to become the core graphics API for that platform – though OpenGL ES is not going to disappear overnight!

Platform Integration

There are many different operating systems out there, each with their own unique way to do windowing, data input, video streaming and similar. In EGL, effectively all platform integration was part of the core API – covering parts of functionality that may or may not be supported on various platforms (e.g. Pixmaps).

The part of the Vulkan API that interacts with the outside world is self-contained as a set of extensions, rather than part of a Core API. The initial Window System Integration extension is much reduced compared to EGL, defining low level functionality that is the minimum needed to get an image on a screen, without trying too hard to abstract different platform constructs like displays, windows, contexts, etc.

This is therefore going to be different on each platform you choose to support in various ways, but it should be much better defined than it was with EGL. A good amount of detail about this can be found in Alon Or-bach’s talk at the SIGGRAPH 2015 BoF.

Conclusions

By not limiting itself to a subset of platforms, Vulkan has the potential to be a very widely adopted API. There’s already a lot of interest from platform vendors, developers and hardware vendors. This should mean a large market share can be achieved by application developers targeting this API, across both mobile and desktop devices. Equally, platforms supporting it are likely to benefit from a significant developer ecosystem around this API as it begins to build over time.

Vulkan is set to make a significant impact on the industry and in the next few blog posts I’ll discuss exactly why it’s such a big deal, and give some insight into why so many parties are interested in it.

Remember to also follow us on Twitter (@ImaginationTech) for  the latest news and announcements from the PowerVR team.

* Possibly an exaggeration.

** If you can actually come up with a sensible use case, let us know in the comments!