AMD has made V-EZ, the Vulkan wrapper library open source. The V-EZ wrapper is C based lightweight layer around Vulkan which reduces the complexity of using the Vulkan API. It abstracts away the lower level complexities of the Vulkan API. It also reduces differences between traditional graphics APIs and Vulkan by providing similar semantics to Vulkan.
V-EZ is basically designed to increase the adoption of Vulkan in the gaming industry. It provides game developers with all the modern graphics API features without all of the low-level responsibilities. The low-level Vulkan API features abstracted in V-EZ include:
- Memory management
- Swapchain management
- Render Passes
- Pipeline permutations, layouts, and barriers
- Descriptor pools, sets, and set layouts
- Image layouts
- GLSL compilation
V-EZ has only a slight performance overhead as compared to native Vulkan APIs and offers most Vulkan API features including
- Batching queue submissions
- Multi-threaded command buffer recording
- Reusing command buffers
- Minimizing pipeline bindings
- Minimizing resource bindings
- Batching draw calls
As mentioned on their Github repo, V-EZ is not hardware vendor specific and should work on non-AMD hardware as well. For building V-EZ you can follow these instructions:
- Run cmake to generate Visual Studio solution files or Linux make files. No specific settings need to be set.
- Pull down submodules
git submodule init
git submodule update
- Build V-EZ project.
Reddit is abuzz with discussion on whether Vulkan is right to be advertised as a general replacement to OpenGL. Some said that Vulkan is a viable replacement to OpenGL but only at a lower level.
A lot of the logic that openGL drivers take care of internally are exposed in the Vulkan API to allow for more optimization and performance focused coding.
It’s a lower level replacement. Most of of the code deals with stuff like GPU memory allocation, command buffering, synchronisation, and other such low-level concerns that, AFAIK, OpenGL doesn’t let you touch.
Some said Vulkan only stands out when you build games.
I see indie game developers who are writing their own games without an existing engine would benefit greatly from higher abstractions of Vulkan, like this V-EZ project. They will get most of the performance improvements of Vulkan without a lot of the complexity. And in some cases the Vulkan abstraction is easier to understand and reason about than the OpenGL equivalent.
Most people shouldn’t use Vulkan directly. They should use a graphics library that would deal with the low level stuff. Only people making game engines and graphics libraries have to use low level Vulkan API and for those purposes Vulkan is superior.