// Copyright 2016-2023 The Khronos Group Inc.
//
// SPDX-License-Identifier: CC-BY-4.0

include::{generated}/meta/{refprefix}VK_KHR_variable_pointers.adoc[]

=== Other Extension Metadata

*Last Modified Date*::
    2017-09-05
*IP Status*::
    No known IP claims.
*Interactions and External Dependencies*::
  - This extension requires
    {spirv}/KHR/SPV_KHR_variable_pointers.html[`SPV_KHR_variable_pointers`]
  - Promoted to Vulkan 1.1 Core
*Contributors*::
  - John Kessenich, Google
  - Neil Henning, Codeplay
  - David Neto, Google
  - Daniel Koch, Nvidia
  - Graeme Leese, Broadcom
  - Weifeng Zhang, Qualcomm
  - Stephen Clarke, Imagination Technologies
  - Faith Ekstrand, Intel
  - Jesse Hall, Google

=== Description

The `VK_KHR_variable_pointers` extension allows implementations to indicate
their level of support for the `SPV_KHR_variable_pointers` SPIR-V extension.
The SPIR-V extension allows shader modules to use invocation-private
pointers into uniform and/or storage buffers, where the pointer values can
be dynamic and non-uniform.

The `SPV_KHR_variable_pointers` extension introduces two capabilities.
The first, code:VariablePointersStorageBuffer, must: be supported by all
implementations of this extension.
The second, code:VariablePointers, is optional.

=== Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the
KHR suffix omitted, however support for the
<<features-variablePointersStorageBuffer,
pname:variablePointersStorageBuffer>> feature is made optional.
The original type, enum and command names are still available as aliases of
the core functionality.

include::{generated}/interfaces/VK_KHR_variable_pointers.adoc[]

=== New SPIR-V Capabilities

  * <<spirvenv-capabilities-table-VariablePointers, code:VariablePointers>>
  * <<spirvenv-capabilities-table-VariablePointersStorageBuffer,
    code:VariablePointersStorageBuffer>>

=== Issues

1) Do we need an optional property for the SPIR-V
code:VariablePointersStorageBuffer capability or should it be mandatory when
this extension is advertised?

*RESOLVED*: Add it as a distinct feature, but make support mandatory.
Adding it as a feature makes the extension easier to include in a future
core API version.
In the extension, the feature is mandatory, so that presence of the
extension guarantees some functionality.
When included in a core API version, the feature would be optional.

2) Can support for these capabilities vary between shader stages?

*RESOLVED*: No, if the capability is supported in any stage it must be
supported in all stages.

3) Should the capabilities be features or limits?

*RESOLVED*: Features, primarily for consistency with other similar
extensions.

=== Version History

  * Revision 1, 2017-03-14 (Jesse Hall and John Kessenich)
  ** Internal revisions