mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-22 02:58:16 +00:00
ce60b9c887
* Vulkan 1.1 initial release. Bump API patch number and header version
number to 70 for this update. The patch number will be used for both
Vulkan 1.1 and Vulkan 1.0 updates, and continues to increment
continuously from the previous Vulkan 1.0.69 update.
NOTE: We are not publishing an updated 1.0.70 specification, or 1.1
reference pages, along with 1.1.70. There are still minor issues to work
out with those build targets. However, we will soon generate all three
types of documents as part of the regular spec update cycle.
NOTE: The GitHub KhronosGroup/Vulkan-Docs repository now maintains the
current specification in the `master` branch. The `1.0` branch is out of
date and will not be maintained, since we will be generating both 1.1
and 1.0 specifications from the `master` branch in the future.
Github Issues:
* Clarify how mapped memory ranges are flushed in
flink:vkFlushMappedMemoryRanges (public issue 127).
* Specify that <<synchronization-pipeline-stages, Pipeline Stages>> are a
list of tasks that each command performs, rather than necessarily being
discrete pieces of hardware that one task flows through. Add a
"`synchronization command`" pipeline type which all synchronization
command execute (it's just TOP + BOTTOM), with an explanatory note
(public issue 554).
Internal Issues:
* Regenerate all images used in the spec in Inkscape with a consistent
look-and-feel, and adjust image size attributes so they're all legible,
and not too large with respect to the spec body text (internal issue
701).
* Document in the <<extensions,extensions>> appendix and in the style
guide that `KHX` extensions are no longer supported or used in the
Vulkan 1.1 timeframe (internal issue 714).
* Remove the leftover equations_temp directory after PDF build completes
(internal issue 925).
* Update the <<credits, Credits (Informative)>> appendix to include
contributors to Vulkan 1.1, and to list them according to the API
version(s) they contributed to (internal issue 987).
* Add a NOTE to the introduction explaining that interfaces defined by
extensions which were promoted to Vulkan 1.1 are now expressed as
aliases of the Vulkan 1.1 type (internal issue 991).
* Instrument spec source conditionals so spec can be built with 1.1
features, extensions promoted to 1.1, or both (internal issues 992,
998).
* Modify the XML schema and tools to support explicit aliasing of types,
structures, and commands, and use this to express the promotion of 1.0
extensions to 1.1 core features, by making the extension interfaces
aliases of the core features they were promoted to. Mark up promoted
interfaces to allow still generating 1.0 + extension specifications
(internal issue 991).
* Platform names, along with corresponding preprocessor symbols to enable
extensions specific to those platforms, are now reserved in vk.xml using
the <platform> tag. Update the registry schema and schema specification
to match (internal issue 1011).
* Updated the <<textures-texel-replacement, Texel Replacement>> section to
clarify that reads from invalid texels for image resources result in
undefined values (internal issue 1014).
* Modify description of patch version so it continues to increment across
minor version changes (internal issue 1033).
* Clarify and unify language describing physical device-level core and
extension functionality in the <<fundamentals-validusage-extensions,
Valid Usage for Extensions>>, <<fundamentals-validusage-versions, Valid
Usage for Newer Core Versions>>, <<initialization-functionpointers
Command Function Pointers>>, <<initialization-phys-dev-extensions,
Extending Physical Device From Device Extensions>>
<<extended-functionality-instance-extensions-and-devices, Instance
Extensions and Device Extensions>> sections and for
flink:vkGetPhysicalDeviceImageFormatProperties2. This documents that
instance-level functionality is tied to the loader, and independent of
the ICD; physical device-level functionality is tied to the ICD, and
associated with device extensions; physical devices are treated more
uniformly between core and extensions; and instance and physical
versions can be different (internal issue 1048).
* Updated the <<commandbuffers-lifecycle, Command Buffer Lifecycle>>
section to clarify the ability for pending command buffers to transition
to the invalid state after submission, and add a command buffer
lifecycle diagram (internal issue 1050).
* Clarify that some flink:VkDescriptorUpdateTemplateCreateInfo parameters
are ignored when push descriptors are not supported (internal issue
1054).
* Specify that flink:vkCreateImage will return an error if the image is
too large, in a NOTE in the slink:VkImageFormatProperties description
(internal issue 1078).
* Remove near-duplicate NOTEs about when to query function pointers
dynamically in the <<initialization, Initialization>> chapter and
replace by extending the NOTE in the <<fundamentals-abi, Application
Binary Interface>> section (internal issue 1085).
* Restore missing references to "`Sparse Resource Features`" in the
flink:VkBufferCreateFlagBits description (internal issue 1086).
* Tidy up definitions of descriptor types in the `GL_KHR_vulkan_glsl`
specification, the <<descriptorsets, Resource Descriptors>> section and
its subsections, and the <<interfaces-resources-descset, Descriptor Set
Interface>> for consistency, reduction of duplicate information, and
removal of GLSL correspondance/examples (internal issue 1090).
* Correctly describe code:PrimitiveId as an Input for tessellation control
and evaluation shaders, not an Output (internal issue 1109).
* Relax the requirements on chroma offsets for nearest filtering in
<<textures-implict-reconstruction, Implicit Reconstruction>> (internal
issue 1116).
Other Issues:
* Clarify the intended relationship between specification language and
certain terms defined in the Khronos Intellectual Property Rights
policy. Specific changes include:
** Rewrote IP/Copyright preamble and introduction to better agree with
normative language both as laid out in the introduction, and the
Khronos IPR policy.
** Added notion of fully informative sections, which are now tagged with
"`(Informative)`" in their titles.
** Removed non-normative uses of the phrase "`not required`"
** Clarified the distinction between terms "`optional`" and "`not
required:`" as they relate to the IPR Policy, and updated specification
text to use terms consistent with the intent.
** Reduced additions to RFC 2119, and ensured the specification agreed
with the leaner language.
** Removed the terms "`hardware`", "`software`", "`CPU`", and "`GPU`" from
normative text.
** Moved several paragraphs that should not have been normative to
informative notes.
** Clarified a number of definitions in the Glossary.
** Updated the document writing guide to match new terminology changes.
* Explicitly state in the <<fundamentals-objectmodel-lifetime-acquire,
application memory lifetime>> language that that for objects other than
descriptor sets, a slink:VkDescriptorSetLayout object used in the
creation of another object (such as slink:VkPipelineLayout or
slink:VkDescriptorUpdateTemplateKHR) is only in use during the creation
of that object and can be safely destroyed afterwards.
* Updated the <<textures-scale-factor, Scale Factor Operation>> section to
use the ratio of anisotropy, rather than the integer sample rate, to
perform the LOD calculation. The spec still allows use of the sample
rate as the value used to calculate the LOD, but no longer requires it.
* Update `vulkan_ext.c` to include all platform-related definitions from
the Vulkan platform headers, following the split of the headers into
platform-specific and non-platform-specific files.
* Fix bogus anchor name in the <<commandbuffers, Command Buffers>> chapter
which accidentally duplicated an anchor in the pipelines chapter. There
were no reference to this anchor, fortunately.
* Add valid usage statement for slink:VkWriteDescriptorSet and
slink:VkCopyDescriptorSet requiring that the slink:VkDescriptorSetLayout
used to allocate the source and destination sets must not have been
destroyed at the time flink:vkUpdateDescriptorSets is called.
* Document mapping of subgroup barrier functions to SPIR-V, and clarify a
place where subgroupBarrier sounds like it's execution-only in the
standalone `GL_KHR_shader_subgroup` specification.
* Use an HTML stylesheet derived from the Asciidoctor `colony` theme, with
the default Arial font family replaced by the sans-serif Noto font
family.
* Numerous minor updates to README.adoc, build scripts, Makefiles, and
registry and style guide specifications to support Vulkan 1.1 outputs,
use them as defaults, and remove mention of `KHX` extensions, which are
no longer supported.
New Extensions:
* `VK_EXT_vertex_attrib_divisor`
378 lines
17 KiB
Plaintext
378 lines
17 KiB
Plaintext
// Copyright (c) 2015-2018 Khronos Group. This work is licensed under a
|
|
// Creative Commons Attribution 4.0 International License; see
|
|
// http://creativecommons.org/licenses/by/4.0/
|
|
|
|
[[extended-functionality]]
|
|
= Extended Functionality
|
|
|
|
Additional functionality may: be provided by layers or extensions.
|
|
A layer cannot: add or modify Vulkan commands, while an extension may: do
|
|
so.
|
|
|
|
The set of layers to enable is specified when creating an instance, and
|
|
those layers are able to intercept any Vulkan command dispatched to that
|
|
instance or any of its child objects.
|
|
|
|
Extensions can operate at either the instance or device _extension scope_.
|
|
Enabled instance extensions are able to affect the operation of the instance
|
|
and any of its child objects, while device extensions may: only be available
|
|
on a subset of physical devices, must: be individually enabled per-device,
|
|
and only affect the operation of the devices where they are enabled.
|
|
|
|
[NOTE]
|
|
.Note
|
|
====
|
|
Examples of these might be:
|
|
|
|
* Whole API validation is an example of a layer.
|
|
* Debug capabilities might make a good instance extension.
|
|
* A layer that provides implementation-specific performance telemetry and
|
|
analysis could be a layer that is only active for devices created from
|
|
compatible physical devices.
|
|
* Functions to allow an application to use additional implementation
|
|
features beyond the core would be a good candidate for a device
|
|
extension.
|
|
====
|
|
|
|
[[extended-functionality-layers]]
|
|
== Layers
|
|
|
|
When a layer is enabled, it inserts itself into the call chain for Vulkan
|
|
commands the layer is interested in.
|
|
A common use of layers is to validate application behavior during
|
|
development.
|
|
For example, the implementation will not check that Vulkan enums used by the
|
|
application fall within allowed ranges.
|
|
Instead, a validation layer would do those checks and flag issues.
|
|
This avoids a performance penalty during production use of the application
|
|
because those layers would not be enabled in production.
|
|
|
|
Vulkan layers may: wrap object handles (i.e. return a different handle value
|
|
to the application than that generated by the implementation).
|
|
This is generally discouraged, as it increases the probability of
|
|
incompatibilities with new extensions.
|
|
The validation layers wrap handles in order to track the proper use and
|
|
destruction of each object.
|
|
See the <<LoaderAndValidationLayers, "`Vulkan Loader Specification and
|
|
Architecture Overview`">> document for additional information.
|
|
|
|
[open,refpage='vkEnumerateInstanceLayerProperties',desc='Returns up to requested number of global layer properties',type='protos']
|
|
--
|
|
|
|
To query the available layers, call:
|
|
|
|
include::../api/protos/vkEnumerateInstanceLayerProperties.txt[]
|
|
|
|
* pname:pPropertyCount is a pointer to an integer related to the number of
|
|
layer properties available or queried, as described below.
|
|
* pname:pProperties is either `NULL` or a pointer to an array of
|
|
slink:VkLayerProperties structures.
|
|
|
|
If pname:pProperties is `NULL`, then the number of layer properties
|
|
available is returned in pname:pPropertyCount.
|
|
Otherwise, pname:pPropertyCount must: point to a variable set by the user to
|
|
the number of elements in the pname:pProperties array, and on return the
|
|
variable is overwritten with the number of structures actually written to
|
|
pname:pProperties.
|
|
If pname:pPropertyCount is less than the number of layer properties
|
|
available, at most pname:pPropertyCount structures will be written.
|
|
If pname:pPropertyCount is smaller than the number of layers available,
|
|
ename:VK_INCOMPLETE will be returned instead of ename:VK_SUCCESS, to
|
|
indicate that not all the available layer properties were returned.
|
|
|
|
The list of available layers may change at any time due to actions outside
|
|
of the Vulkan implementation, so two calls to
|
|
fname:vkEnumerateInstanceLayerProperties with the same parameters may:
|
|
return different results, or retrieve different pname:pPropertyCount values
|
|
or pname:pProperties contents.
|
|
Once an instance has been created, the layers enabled for that instance will
|
|
continue to be enabled and valid for the lifetime of that instance, even if
|
|
some of them become unavailable for future instances.
|
|
|
|
include::../validity/protos/vkEnumerateInstanceLayerProperties.txt[]
|
|
--
|
|
|
|
[open,refpage='VkLayerProperties',desc='Structure specifying layer properties',type='structs']
|
|
--
|
|
|
|
The sname:VkLayerProperties structure is defined as:
|
|
|
|
include::../api/structs/VkLayerProperties.txt[]
|
|
|
|
* pname:layerName is a null-terminated UTF-8 string specifying the name of
|
|
the layer.
|
|
Use this name in the pname:ppEnabledLayerNames array passed in the
|
|
slink:VkInstanceCreateInfo structure to enable this layer for an
|
|
instance.
|
|
* pname:specVersion is the Vulkan version the layer was written to,
|
|
encoded as described in the <<fundamentals-versionnum,API Version
|
|
Numbers and Semantics>> section.
|
|
* pname:implementationVersion is the version of this layer.
|
|
It is an integer, increasing with backward compatible changes.
|
|
* pname:description is a null-terminated UTF-8 string providing additional
|
|
details that can: be used by the application to identify the layer.
|
|
|
|
include::../validity/structs/VkLayerProperties.txt[]
|
|
--
|
|
|
|
To enable a layer, the name of the layer should: be added to the
|
|
pname:ppEnabledLayerNames member of slink:VkInstanceCreateInfo when creating
|
|
a sname:VkInstance.
|
|
|
|
Loader implementations may: provide mechanisms outside the Vulkan API for
|
|
enabling specific layers.
|
|
Layers enabled through such a mechanism are _implicitly enabled_, while
|
|
layers enabled by including the layer name in the pname:ppEnabledLayerNames
|
|
member of slink:VkInstanceCreateInfo are _explicitly enabled_.
|
|
Except where otherwise specified, implicitly enabled and explicitly enabled
|
|
layers differ only in the way they are enabled.
|
|
Explicitly enabling a layer that is implicitly enabled has no additional
|
|
effect.
|
|
|
|
|
|
[[extended-functionality-device-layer-deprecation]]
|
|
=== Device Layer Deprecation
|
|
|
|
Previous versions of this specification distinguished between instance and
|
|
device layers.
|
|
Instance layers were only able to intercept commands that operate on
|
|
sname:VkInstance and sname:VkPhysicalDevice, except they were not able to
|
|
intercept flink:vkCreateDevice.
|
|
Device layers were enabled for individual devices when they were created,
|
|
and could only intercept commands operating on that device or its child
|
|
objects.
|
|
|
|
Device-only layers are now deprecated, and this specification no longer
|
|
distinguishes between instance and device layers.
|
|
Layers are enabled during instance creation, and are able to intercept all
|
|
commands operating on that instance or any of its child objects.
|
|
At the time of deprecation there were no known device-only layers and no
|
|
compelling reason to create one.
|
|
|
|
In order to maintain compatibility with implementations released prior to
|
|
device-layer deprecation, applications should: still enumerate and enable
|
|
device layers.
|
|
The behavior of fname:vkEnumerateDeviceLayerProperties and valid usage of
|
|
the pname:ppEnabledLayerNames member of sname:VkDeviceCreateInfo maximizes
|
|
compatibility with applications written to work with the previous
|
|
requirements.
|
|
|
|
[open,refpage='vkEnumerateDeviceLayerProperties',desc='Returns properties of available physical device layers',type='protos']
|
|
--
|
|
|
|
To enumerate device layers, call:
|
|
|
|
include::../api/protos/vkEnumerateDeviceLayerProperties.txt[]
|
|
|
|
* pname:pPropertyCount is a pointer to an integer related to the number of
|
|
layer properties available or queried.
|
|
* pname:pProperties is either `NULL` or a pointer to an array of
|
|
slink:VkLayerProperties structures.
|
|
|
|
If pname:pProperties is `NULL`, then the number of layer properties
|
|
available is returned in pname:pPropertyCount.
|
|
Otherwise, pname:pPropertyCount must: point to a variable set by the user to
|
|
the number of elements in the pname:pProperties array, and on return the
|
|
variable is overwritten with the number of structures actually written to
|
|
pname:pProperties.
|
|
If pname:pPropertyCount is less than the number of layer properties
|
|
available, at most pname:pPropertyCount structures will be written.
|
|
If pname:pPropertyCount is smaller than the number of layers available,
|
|
ename:VK_INCOMPLETE will be returned instead of ename:VK_SUCCESS, to
|
|
indicate that not all the available layer properties were returned.
|
|
|
|
The list of layers enumerated by fname:vkEnumerateDeviceLayerProperties
|
|
must: be exactly the sequence of layers enabled for the instance.
|
|
The members of sname:VkLayerProperties for each enumerated layer must: be
|
|
the same as the properties when the layer was enumerated by
|
|
fname:vkEnumerateInstanceLayerProperties.
|
|
|
|
include::../validity/protos/vkEnumerateDeviceLayerProperties.txt[]
|
|
--
|
|
|
|
The pname:ppEnabledLayerNames and pname:enabledLayerCount members of
|
|
sname:VkDeviceCreateInfo are deprecated and their values must: be ignored by
|
|
implementations.
|
|
However, for compatibility, only an empty list of layers or a list that
|
|
exactly matches the sequence enabled at instance creation time are valid,
|
|
and validation layers should: issue diagnostics for other cases.
|
|
|
|
Regardless of the enabled layer list provided in sname:VkDeviceCreateInfo,
|
|
the sequence of layers active for a device will be exactly the sequence of
|
|
layers enabled when the parent instance was created.
|
|
|
|
|
|
[[extended-functionality-extensions]]
|
|
== Extensions
|
|
|
|
Extensions may: define new Vulkan commands, structures, and enumerants.
|
|
For compilation purposes, the interfaces defined by registered extensions,
|
|
including new structures and enumerants as well as function pointer types
|
|
for new commands, are defined in the Khronos-supplied `vulkan_core.h`
|
|
together with the core API.
|
|
However, commands defined by extensions may: not be available for static
|
|
linking - in which case function pointers to these commands should: be
|
|
queried at runtime as described in <<initialization-functionpointers>>.
|
|
Extensions may: be provided by layers as well as by a Vulkan implementation.
|
|
|
|
Because extensions may: extend or change the behavior of the Vulkan API,
|
|
extension authors should: add support for their extensions to the Khronos
|
|
validation layers.
|
|
This is especially important for new commands whose parameters have been
|
|
wrapped by the validation layers.
|
|
See the <<LoaderAndValidationLayers, "`Vulkan Loader Specification and
|
|
Architecture Overview`">> document for additional information.
|
|
|
|
[open,refpage='vkEnumerateInstanceExtensionProperties',desc='Returns up to requested number of global extension properties',type='protos']
|
|
--
|
|
|
|
To query the available instance extensions, call:
|
|
|
|
include::../api/protos/vkEnumerateInstanceExtensionProperties.txt[]
|
|
|
|
* pname:pLayerName is either `NULL` or a pointer to a null-terminated
|
|
UTF-8 string naming the layer to retrieve extensions from.
|
|
* pname:pPropertyCount is a pointer to an integer related to the number of
|
|
extension properties available or queried, as described below.
|
|
* pname:pProperties is either `NULL` or a pointer to an array of
|
|
slink:VkExtensionProperties structures.
|
|
|
|
When pname:pLayerName parameter is `NULL`, only extensions provided by the
|
|
Vulkan implementation or by implicitly enabled layers are returned.
|
|
When pname:pLayerName is the name of a layer, the instance extensions
|
|
provided by that layer are returned.
|
|
|
|
If pname:pProperties is `NULL`, then the number of extensions properties
|
|
available is returned in pname:pPropertyCount.
|
|
Otherwise, pname:pPropertyCount must: point to a variable set by the user to
|
|
the number of elements in the pname:pProperties array, and on return the
|
|
variable is overwritten with the number of structures actually written to
|
|
pname:pProperties.
|
|
If pname:pPropertyCount is less than the number of extension properties
|
|
available, at most pname:pPropertyCount structures will be written.
|
|
If pname:pPropertyCount is smaller than the number of extensions available,
|
|
ename:VK_INCOMPLETE will be returned instead of ename:VK_SUCCESS, to
|
|
indicate that not all the available properties were returned.
|
|
|
|
Because the list of available layers may change externally between calls to
|
|
pname:vkEnumerateInstanceExtensionProperties, two calls may retrieve
|
|
different results if a pname:pLayerName is available in one call but not in
|
|
another.
|
|
The extensions supported by a layer may also change between two calls, e.g.
|
|
if the layer implementation is replaced by a different version between those
|
|
calls.
|
|
|
|
include::../validity/protos/vkEnumerateInstanceExtensionProperties.txt[]
|
|
--
|
|
|
|
To enable an instance extension, the name of the extension should: be added
|
|
to the pname:ppEnabledExtensionNames member of slink:VkInstanceCreateInfo
|
|
when creating a sname:VkInstance.
|
|
|
|
Enabling an extension does not change behavior of functionality exposed by
|
|
the core Vulkan API or any other extension, other than making valid the use
|
|
of the commands, enums and structures defined by that extension.
|
|
|
|
[open,refpage='vkEnumerateDeviceExtensionProperties',desc='Returns properties of available physical device extensions',type='protos']
|
|
--
|
|
|
|
To query the extensions available to a given physical device, call:
|
|
|
|
include::../api/protos/vkEnumerateDeviceExtensionProperties.txt[]
|
|
|
|
* pname:physicalDevice is the physical device that will be queried.
|
|
* pname:pLayerName is either `NULL` or a pointer to a null-terminated
|
|
UTF-8 string naming the layer to retrieve extensions from.
|
|
* pname:pPropertyCount is a pointer to an integer related to the number of
|
|
extension properties available or queried, and is treated in the same
|
|
fashion as the
|
|
flink:vkEnumerateInstanceExtensionProperties::pname:pPropertyCount
|
|
parameter.
|
|
* pname:pProperties is either `NULL` or a pointer to an array of
|
|
slink:VkExtensionProperties structures.
|
|
|
|
When pname:pLayerName parameter is `NULL`, only extensions provided by the
|
|
Vulkan implementation or by implicitly enabled layers are returned.
|
|
When pname:pLayerName is the name of a layer, the device extensions provided
|
|
by that layer are returned.
|
|
|
|
include::../validity/protos/vkEnumerateDeviceExtensionProperties.txt[]
|
|
--
|
|
|
|
[open,refpage='VkExtensionProperties',desc='Structure specifying a extension properties',type='structs']
|
|
--
|
|
|
|
The sname:VkExtensionProperties structure is defined as:
|
|
|
|
include::../api/structs/VkExtensionProperties.txt[]
|
|
|
|
* pname:extensionName is a null-terminated string specifying the name of
|
|
the extension.
|
|
* pname:specVersion is the version of this extension.
|
|
It is an integer, incremented with backward compatible changes.
|
|
|
|
include::../validity/structs/VkExtensionProperties.txt[]
|
|
--
|
|
|
|
|
|
[[extended-functionality-instance-extensions-and-devices]]
|
|
=== Instance Extensions and Device Extensions
|
|
|
|
This section provides some guidelines and rules for when to expose new
|
|
functionality as an instance extension, as a device extension, or as both.
|
|
The decision depends on the scope of the new functionality; such as whether
|
|
it extends instance-level or device-level functionality.
|
|
All Vulkan commands, structures, and enumerants are considered either
|
|
instance-level, physical-device-level, or device-level.
|
|
|
|
New instance-level extension functionality must: be structured within an
|
|
instance extension.
|
|
New device-level extension functionality may: be structured within a device
|
|
extension.
|
|
Vulkan 1.0 initially required all new physical-device-level extension
|
|
functionality to be structured within an instance extension.
|
|
ifdef::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
|
|
In order to avoid using an instance extension, which often requires loader
|
|
support, physical-device-level extension functionality may: be implemented
|
|
within device extensions (which must: depend on the
|
|
`<<VK_KHR_get_physical_device_properties2>>` extension, or on Vulkan 1.1 or
|
|
later).
|
|
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
|
|
|
|
|
|
[[extended-functionality-extensions-dependencies]]
|
|
== Extension Dependencies
|
|
|
|
Some extensions are dependent on other extensions to function.
|
|
To use extensions with dependencies, such _required extensions_ must: also
|
|
be enabled through the same API mechanisms when creating an instance with
|
|
flink:vkCreateInstance or a device with flink:vkCreateDevice.
|
|
Each extension which has such dependencies documents them in the
|
|
<<extensions, appendix summarizing that extension>>.
|
|
|
|
[NOTE]
|
|
.Note
|
|
====
|
|
The Specification does not currently include required extensions in Valid
|
|
Usage statements for individual commands and structures, although it might
|
|
do so in the future.
|
|
Nonetheless, applications must: not use any extension functionality if
|
|
dependencies of that extension are not enabled.
|
|
====
|
|
|
|
|
|
[[extended-functionality-extensions-compatibility]]
|
|
== Extension Compatibility
|
|
|
|
By default, all extensions are considered compatible with each other and any
|
|
core API version, unless otherwise stated.
|
|
Thus enabling such extensions does not otherwise alter the behavior of the
|
|
application.
|
|
|
|
Each extension that is mutually exclusive or otherwise incompatible with
|
|
another extension or set of extensions documents them in the <<extensions,
|
|
appendix summarizing that extension>> and has a corresponding Valid Usage
|
|
statement disallowing enabling such an incompatible combination of
|
|
extensions at sname:VkInstance creation time or sname:VkDevice creation
|
|
time, depending on the type of extensions participating in the interaction.
|