• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1// Copyright 2016-2024 The Khronos Group Inc.
2//
3// SPDX-License-Identifier: CC-BY-4.0
4
5include::{generated}/meta/{refprefix}VK_KHR_variable_pointers.adoc[]
6
7=== Other Extension Metadata
8
9*Last Modified Date*::
10    2017-09-05
11*IP Status*::
12    No known IP claims.
13*Contributors*::
14  - John Kessenich, Google
15  - Neil Henning, Codeplay
16  - David Neto, Google
17  - Daniel Koch, Nvidia
18  - Graeme Leese, Broadcom
19  - Weifeng Zhang, Qualcomm
20  - Stephen Clarke, Imagination Technologies
21  - Faith Ekstrand, Intel
22  - Jesse Hall, Google
23
24=== Description
25
26The `VK_KHR_variable_pointers` extension allows implementations to indicate
27their level of support for the `SPV_KHR_variable_pointers` SPIR-V extension.
28The SPIR-V extension allows shader modules to use invocation-private
29pointers into uniform and/or storage buffers, where the pointer values can
30be dynamic and non-uniform.
31
32The `SPV_KHR_variable_pointers` extension introduces two capabilities.
33The first, code:VariablePointersStorageBuffer, must: be supported by all
34implementations of this extension.
35The second, code:VariablePointers, is optional.
36
37=== Promotion to Vulkan 1.1
38
39All functionality in this extension is included in core Vulkan 1.1, with the
40KHR suffix omitted, however support for the
41<<features-variablePointersStorageBuffer,
42pname:variablePointersStorageBuffer>> feature is made optional.
43The original type, enum and command names are still available as aliases of
44the core functionality.
45
46include::{generated}/interfaces/VK_KHR_variable_pointers.adoc[]
47
48=== New SPIR-V Capabilities
49
50  * <<spirvenv-capabilities-table-VariablePointers, code:VariablePointers>>
51  * <<spirvenv-capabilities-table-VariablePointersStorageBuffer,
52    code:VariablePointersStorageBuffer>>
53
54=== Issues
55
561) Do we need an optional property for the SPIR-V
57code:VariablePointersStorageBuffer capability or should it be mandatory when
58this extension is advertised?
59
60*RESOLVED*: Add it as a distinct feature, but make support mandatory.
61Adding it as a feature makes the extension easier to include in a future
62core API version.
63In the extension, the feature is mandatory, so that presence of the
64extension guarantees some functionality.
65When included in a core API version, the feature would be optional.
66
672) Can support for these capabilities vary between shader stages?
68
69*RESOLVED*: No, if the capability is supported in any stage it must be
70supported in all stages.
71
723) Should the capabilities be features or limits?
73
74*RESOLVED*: Features, primarily for consistency with other similar
75extensions.
76
77=== Version History
78
79  * Revision 1, 2017-03-14 (Jesse Hall and John Kessenich)
80  ** Internal revisions
81