• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1include::meta/VK_EXT_shader_subgroup_vote.txt[]
2
3*Last Modified Date*::
4    2016-11-28
5*IP Status*::
6    No known IP claims.
7*Interactions and External Dependencies*::
8  - This extension requires the
9    https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_subgroup_vote.html[+SPV_KHR_subgroup_vote+]
10    SPIR-V extension.
11  - This extension requires the
12    https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shader_group_vote.txt[+GL_ARB_shader_group_vote+]
13    extension for GLSL source languages.
14*Contributors*::
15  - Neil Henning, Codeplay
16  - Daniel Koch, NVIDIA Corporation
17
18This extension adds support for the following SPIR-V extension in Vulkan:
19
20  * +SPV_KHR_subgroup_vote+
21
22This extension provides new SPIR-V instructions:
23
24  * code:OpSubgroupAllKHR,
25  * code:OpSubgroupAnyKHR, and
26  * code:OpSubgroupAllEqualKHR.
27
28to compute the composite of a set of boolean conditions across a group of
29shader invocations that are running concurrently (a _subgroup_).
30These composite results may be used to execute shaders more efficiently on a
31slink:VkPhysicalDevice.
32
33When using GLSL source-based shader languages, the following shader
34functions from GL_ARB_shader_group_vote can map to these SPIR-V
35instructions:
36
37  * code:anyInvocationARB() -> code:OpSubgroupAnyKHR,
38  * code:allInvocationsARB() -> code:OpSubgroupAllKHR, and
39  * code:allInvocationsEqualARB() -> code:OpSubgroupAllEqualKHR.
40
41The subgroup across which the boolean conditions are evaluated is
42implementation-dependent, and this extension provides no guarantee over how
43individual shader invocations are assigned to subgroups.
44In particular, a subgroup has no necessary relationship with the compute
45shader _local workgroup_ -- any pair of shader invocations in a compute
46local workgroup may execute in different subgroups as used by these
47instructions.
48
49Compute shaders operate on an explicitly specified group of threads (a local
50workgroup), but many implementations will also group non-compute shader
51invocations and execute them concurrently.
52When executing code like
53
54[source,c++]
55----------------------------------------
56if (condition) {
57  result = do_fast_path();
58} else {
59  result = do_general_path();
60}
61----------------------------------------
62
63where code:condition diverges between invocations, an implementation might
64first execute code:do_fast_path() for the invocations where code:condition
65is true and leave the other invocations dormant.
66Once code:do_fast_path() returns, it might call code:do_general_path() for
67invocations where code:condition is code:false and leave the other
68invocations dormant.
69In this case, the shader executes *both* the fast and the general path and
70might be better off just using the general path for all invocations.
71
72This extension provides the ability to avoid divergent execution by
73evaluating a condition across an entire subgroup using code like:
74
75[source,c++]
76----------------------------------------
77if (allInvocationsARB(condition)) {
78  result = do_fast_path();
79} else {
80  result = do_general_path();
81}
82----------------------------------------
83
84The built-in function code:allInvocationsARB() will return the same value
85for all invocations in the group, so the group will either execute
86code:do_fast_path() or code:do_general_path(), but never both.
87For example, shader code might want to evaluate a complex function
88iteratively by starting with an approximation of the result and then
89refining the approximation.
90Some input values may require a small number of iterations to generate an
91accurate result (code:do_fast_path) while others require a larger number
92(code:do_general_path).
93In another example, shader code might want to evaluate a complex function
94(code:do_general_path) that can be greatly simplified when assuming a
95specific value for one of its inputs (code:do_fast_path).
96
97=== New Object Types
98
99None.
100
101=== New Enum Constants
102
103None.
104
105=== New Enums
106
107None.
108
109=== New Structures
110
111None.
112
113=== New Functions
114
115None.
116
117=== New Built-In Variables
118
119None.
120
121=== New SPIR-V Capabilities
122
123  * <<spirvenv-capabilities-table-subgroupvote,SubgroupVoteKHR>>
124
125=== Issues
126
127None.
128
129=== Version History
130
131  * Revision 1, 2016-11-28 (Daniel Koch)
132    - Initial draft
133