Add the ability to Sleep and/or reduce a wave's priority

[AdamJMiles]

Hi,

As the algorithms we put into Compute Shaders get more and more complex there's an ever increasing number of shaders that have a property of being inherently producer-consumer. That may be one wave producing work that other waves in a thread group can consume, or something more complex where thread groups are producing work that other thread groups consume.

Today, neither of those algorithms are strictly legal without a Forward Progress guarantee, but they are being written and for the most part are being shipped regardless.

Given that, I've sometimes felt the need to be able to indicate that a wave (or set of waves) should temporarily either yield execution completely to other waves / thread groups, or at least indicate that other waves / thread groups should take priority thereafter. In a CPU world, this would be achieved through a combination of YieldProcessor, Sleep and SetThreadPriority.

The timescales that GPU shaders work on would make a Sleep that takes milliseconds (or even microseconds) too long, and expressing the intended delay in cycles does not feel like an appropriate proposal that would work across GPUs past, present and future. CUDA exposes __nanosleep(ns) for this purpose. A Yield intrinsic that communicates that a wave does not need to immediately continue execution, and if necessary can be ignored by an IHV would be one way to at 'context switch' to other work.

Based on public information, switching wave priority is something that some GPUs do support and could be another way to get the most important (producer) waves some priority over those waves that would otherwise just spin infinitely looking for work that would be produced until other waves get a chance. Like Yield, this intrinsic could be ignored if it's not supported, and would simply serve as a hint if an IHV is able to achieve something akin to a change in wave priority.

Thanks,

Adam

[devshgraphicsprogramming]

This is a Shader Model / Environment (Vulkan / DirectX) issue, first such a capability must exist in SPIR-V and the client graphics API.

On the Vulkan side, the correct door to knock on is KhronosGroup/Vulkan-Docs#2233

[devshgraphicsprogramming]

Also doesn't this depend on #336 ?

[llvm-beanz]

This is a Shader Model / Environment (Vulkan / DirectX) issue, first such a capability must exist in SPIR-V and the client graphics API.

On the Vulkan side, the correct door to knock on is KhronosGroup/Vulkan-Docs#2233

Respectfully disagree. This is the right place for us to track this request. The HLSL team participates in the Khronos Vulkan and SPIR working groups. We're able to handle that coordination.