GDC thus far has been full of things we expected to see though there are even a few good surprises that have a big impact on the future of gaming. Khronos has updated Vulkan to version 1.0.42, and with the few small differences they’ve added experimental support for a very important technology for gaming; explicit multi-adapter.
Vulkan is getting very competitive
This new version of Vulcan actually adds a few more very important features that could help improve performance by a few percentage points for all GPUs. Vulkan contains extension sets that allow certain features be put into Vulkan and iterated without destroying or otherwise adversely affecting the production code. Once these extensions are perfected, they can be ratified and officially added to the code base. Here, they’re working on enabling the use of explicit multi-adapter, a method of using multiple GPUs, or really any GPU in the system as a potential rendering resource.
This development is very important and mirrors work done by Microsoft with DirectX 12. This allows all GPUs to be accessible regardless of whether or not they’re linked by a specific multi-GPU protocol such as SLI or Crossfire. With the extension, Vulkan can see all GPU devices as one logical device, with pooled resources. With that, the Vulcan API can use Alternate Frame Rendering or Split Frame Rendering with a shared, pooled memory. There is also support for explicit control of scheduling of those resources to help with resources.
In the future it may even be possible to have the API detect resources and schedule tasks asynchronously so that reasonably simple tasks can even be sent to the iGPU for processing, similar to how it works with DirectX 12. The issue with pooling resources without a dedicated fabric to communicate is that there’s a latency penalty for accessing the memory of GPU for tasks on the other, should the scheduler misstep. And if they aren’t quite in sync for the tasks that need to be completed, it could hinder the experience with delays, jitter, tearing or out of sync frames. It still could add value to having older, dissimilar GPUs alongside for splitting the workload. Though that’s not likely anytime soon.
Additionally, having a logical pool of devices makes it significantly more valuable as a means to powering VR titles. This way, each GPU can be used specifically for one side of rendering a scene, being agnostic to the higher-level AMD LiquidVR or NVIDIA VRWorks for that same task. Having this task be inherent in the base layer API could save latency and decrease frame times by a good measure for those more challenging seems. Consistency is key, and keeping things exactly at 90FPS for the best experience possible.
These are early days yet for Vulkan, though this development is a way to increase the draw of the API for future game development.