Vulkan's new Ray Tracing extension goes by the name VK_KHR_ray_tracing and then enter one of the following functions:
- Performance of construction and management of accelerated structures.
- Support for sections and pipelines for ray traching shaders.
- Internal ray query for all shader classes.
The features of this expansion are quite wide, but among them we have found one that reads:
- rayTracingHostAccelerationStructureCommands shows CPU-based acceleration support.
Which of the other additions leaves the scene undetected so far by the NVIDIA / Microsoft duo.
Ray Tracking on CPU due to Vulkan: when GPUs are not enough
We all know that Turing's architecture has always been front and rear of the GPUs and development engines, not with the innocent NVIDIA charging it for the price of gold. But we have also seen that its implementation of BVH algorithms is performed in an integrated and clean and independent way, as a completely external process to traditional Shading.
The lack of power of GPUs and their specific units limits the performance that can be achieved in this way, because very high computational power is required to achieve high-quality ray tracking in real time.
However, What if the CPU participates in this calculation? Users with faster processes and more cores will have noticed that the current engines rarely load all 20-50% more threads in the worst case, where six cores are more than playable.
Khronos has taken this into account and has enabled a special extension of the Vulkan that allows to accurately load the CPU with direct Ray Tracing calculations.
CPUs also work to support GPUs
A specific extension is defined as VK_KHR_deforter_host_operations and allows the API to load expensive driver functions into a specific set of CPU strings, which will be managed by the application.
This enables work done by multiple threads in the background and similarly to many cores. This is useful for integrating Ray Tracing pipes or building CPU-accelerated structures for similar purposes.
The intended administrative functions are based on the "divisional labor" principle and furthermore the application is responsible for:
- Configuration of commands and requests execution denied.
- Assigning employee threads to execute deferred commands.
- Set CPU priorities and budgets as you see fit, choosing what tasks to carry out and when to do them.
The driver is also responsible for some of this:
- Tracking status to issue a limited command.
- Implementation of distribution operations, or any similar architecture is more suitable i load (functions, associated logs, dependency charts, task queues, etc.).
In this way, the app controls the allocation and prioritization of the work, but the driver handles low API information.
The battle is waived, is this one of the developer's requests to choose Vulkan rather than DXR? Will Microsoft copy the launch of Vulkan before they even think about it? A power struggle is being waged.
