Vulkan-Docs/appendices/VK_EXT_shader_subgroup_vote.txt
Jon Leech f1a7c4b4f3 Change log for January 13, 2019 Vulkan 1.1.98 spec update:
* Update release number to 98.

Public Issues:

  * Fix missing markup in flink:vkDestroyPipelineLayout valid usage
    statement (pull request 882).
  * Add missing contributors for `<<VK_EXT_buffer_device_address>>` (public
    pull request 891).

Internal Issues:

  * Detect nested bullet points in valid usage blocks and warn about them
    during VUID assignment (internal issue 1382).
  * Update the style guide to document the process for reserving new bits in
    bitmask types (internal issue 1411).
  * Clarify for slink:VkApplicationInfo::pname:apiVersion and in the
    <<fundamentals-validusage-versions, Valid Usage for Newer Core
    Versions>> section when it is valid for an application to use a certain
    version of Vulkan API functionality (for an instance and for a
    device/physical device); and when the validation layers must generate an
    error (internal issue 1412).
  * Add optional <<memory-model-availability-visibility, transitive
    availability/visibility operations to the memory model, including a new
    pname:vulkanMemoryModelAvailabilityVisibilityChains feature for
    slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR (internal issue
    1460).
  * Add the code:StorageBuffer storage class to those in the
    <<interfaces-resources-descset, Descriptor Set Interface>> (internal
    issue 1480).
  * Add missing `returnedonly` tags for a number of returned extension
    structures that can be passed in pname:pNext chains (internal issue
    1515).
  * Clean up and rearrange some spec language for
    slink:VkRenderPassCreateInfo and slink:VkAttachmentReference.txt
    (internal issue 1522).
  * Correctly round the code:OpVectorTimesScalar and
    code:OpMatrixTimesScalar SPIR-V operations in the <<Precision of core
    SPIR-V Instructions>> table (internal merge request 2996).
  * Work around cases in flink:vkCmdBeginTransformFeedbackEXT,
    flink:vkCmdEndTransformFeedbackEXT, and
    slink:VkPipelineCoverageModulationStateCreateInfoNV where an array
    parameter is `optional` but the length is not in `vk.xml`. This is an
    interim fix using `noautovalidity` + handcoded VU replacing those that
    should be autogenerated (internal issue 2944 and
    https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/480).
  * Remove redundant capability validation of the code:float16 and code:int8
    SPIR-V capabilities from the <<spirvenv-capabilities, Capabilities>>
    section, since they are already covered in the preceding table.
  * Update check_spec_links script, including validation for reference page
    open blocks. Fix errors identified by the script.
2019-01-13 05:53:27 -08:00

133 lines
4.1 KiB
Plaintext

include::meta/VK_EXT_shader_subgroup_vote.txt[]
*Last Modified Date*::
2016-11-28
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- This extension requires the
https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_subgroup_vote.html[`SPV_KHR_subgroup_vote`]
SPIR-V extension.
- This extension requires the
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shader_group_vote.txt[`GL_ARB_shader_group_vote`]
extension for GLSL source languages.
*Contributors*::
- Neil Henning, Codeplay
- Daniel Koch, NVIDIA Corporation
This extension adds support for the following SPIR-V extension in Vulkan:
* `SPV_KHR_subgroup_vote`
This extension provides new SPIR-V instructions:
* code:OpSubgroupAllKHR,
* code:OpSubgroupAnyKHR, and
* code:OpSubgroupAllEqualKHR.
to compute the composite of a set of boolean conditions across a group of
shader invocations that are running concurrently (a _subgroup_).
These composite results may be used to execute shaders more efficiently on a
slink:VkPhysicalDevice.
When using GLSL source-based shader languages, the following shader
functions from GL_ARB_shader_group_vote can map to these SPIR-V
instructions:
* code:anyInvocationARB() -> code:OpSubgroupAnyKHR,
* code:allInvocationsARB() -> code:OpSubgroupAllKHR, and
* code:allInvocationsEqualARB() -> code:OpSubgroupAllEqualKHR.
The subgroup across which the boolean conditions are evaluated is
implementation-dependent, and this extension provides no guarantee over how
individual shader invocations are assigned to subgroups.
In particular, a subgroup has no necessary relationship with the compute
shader _local workgroup_ -- any pair of shader invocations in a compute
local workgroup may execute in different subgroups as used by these
instructions.
Compute shaders operate on an explicitly specified group of threads (a local
workgroup), but many implementations will also group non-compute shader
invocations and execute them concurrently.
When executing code like
[source,c++]
----------------------------------------
if (condition) {
result = do_fast_path();
} else {
result = do_general_path();
}
----------------------------------------
where code:condition diverges between invocations, an implementation might
first execute code:do_fast_path() for the invocations where code:condition
is true and leave the other invocations dormant.
Once code:do_fast_path() returns, it might call code:do_general_path() for
invocations where code:condition is code:false and leave the other
invocations dormant.
In this case, the shader executes *both* the fast and the general path and
might be better off just using the general path for all invocations.
This extension provides the ability to avoid divergent execution by
evaluating a condition across an entire subgroup using code like:
[source,c++]
----------------------------------------
if (allInvocationsARB(condition)) {
result = do_fast_path();
} else {
result = do_general_path();
}
----------------------------------------
The built-in function code:allInvocationsARB() will return the same value
for all invocations in the group, so the group will either execute
code:do_fast_path() or code:do_general_path(), but never both.
For example, shader code might want to evaluate a complex function
iteratively by starting with an approximation of the result and then
refining the approximation.
Some input values may require a small number of iterations to generate an
accurate result (code:do_fast_path) while others require a larger number
(code:do_general_path).
In another example, shader code might want to evaluate a complex function
(code:do_general_path) that can be greatly simplified when assuming a
specific value for one of its inputs (code:do_fast_path).
=== New Object Types
None.
=== New Enum Constants
None.
=== New Enums
None.
=== New Structures
None.
=== New Functions
None.
=== New Built-In Variables
None.
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-table-subgroupvote,SubgroupVoteKHR>>
=== Issues
None.
=== Version History
* Revision 1, 2016-11-28 (Daniel Koch)
- Initial draft