Vulkan vs OpenGL – part 1

vulkan card

From the point of view of the developers making multiplatform applications using graphics acceleration, the year 2016 was definitely breakthrough. The new graphical APIs undoubtedly does not come out very often, and when it come out, it may stay with us for a decades. And just in early 2016, the final specification of API Vulkan 1.0 API was finished, and the new API is slowly seeping into ordinary, stable versions of graphics drivers. Finally, every ordinary users will be able to get hands on it. Since Vulkan will definitely have a important role in upcoming world of various AR/VR (and of course, multiplatform gaming), I would like to devote it at least two posts. As a person who grew up with OpenGL, I’m going to focus at the comparison of both interfaces and the description of what the moving to Vulkan actually means for the OpenGL developer.

What is the Vulkan?

A quick introduction to accidental passersby will never hurt. Vulkan is the first independent, multiplatform, low-level graphics API, aspiring to be a successor of the legendary OpenGL. It is a kind of guide describing how your application and graphic driver communicate together. Vulkan API is open-standard – just like OpenGL and therefore is freely available for implementation in to your projects (Vulkan or OpenGL are not an open source, it’s really just a “guide,” Vulkan implementation in drivers is usually proprietary and closed). It can be likened with DirectX12, but usage of DirectX12 is limited to a single version of a single operating system.

From user’s point of view, the new API will bring mainly higher performance, i.e. the possibility of higher FPS or higher quality of rendering while preserving the FPS. Of course, everything only in case of support from graphic hardware and from the running application. Much more interesting and key changes are of course taking place under the hood of the API.

The advantages of the Vulcan compared to OpenGL could be summarized as:

  • It is a low-level API. The API reduces the level of abstraction and thus gives more freedom in performing optimizations to the final application.
  • Adds native support for CPU multi-threading.
  • It brings a new intermediate language for shaders – SPIR-V.
  • Eliminates obsolete concepts of handling the GPU.
  • Unifies the desktop API (OpenGL) and its stripped-down version for mobile platforms (OpenGL ES).

It also brings some disadvantages:

  • Increases the complexity of the end application (entry barrier), transfers a higher responsibility to the end application.
  • It is not compatible with Apple platforms.

The motivation for Vulkan

Someone may now think – OK, Vulkan is an effective, low-level and low-overhead. But why was not the low-level and low-overhead already the original OpenGL? At first glance, it seems ironical that programming languages started at the low-level and now are running for more and more abstraction, while the graphic APIs are evolving quite opposite direction.

The first version of OpenGL was established in 1992. That means pretty long time ago, especially in computer technology scale. By that time most of consumer graphics cards did not yet have 3D acceleration (often not even 2D acceleration), the real-time 3D rendering was the prerogative of graphical workstations and still was very immature. Later, the 3D accelerators became common and the market was flooded with the first cards with a fixed “hard-wired” 3D redering process – so called Fixed Function Pipeline. There was a lot of manufacturers and the rendering pipeline was taking many various forms, often quite exotic. OpenGL had to satisfy all devices and reliably convert jungle of different hardware solutions to a single general API for every programmer (at the same time CPU programmers were already enjoying a unified X86).

Later the rendering pipeline went into the second phase – some of its parts began to be programmable and the Shaders came on the scene. Further development moved the architecture of the rendering pipeline towards even more universal and general approach – the Unified shaders. The graphics card architecture become somewhat unified and also number of manufacturers has considerably dropped – in the desktop world practically to 3. OpenGL has undergone a lot of changes in the meantime, but it was still burdened by a lot of quite outdated approaches and a lot of legacy calls already had to be emulated internally using Shaders. OpenGL also lacked support for multi-core CPUs. Although multi-thread rendering with OpenGL is possible, it requires switching the OpenGL context and can not actually perform multiple draw calls in parallel.

Graphics card manufacturers have been trying to break out from too abstract APIs from the very beginning and to deploy their own low-level API wherever possible (where API versatility was not needed). Consoles and arcade game machines were having special interfaces as PSGL, GNM or Glide and were usually able to achieve significantly better performance than PCs with similar hardware. The same motivation also brought AMD to release their own API – the API Mantle. But just releasing of the another proprietary API does not solve the problem. If new APIs is supposed to be accepted by developers, it must be ideally adopted by all major GPU manufacturers. Mantle was therefore donated to an independent third party – the Khronos consortium, and on its foundations Vulkan API was created. The first universally accepted low-level graphics API.

Support of the Vulkan

Vulkan is not a new iteration of an existing graphical API, it is just doing same things with better ways. Therefore new graphics hardware is not necessarily required. Graphics cards supporting OpenGL 4.x or OpenGL ES 3.1. are sufficient for Vulkan.

Support for Vulkan is of course also required in the graphics card driver and it is completely up to GPU manufacturer if the support will be added for certain card or not. Now, at the turn of 2016 and 2017, we have Vulkan for AMD and nVidia graphics cards. Intel graphics chips are having beta version of drivers with Vulkan support. Intel is however ahead with Vulkan support for open-souce Mesa 3D GPU driver. Intel is currently only GPU supported. (Edit: Stable support for Intel graphics chips added from version Windows supports Vulkan from W7, Android adds Vulcan support from version 7.0 – Nougat. Current mobile ARM based chipsets should already be ready for Vulkan. Apple unfortunately does not plan the support – they are promoting their own low-level API Metal. However, there are already projects designed to enable Vulcan on top of the Metal API – for example MoltenVK . Vulcan can therefore be considered as a very multiplatform API.

So much for the short general introduction. Next time it will be more about the developer’s point of view – threads, command buffers, and SPIR-V.

Be the first to comment

Leave a Reply

Your email address will not be published.