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.

Tile Based Deferred Architecture

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!

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.

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 (@ImaginationPR, @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!

Comments

  • Chris Hunter

    Well This is a total win for AMD.

    • Tobias Hector

      It’s a total win for everyone – at least in theory. It’s certainly a big win for us. Vulkan may have Mantle at its roots but it’s been haggled over for a year and a half to make it work for everyone. My next few talks (http://blog.imgtec.com/powervr/5-new-webinars-on-the-vulkan-api) – particularly the last one – should drive home why Vulkan is great for us.

  • Patrick Gina

    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.

    • dr.no

      are you lost or something?
      Apple decides what goes in their platform.
      Not GPU designer.

      • Patrick Gina

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

        • nega gina

          stfu iGina, you all don’t even know what a gpu is.

    • Tobias Hector

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

      • Patrick Gina

        Ok, but wasn’t Apple participating in Vulkan spec development? What happened there?

        • Tobias Hector

          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.

        • nega gina

          apple is participating in your ass, f’n fanboy.

    • nega gina

      what?!?! iGina how dare you!

  • deranger

    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.

    • Tobias Hector

      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.