Vulkan summary
-
GPU selection / Multi-GPU compatibility
-
Opt in for extensions, nothing is automatically enabled.
-
No driver validation by default. Validation layer is opt-in for development.
-
Queues for graphics, compute and DMA (asynchronous data transfer). Multiple queues of each type.
-
Command buffers can be created from all threads, but they are not thread-safe (use 1 command buffer per thread).
-
Command buffers can be precomputed and reused, and all driver optimizations etc are done on application thread. Driver is simpler
-
SPIR-V shaders are compiled instantly on application thread, allowing multi-threaded shader compilation.
-
Pipeline = shader + framebuffer internal format + blend/depth/stencil etc state. Precompiled, but some settings are dynamic.
-
Resources are allocated by creating the CPU side object, then attaching GPU memory to them. GPU memory can be allocated in chunks and the application can do exactly what it wants with it.
-
Resources are accessed by GPU using descriptors. Descriptors are organized in descriptor sets.
-
Descriptor sets and pipelines both have layouts that much match, allowing you to switch entire descriptor sets extremely fast.
-
Rendering is done in render passes. Encapsulates all operations for a specific framebuffer.
-
Rendering is essentially [bind pipeline, bind descriptor set, draw call] triples.
-
All these draw calls are stored in a command buffers.
-
No global state! Driver only tracks state inside command buffers.
-
Indexed, non-indexed, direct, indirect, compute, etc draw calls supported.
-
Synchronization between CPU, GPU, etc.
-
Barriers must be placed when using a resource in a new way (example: render-to-texture --> sample texture)
-
Finally submit command buffers to the Vulkan queues. Can reuse command buffers any number of times.
-
Apparently not really low-level. Just a much better fit for modern GPUs.
-
Even without utilizing multithreading, has much better CPU performance anyway.
SPIR-V summary
-
Open standard. Can write your own -to-SPIR-V compiler.
-
SPIR-V is an intermediate language. Vulkan drivers can only use SPIR-V shaders.
-
Compile GLSL/whatever to SPIR-V offline, distribute SPIR-V binary file with game.
-
Driver still needs to compile SPIR-V to assembly code for the GPU you have.
-
SPIR-V can support pointers but can also run without them (like GLSL).
-
Can contain debug information to allow you to debug the source code.
-
All in all, not really that relevant for us.
ARM summary
- Prototype ARM Mali Midgard GPU driver created for Vulkan.
- Vulkan takes only 21% as many CPU cycles to render the same thing in their test.
The rest
- Imagination technologies ported a complicated demo using 2 people and 2 months to Vulkan, got better CPU performance.
- Intel has a prototype Vulkan render 200 000 primitives using OpenGL CPU bound at ~30 FPS, using Vulkan the CPU usage drops a lot, splits the load across all cores and runs at ~42 FPS.
- Nvidia showed an unoptimized “OpenGL-emulated” Vulkan driver that had 5x (400ms --> 80ms) better CPU performance, and they’re expecting a 45x (400ms --> 9ms) increase after optimization.
Q&A
- Open-source intermediate loader takes care of directing Vulkan calls to the right driver when using multiple GPUs from different vendors.
- Minimum specs roughly equivalent to OpenGL ES 3. Seems to require compute shaders, which in theory should be Nvidia 8000 series and AMD HD 3000 series (OGL3), but might mean OGL 4 cards only if we’re unlucky.
- The demos used an open source GLSL-to-SPIR-V compiler which is still under development. One demo faked it and loaded GLSL directly to be able to benchmark the relevant CPU overhead of Vulkan only.
- They will not be abandoning OpenGL. Fuuuuuuuu-------
- Hello world! on GL is 5 lines; on Vulkan it’s 600 lines, but obviously a lot of that can be reused.