RenderingPipeline

from geometry to pixels

Some thoughts about the Vulkan API (glNext) and the future of OpenGL

Today the Khronos group announced officially the name of the new cross-plattform 2D/3D and compute API which will be (kind of) the successor of OpenGL. So far it was named “Next Generation OpenGL Initiative” or shorter: “glNext”, the official name will now be Vulkan (btw. the german name for Vulcano).

I read at some places, that it is “OpenGL 5.0” – but I think that this is far from being correct. The Vulkan API is not an improved version on OpenGL (as GL 3 was over GL 2.1) but a new start. It is not compatible with OpenGL. So far for OpenGL compatibility was a huge deal and functions from OpenGL 1.0 (we are talking 1992 here!) are still available in the latest OpenGL Compatibility profile.

Graphics hardware is quickly developing and can be programmed in a very flexible way today. The job of a modern graphics API is to allow the developers full access to this programmable processors in an efficient way. But before around 2001 there was no programmability at all and the graphics APIs job was to control a fixed function co-processor limited to implement some steps of the rendering pipeline. In fact, back in 1992 when OpenGL started out, there weren’t even 3D accelerated graphics cards for consumers at all! Keeping this in mind it is impressive that the same API was able to survive for 23 years just with added functionality but without breaking old code. OpenGL is not only cross-plattform on the PC, but variants also available on phones, game consoles (OpenGL ES) and even the web (WebGL).

In my opinion after such a long time it is time to have a fresh start, because OpenGL got at some placed more complicated and indirect than it could be – just to ensure not breaking any compatibility. It is also hard to parallel the rendering code onto multiple CPU threads, which wasn’t a big deal back in the days of single core CPUs… Not only could it be more pleasant to develop for (we will have to see how nice Vulkan API will be to program), it can also result in a better performance removing some of the layers between to application and the hardware. This also is a chance to add better debugging tools and functions.

As there is no compatibility between OpenGL and the Vulkan API, many large GL code bases will not switch immediately. But older applications will still want to access new hardware features, so I believe that OpenGL is not dead yet, but will in fact live on for some more versions. I’m confident that we will see new hardware features exposed in OpenGL 5.0 (maybe at Siggraph this year?). Just as NVIDIA, AMD and Intel didn’t drop the Compatibility profile even in the latest OpenGL versions, I don’t expect them to drop support for new OpenGL versions any time soon. I guess it’s actually more likely that we will quite some OpenGL extensions which expose more Vulkan like features in OpenGL to help transitioning (e.g. the Vulkan shader “binaries” SPIR-V). Limited compatibility in the other direction at least for the shaders is planned by providing a GLSL to SPIR-V compiler.

I can’t estimate how soon Apple will react to Vulkan. Will they drop Metal in favour of Vulkan on iOS? As Apple is developing the graphics drivers on their own (on iOS and MacOS), they will not want to support two APIs. On the other hand, a slimmer and closer to the metal (and closer to Metal) API will simplify the driver development. So when will Apple switch to Vulkan and not update their OpenGL versions? I expect them to switch sooner or later as Apple is part of the Khronos initiative that created Vulkan.

Vulkan API offers another nice opportunity for OpenGL developers: You can probably implement a full OpenGL stack on top of Vulkan. This offers a way to run OpenGL programs on systems that do not support (newer versions of) OpenGL and also provides a OpenGL stack that behaves the same on all systems (as you deploy it). A program can even at startup time choose between the OpenGL stack provided by the operating system and the one it provides itself in a library based on Vulkan.

 

Here is a list of links to more infos about the Vulkan API.

, , , , , , , ,

