Vulkan: One API for all platforms

Share on linkedin
Share on twitter
Share on facebook
Share on reddit
Share on digg
Share on email

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?


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.


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.

Tile Based Deferred Architecture



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.


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.


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!

Platforms you may find Vulkan on

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.


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, @PowerVRInsider) for  the latest news and announcements from the PowerVR team.

If you want to learn more about Vulkan, register now for our five upcoming seminars:

* Possibly an exaggeration.

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

13 thoughts on “Vulkan: One API for all platforms”

  1. Vulkan should be compared to Mantle.
    Who is designing Vulkan? Game engine people.
    What is their main problem? Too many Shading Languages.
    What is their solution? SPIR-V.
    Vulkan is not going to be 90% of the game platforms.
    PC XBox games, XBOx, PS4, Mac, IOS.
    All the CAD people might as well move D312/Metal.
    Everything else is just comparison to 20 years old API.
    Guess what Vulkan is also C based. So much for progress.

    • Game engine developers are not the only ones designing Vulkan – though they are involved. We’ve also had input from OS vendors, web developers, certainly HW vendors and CAD developers amongst others.
      Android, SteamOS (as well as other Linux platforms) and Windows are all pegged to get Vulkan support, and all of these are very viable gaming platforms with large (or potentially large) market shares. The other OSs mentioned are all up and coming. Android alone has roughly the same market share as iOS, or possibly more according to some estimates. I do imagine that developers will be cross-developing DX12, Metal and Vulkan (plus whatever is on PS4) for at least the foreseeable future though. There’s plenty of middleware (gaming or otherwise) that will be able to abstract this, since these APIs all have similar design principles.
      Vulkan is C-based deliberately – simply so that it can be easily interoperated with other programming/scripting languages. It’s got an object-oriented design though, so a C++ wrapper is quite trivial to write (or even auto-generate, which one of our developers is actually doing internally). We’ve made a lot of modern design choices, paying careful attention to multithreading and CPU efficiency (see my next two posts). This is certainly not a C-API as you’d traditionally think of it.

  2. Can you confirm that iOS/Mac will be stuck with OpenGL 4.1 forever now? Their OpenGL is actually fine, but Metal departs from many conveniences of supporting libraries, and Apple keeps pushing it.

      • Lost… what, you better take that back and shove it up yours..
        Apple does what works, at least they used to before SJ passed. Now they are just clueless what’s next, and I am sure this WILL backfire soon.
        Also, their implementations are just someone else’s GPU designs copied (or stolen).

    • I’m afraid this is down to Apple, so I cannot confirm one way or another. They currently are pushing Metal as it is a more optimal API than OpenGL is, in a similar vein to Vulkan (Metal is still a higher level API than Vulkan, however).

        • Apple is a Khronos Promoter member. Unfortunately, I can’t really comment on specific Khronos member involvement – all I can say is that I’ve heard nothing that indicates whether they would (or would not) support Vulkan; and they’ve said nothing publicly.


Please leave a comment below

Comment policy: We love comments and appreciate the time that readers spend to share ideas and give feedback. However, all comments are manually moderated and those deemed to be spam or solely promotional will be deleted. We respect your privacy and will not publish your personal details.

Blog Contact

If you have any enquiries regarding any of our blog posts, please contact:

United Kingdom

[email protected]
Tel: +44 (0)1923 260 511

Search by Tag

Search by Author

Related blog articles

android background

The Android Invasion: Imagination GPU IP buddies up with Google-powered devices

Google Android continues to have the lion share of the mobile market, powering around 75% of all smartphones and tablets, making it the most used operating system in the world. Imagination’s PowerVR architecture-based IP and the Android OS are bedfellows, with a host of devices based on Android coming to market all the time. Here we list a few that have appeared in Q4 2020.

Read More »
bseries imgic technology

Back in the high-performance game

My first encounter with the PowerVR GPU was helping the then VideoLogic launch boards for Matrox in Europe. Not long after I joined the company, working on the rebrand to Imagination Technologies and promoting both our own VideoLogic-branded boards and those of our partners using ST’s Kyro processors. There were tens of board partners but only for one brief moment did we have two partners in the desktop space: NEC and ST.

Read More »
pvrtune complete

What is PVRTune Complete?

PVR Tune Complete highlights exactly what the application is doing at the GPU level, helping to identify any bottlenecks in the compute stage, the renderer, and the tiler.

Read More »


Sign up to receive the latest news and product updates from Imagination straight to your inbox.