On this website we describe the motivation, goals and results of our computer graphics practical supervised by Susanne Krömker. We compare the conceptual and programming specific differences between Vulkan and OpenGL which will become more apparent when we present our minimal OpenGL project in detail. Due to the nature of Vulkan we omit an in-depth explanation of our Vulkan application and instead show some notable examples of how OpenGL differs from it as well as where similarities arise.
When you are done with the technical stuff you can enjoy our demo scenes here.
While OpenGL is one of the most used APIs for rendering 2D and 3D vector graphics since 1992, the Khronos Group, who is also developing OpenGL, decided in 2015 to create a new API, called Vulkan, which should be the "next generation OpenGL initiative". Vulkan was announced to produce lower overhead then its predecessors and offer more direct control over the GPU .
We already worked with OpenGL before and were interested about the opportunities Vulkan has to offer. This leaded to us, doing this project, where we could get a first impression of Vulkan and compare it to OpenGL.
Our goals were to compare OpenGL and Vulkan in multiple areas. We wanted to check the performance from the two competitors, examine the programming experience while implementing code, and compare the visuals when drawing a similar scene.
To realize this we implemented two "minimal projects" first, one for OpenGL and one for Vulkan. As a "minimal project" we describe a project which creates a window and draws a simple triangle in it. With these projects we could compare the effort thats needed to create a working program between the two APIs.
Based on this "minimal projects" we implemented several exercises from "Computergrafik l", a lecture by Susanne Krömker and Computergraphics, a lecture by Filip Sadlo for both OpenGL and Vulkan.
When comparing OpenGL and Vulkan we primarily focused on the differences on encounters as users of the libraries. However, we did some simple performance measurements to find out if Vulkan really brings the performance improvements that were promised. For that, we compared two versions of the billboard forest scene. The first one consists of an instanced draw call where we increased the instance count gradually.
We observe that the frame time – the time it takes to acquire a swapchain image, render the scene and present it – increases linearly with instance count — which is expected. Contrary to our hopes, Vulkan takes around 30% more time.
Therefore, we crated an artifical case were Vulkan outperforms OpenGL. In the next scene we did not use instanced draw calls, instead we issued a draw call for every tree, leading to an overall poorer performance. We see that the maximum frame times are approximately the same, but that is already reached for one hundredth of the objects drawn. However, we clearly make out a huge difference between both candidates. OpenGL is extremely slower which can be explained by Vulkan's significantly lower driver overhead.
In conclusion, we can say that neither of the presented extreme cases represents a "normal" usage of either library. The real use cases might be somewhere in between. But we can definitely say, that Vulkan handles large numbers of driver interactions better.