Vulkan versus OpenGL

Here are the features/improvements in Vulkan that give it an edge over OpenGL:

• Reduced driver overhead and CPU usage: Vulkan is designed to be closer to the underlying graphics hardware. Therefore, it provides an application programmer with direct control over computing resources on the host in order to allow the GPU to render as fast as possible. This also allows the software to directly access the graphics processor, allowing better performance.
• Multithread scalability: Multithread scaling is really poor in OpenGL, and it is very difficult to take advantage of the threading features to better utilize the CPU. However, Vulkan is specially designed to allow end users to fully exploit its multithreading capability in a very transparent manner with no implicit global states. Jobs under different threads remain separated from the moment they are created and submitted for execution.
• An explicit API: OpenGL is an implicit API, where resource management is the driver's responsibility. The driver takes application hints and tracks resources, which is an unnecessary overhead.
  • Vulkan is an explicit API; here, the driver is not responsible for tracking resources and their relationships. This task is assigned to the application. This clean approach is more predictable; the driver is not doing gymnastics behind the scenes to manage resources (as in OpenGL). As a result, job processing is streamlined and straightforward, resulting in optimal performance and predictable behavior.

• Precompiled intermediate shading language: Unlike OpenGL, which requires shaders to be provided as OpenGL Shading Language (GLSL) source code, the Standard Portable Intermediate Language (SPIR-V) is a standard intermediate language used by Vulkan for parallel computing and graphics.

Note

Compilers for source languages, such as GLSL, HLSL, or LLVM, must target the SPIR-V specification and provide utilities to provide SPIR-V input. Vulkan takes this ready-to-execute binary-intermediate input and uses it at the shader stage.

• Driver and Application layer: In OpenGL, the application layer is thinner as compared to the driver layer, as the driver's automation takes into account resource management and state tracking. Vulkan is the opposite of this. It ensures the driver is closer to the hardware with less overhead. It's an application's responsibility to manage logic, resources, and states. The following diagram shows the thickness of the driver and application code base of both the APIs:

• Memory controls: Vulkan is capable of exposing various memory types on the system and requires the application developer to choose the appropriate memory type for the intended use of each resource. In contrast, OpenGL drivers decide on the placement of resources according to internal heuristics, which vary between vendors, and it may produce suboptimal placement or unexpected hitches if the driver moves the resource later.
• Predictable: Vulkan is highly predictable as compared to OpenGL; it does not cause any lags or hitches while rendering. The jobs are submitted upfront as soon as they are given to the driver, whereas the OpenGL job submission process is not upfront and is at the mercy of the driver's scheduler.
• A single API: OpenGL has separate versions for a desktop-based API (OpenGL) and embedded API (OpenGL ES). Vulkan is clean and consists of only a single API for any number of platforms. Vulkan supports mobile platforms as a first-class citizen, which is not the case in OpenGL. Usually, the OpenGL implementation first appears on desktop-based versions and is later made available to the OpenGL ES APIs.
• Direct access to the GPU: Vulkan gives a lot of control to the application user by advertising its capabilities and hardware facilities. It exposes various types of available physical devices, memory types, command buffer queues, and extensions. This behavior ensures the software layer is much closer to the real hardware.
• Error checking and validation: When using OpenGL, well-behaved applications pay a price when it comes to checking for errors, which they will never trigger at the time of execution. In contrast, Vulkan offers these checks and validation as an add-on service, which can be enabled and disabled as and when required. These checks are optional and can be injected into a runtime by enabling error checking and other validation layers. As a result, it causes less CPU overhead by avoiding unnecessary checks. Ideally, these error and validation layers must be turned on during the development phase for the debugging process and turned off during the release process.
• Supports various GPU hardware: Vulkan supports mobile and desktop rasterizers as an integrated part of the implementation. It supports tile-based or deferred rasterizers for embedded platforms along with native tiling-based feed forward rasterizers.