13 thoughts on “Some thoughts about the Vulkan API (glNext) and the future of OpenGL
  • For a while I thought that Apple could release a Metal 2.0 to support desktop GPUs and use it on desktop.

    Now, I think that this would be a massively more complex task than doing Metal 1.0 on iOS because on iOS they only support a single architecture and Metal kind of map to this architecture.

    On desktop, it will be impossible for them to do the same because Intel IGPs makes great sense on laptop but these GPUs are too low performance / efficiency for desktop performance. PowerVR on desktop? Maybe one day but it’s not really.

    Considering the huge amount of efforts it took for Vulkan to build a design that would be efficient, cross platform, I think it would be nearly impossible for Apple to figure all this by itself and Vulkan might be better option for them.

    Wishful thinking? maybe!

    • Robert says:

      Yes, Metal is implicitly meant to work with shared memory architectures which only maps to Intel on Desktops currently. It would not be possible to use it unaltered for MacOS X. But I also hope that Apple will support Vulkan sooner than later – maybe with the late 2016 release of MacOS 10.12?

      • brianj says:

        When concerning Apple, a late 2016 release seems highly likely, and that is just very disappointing. And we’re assuming they’ll have Vulkan support in Mac OS. We have nothing to go on other than their logo as part of the API working group. They haven’t made an official statement. Being kept in the dark about this really sucks.

  • dr.no says:

    Apple is not going to drop Metal as it is doing custom GPUs.
    Apple may support SPIR-V if it came with LLVM compiler but not much else.
    It may even back away from OpenCL especially in mobile environment.

    For Apple 70% computers sold are Laptops which means Intel GPU.
    Apple asked Intel for Iris Pro GPU for a reason. Just like it asked for OpenCL compatibility.
    Now even OpenCL is too hard so new solution like Swift is needed.
    Latest Swift 1.2 is close to C++ speed.

    Metal has to expand to cover Swift and also SceneKit, SpriteKit, CoreAnimation, Quartz.

    iMac 5K has laptop GPU that everyone cries about. No one is playing games on it.

    Will CAD manufacturers support Vulkan then Apple may be forced otherwise don’t bet a dollar.

    • Robert says:

      A few notes: Some Apple notebooks have also a dedicated GPU.
      I’m not sure why you compare Swift to OpenCL as the one is a programming language and the other a compute API – maybe I didn’t get your point?
      Sure, SceneKit, SpriteKit etc. rendering can be done on top of Metal, but also on top of Vulkan or OpenGL ES.

      • dr.no says:

        Metal Shading language is currently C++11,
        while the API is Objective-C.

        Apple has ambition to get rid of C, C++ and Obj-C for all new developers.

        If API is changed to Swift then Shading language doesn’t match with c++ unless it goes thru Objective-C wrappers.

        Plus Swift matches better matrix and vector math in Swift then going back to C.

        You guys cannot provide a technical reason for Apple to adopt C based API
        for high level graphics when Swift is the future.

      • dr.no says:

        OpenCL is C API is too low level for most programmers.
        People have complained about OpenCL that Apple has implemented
        or lack of support for things like Debuggers.
        Apple is no longer involved even in writing the Spec for OpenCL 2.1

        Metal is new thinking which is higher level API.
        Swift is just the new king to rule the world.

        discrete GPU are dinosaurs. It is there is high end laptops for FCPX
        not games.

        SceneKit, SpriteKit are Obj-C API first and foremost.
        Apple is not going to wait another year for some Spec.
        The political gamesmanship that Khronos is famous for may have put Apple off. It no longer need to take any tech to them for some kind of blessing.
        OpenCL experience may be too bitter for them.
        That is the main problem.

  • Alex says:

    Do you think that Vulkan will become a first entry level API for novice computer graphics programmers?

    • Robert says:

      Hello Alex,

      if you are serious about graphics programming, then yes. The alternatives would be DirectX12 or Metal which are on the same level of complexity. DX10, DX11 and OpenGL will phase out and require the same level of insight into the inner workings of GPUs if you want to build efficient applications.
      However, for absolute beginners I guess that we will see quite some libraries that will make the first steps simpler by hiding some of the inner complexity. IMHO this would be a better start than using a simpler API as at some point you can just read the libs code and dive deeper into the topic and adjust the libs to your needs (or write similar wrappers of low-level functions).
      An alternative for graphics programming without going so deep into the details would be higher level libraries which build on DX12, Vulkan, OpenGL or whatever, something like Apples SceneKit.
      So it kind of depends on whether you want to learn all the low-level details or not.

      • Alex says:

        Hi Robert,
        thank you for your reply. As teacher of a computer graphics course for undergraduate students i think that the first steps should be more simpler. Many times in a classroom there are different skills and different point of view about how develop 3D apps. I am thinking to a library such as three.js that my students had appreciate a lot respect to OpenGL.

        • Robert says:

          I also teach CG classes at a university. Currently we do that based on OpenGL Core profile, and before we could switch to Vulkan, it should be supported by a larger number of GPUs (students should be able to solve the homework on there own machines and not just in the lab).
          We currently provide a few helping C++ classes to get started, e.g. for shader loading and error checking as well as simple 3D model and texture loading. I guess with some provided code a switch to Vulkan should be possible in the future even for the beginner classes (judging from my experiences with Metal) – but I would have to test this out once we get the first Vulkan drivers first. Also I would not expect a switch within the near future.

          If you try out using Vulkan in classes, please contact me and share your experiences!

  • Lex Barringer says:

    What I need to explain to you is that. The Khronos Vulkan API is an open source descendant of the AMD Mantle proprietary API. It is not OpenGL in any shape or form.

    OpenGL has been a mess ever since Khronos decided to allow implementers to add custom extensions to the OpenGL library and the use of core profiles instead of full compatibility profiles.

    Each manufacturer and people who implement the API and support library per operating system / distribution (if Linux) decides what they will support and what they won’t. That’s the wrong way to go about it.

    Essentially, OpenGL 4.x is a horrendous mess, every point release they would change and obsolete previous API until they hit OpenGL 4.5. Even the core profiles (the most commonly used library commands) change from every point release above 4.0. OpenGL 4.2 to 4.4 was the worst, so many changes to the API in a short period of time caused chaos in implementation.

    What Khronos is hoping for is to move forward with Vulkan API with a clean slate, however, they’re screwing this up, too. They already have Compatibility (full version of the library) and Core profiles. They need to stop that immediately. Only Compatibility profiles should exist. They’re allowing custom library command from the different manufacturers again, big mistake, it’s just being to be another clusterf*ck, if they keep this up.

    A truly neutral graphics library API is necessary for all platforms it will be implemented on. Otherwise, there will be a lot of infighting and not a lot of progress being made.

    • Robert says:

      I disagree. OpenGL does offer multiple ways of doing the same thing because it is an old API and newer methods and ways were added without deprecating older ones (only a strict Core profile is actually removing functionality and only one implementer is forcing you to use Core (Apple) if you want new features). Extensions are a good way of exposing new hardware features and allowing app developers to use cutting edge features before everyone supports them and they can become core. The same is done in Vulkan which is IMHO a good way.

Leave a Reply

Your email address will not be published. Required fields are marked *

*