![](/style/images/good.png)
![](/style/images/bad.png)
VK_EXT_pipeline_creation_cache_control(3)
source link: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_pipeline_creation_cache_control.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Background
Pipeline creation is a costly operation, and the explicit nature of the Vulkan design means that cost is not hidden from the developer. Applications are also expected to schedule, prioritize, and load balance all calls for pipeline creation. It is strongly advised that applications create pipelines sufficiently ahead of their usage. Failure to do so will result in an unresponsive application, intermittent stuttering, or other poor user experiences. Proper usage of pipeline caches and/or derivative pipelines help mitigate this but is not assured to eliminate disruption in all cases. In the event that an ahead-of-time creation is not possible, considerations should be taken to ensure that the current execution context is suitable for the workload of pipeline creation including possible shader compilation.
Applications making API calls to create a pipeline must be prepared for any of the following to occur:
-
OS/kernel calls to be made by the ICD
-
Internal memory allocation not tracked by the
pAllocator
passed tovkCreate*Pipelines
-
Internal thread synchronization or yielding of the current thread’s core
-
Extremely long (multi-millisecond+), blocking, compilation times
-
Arbitrary call stacks depths and stack memory usage
The job or task based game engines that are being developed to take advantage of explicit graphics APIs like Vulkan may behave exceptionally poorly if any of the above scenarios occur. However, most game engines are already built to “stream” in assets dynamically as the user plays the game. By adding control by way of VkPipelineCreateFlags, we can require an ICD to report back a failure in critical execution paths rather than forcing an unexpected wait.
Applications can prevent unexpected compilation by setting
VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT
on
Vk*PipelineCreateInfo
::flags
.
When set, an ICD must not attempt pipeline or shader compilation to create
the pipeline object.
The ICD will return the result VK_PIPELINE_COMPILE_REQUIRED_EXT
.
An ICD may still return a valid VkPipeline
object by either re-using
existing pre-compiled objects such as those from a pipeline cache, or
derivative pipelines.
By default vkCreate*Pipelines
calls must attempt to create all
pipelines before returning.
Setting VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT
on
Vk*PipelineCreateInfo
::flags
can be used as an escape hatch for
batched pipeline creates.
Hidden locks also add to the unpredictability of the cost of pipeline
creation.
The most common case of locks inside the vkCreate*Pipelines
is
internal synchronization of the VkPipelineCache object.
VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT
can be set
when calling vkCreatePipelineCache to state the cache is
externally synchronized.
The hope is that armed with this information application and engine developers can leverage existing asset streaming systems to recover from "just-in-time" pipeline creation stalls.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK