mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-17 16:57:09 +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`
381 lines
14 KiB
Plaintext
381 lines
14 KiB
Plaintext
// Copyright (c) 2016-2018 Khronos Group. This work is licensed under a
|
|
// Creative Commons Attribution 4.0 International License; see
|
|
// http://creativecommons.org/licenses/by/4.0/
|
|
|
|
[appendix]
|
|
[[boilerplate]]
|
|
= API Boilerplate
|
|
|
|
This appendix defines Vulkan API features that are infrastructure required
|
|
for a complete functional description of Vulkan, but do not logically belong
|
|
elsewhere in the Specification.
|
|
|
|
|
|
[[boilerplate-headers]]
|
|
== Vulkan Header Files
|
|
|
|
Vulkan is defined as an API in the C99 language.
|
|
Khronos provides a corresponding set of header files for applications using
|
|
the API, which may be used in either C or C++ code.
|
|
The interface descriptions in the specification are the same as the
|
|
interfaces defined in these header files, and both are derived from the
|
|
`vk.xml` XML API Registry, which is the canonical machine-readable
|
|
description of the Vulkan API.
|
|
The Registry, scripts used for processing it into various forms, and
|
|
documentation of the registry schema are available as described at
|
|
https://www.khronos.org/registry/vulkan/#apiregistry .
|
|
|
|
Language bindings for other languages can be defined using the information
|
|
in the Specification and the Registry.
|
|
Khronos does not provide any such bindings, but third-party developers have
|
|
created some additional bindings.
|
|
|
|
|
|
[[boilerplate-vulkan-h]]
|
|
=== Vulkan Combined API Header `vulkan.h` (Informative)
|
|
|
|
Applications normally will include the header `vulkan.h`.
|
|
In turn, `vulkan.h` always includes the following headers:
|
|
|
|
* <<boilerplate-vk-platform,`vk_platform.h`>>, defining platform-specific
|
|
macros and headers.
|
|
* <<boilerplate-vulkan-core,`vulkan_core.h`>>, defining APIs for the
|
|
Vulkan core and all registered extensions _other_ than window
|
|
system-specific extensions.
|
|
|
|
In addition, specific preprocessor macros defined at the time `vulkan.h` is
|
|
included cause header files for the corresponding <<boilerplate-wsi-header,
|
|
window system-specific extension interfaces>> to be included.
|
|
|
|
|
|
[[boilerplate-platform-macros]]
|
|
=== Vulkan Platform-Specific Header `vk_platform.h` (Informative)
|
|
|
|
Platform-specific macros and interfaces are defined in `vk_platform.h`.
|
|
These macros are used to control platform-dependent behavior, and their
|
|
exact definitions are under the control of specific platforms and Vulkan
|
|
implementations.
|
|
|
|
|
|
[[boilerplate-platform-specific-calling-conventions]]
|
|
==== Platform-Specific Calling Conventions
|
|
|
|
On many platforms the following macros are empty strings, causing platform-
|
|
and compiler-specific default calling conventions to be used.
|
|
|
|
// @refBegin VKAPI_ATTR Vulkan function attributes
|
|
|
|
dname:VKAPI_ATTR is a macro placed before the return type in Vulkan API
|
|
function declarations.
|
|
This macro controls calling conventions for C++11 and GCC/Clang-style
|
|
compilers.
|
|
|
|
// @refEnd VKAPI_ATTR VKAPI_CALL VKAPI_PTR
|
|
|
|
// @refBegin VKAPI_CALL Vulkan function calling conventions
|
|
|
|
dname:VKAPI_CALL is a macro placed after the return type in Vulkan API
|
|
function declarations.
|
|
This macro controls calling conventions for MSVC-style compilers.
|
|
|
|
// @refEnd VKAPI_CALL VKAPI_ATTR VKAPI_PTR
|
|
|
|
// @refBegin VKAPI_PTR Vulkan function pointer calling conventions
|
|
|
|
dname:VKAPI_PTR is a macro placed between the '(' and '*' in Vulkan API
|
|
function pointer declarations.
|
|
This macro also controls calling conventions, and typically has the same
|
|
definition as dname:VKAPI_ATTR or dname:VKAPI_CALL, depending on the
|
|
compiler.
|
|
|
|
// @refEnd VKAPI_PTR VKAPI_ATTR VKAPI_CALL
|
|
|
|
With these macros, a Vulkan function declaration takes the form of:
|
|
|
|
[source,c++]
|
|
----------------------------------------
|
|
VKAPI_ATTR <return_type> VKAPI_CALL <command_name>(<command_parameters>);
|
|
----------------------------------------
|
|
|
|
Additionaly, a Vulkan function pointer type declaration takes the form of:
|
|
|
|
[source,c++]
|
|
----------------------------------------
|
|
typedef <return_type> (VKAPI_PTR *PFN_<command_name>)(<command_parameters>);
|
|
----------------------------------------
|
|
|
|
|
|
==== Platform-Specific Header Control
|
|
|
|
// @refBegin VK_NO_STDINT_H Control definition of `<stdint.h>` types
|
|
|
|
If the code:VK_NO_STDINT_H macro is defined by the application at compile
|
|
time, extended integer types used by the Vulkan API, such as code:uint8_t,
|
|
must: also be defined by the application.
|
|
Otherwise, the Vulkan headers will not compile.
|
|
If code:VK_NO_STDINT_H is not defined, the system `<stdint.h>` is used to
|
|
define these types.
|
|
There is a fallback path when Microsoft Visual Studio version 2008 and
|
|
earlier versions are detected at compile time.
|
|
|
|
// @refEnd VK_NO_STDINT_H
|
|
|
|
|
|
[[boilerplate-vulkan-core]]
|
|
=== Vulkan Core API Header `vulkan_core.h`
|
|
|
|
Applications that do not make use of window system-specific extensions may
|
|
simply include `vulkan_core.h` instead of `vulkan.h`, although there is
|
|
usually no reason to do so.
|
|
In addition to the Vulkan API, `vulkan_core.h` also defines a small number
|
|
of C preprocessor macros that are described below.
|
|
|
|
|
|
[[boilerplate-versions]]
|
|
==== Vulkan Version Number Macros
|
|
|
|
<<fundamentals-versionnum,API Version Numbers>> are packed into integers.
|
|
These macros manipulate version numbers in useful ways.
|
|
|
|
[open,refpage='VK_VERSION_MAJOR',desc='Extract API major version number',type='defines']
|
|
--
|
|
|
|
dname:VK_VERSION_MAJOR extracts the API major version number from a packed
|
|
version number:
|
|
|
|
include::../api/defines/VK_VERSION_MAJOR.txt[]
|
|
|
|
--
|
|
|
|
[open,refpage='VK_VERSION_MINOR',desc='Extract API minor version number',type='defines']
|
|
--
|
|
|
|
dname:VK_VERSION_MINOR extracts the API minor version number from a packed
|
|
version number:
|
|
|
|
include::../api/defines/VK_VERSION_MINOR.txt[]
|
|
|
|
--
|
|
|
|
[open,refpage='VK_VERSION_PATCH',desc='Extract API patch version number',type='defines']
|
|
--
|
|
|
|
dname:VK_VERSION_PATCH extracts the API patch version number from a packed
|
|
version number:
|
|
|
|
include::../api/defines/VK_VERSION_PATCH.txt[]
|
|
|
|
--
|
|
|
|
[open,refpage='VK_API_VERSION_1_0',desc='Return API version number for Vulkan 1.0',type='defines',xrefs='vkCreateInstance vkGetPhysicalDeviceProperties']
|
|
--
|
|
|
|
dname:VK_API_VERSION_1_0 returns the API version number for Vulkan 1.0.
|
|
The patch version number in this macro will always be zero.
|
|
The supported patch version for a physical device can: be queried with
|
|
flink:vkGetPhysicalDeviceProperties.
|
|
|
|
include::../api/defines/VK_API_VERSION_1_0.txt[]
|
|
|
|
--
|
|
|
|
ifdef::VK_VERSION_1_1[]
|
|
[open,refpage='VK_API_VERSION_1_1',desc='Return API version number for Vulkan 1.1',type='defines',xrefs='vkCreateInstance vkGetPhysicalDeviceProperties']
|
|
--
|
|
|
|
dname:VK_API_VERSION_1_1 returns the API version number for Vulkan 1.1.
|
|
The patch version number in this macro will always be zero.
|
|
The supported patch version for a physical device can: be queried with
|
|
flink:vkGetPhysicalDeviceProperties.
|
|
|
|
include::../api/defines/VK_API_VERSION_1_1.txt[]
|
|
|
|
--
|
|
endif::VK_VERSION_1_1[]
|
|
|
|
[open,refpage='VK_API_VERSION',desc='Deprecated version number macro',type='defines']
|
|
--
|
|
|
|
dname:VK_API_VERSION is now commented out of `vulkan_core.h` and cannot: be
|
|
used.
|
|
|
|
include::../api/defines/VK_API_VERSION.txt[]
|
|
|
|
--
|
|
|
|
[open,refpage='VK_MAKE_VERSION',desc='Construct an API version number',type='defines',xrefs='VkApplicationInfo vkCreateInstance']
|
|
--
|
|
|
|
dname:VK_MAKE_VERSION constructs an API version number.
|
|
|
|
include::../api/defines/VK_MAKE_VERSION.txt[]
|
|
|
|
* pname:major is the major version number.
|
|
* pname:minor is the minor version number.
|
|
* pname:patch is the patch version number.
|
|
|
|
This macro can: be used when constructing the
|
|
slink:VkApplicationInfo::pname:apiVersion parameter passed to
|
|
flink:vkCreateInstance.
|
|
|
|
--
|
|
|
|
|
|
==== Vulkan Header File Version Number
|
|
|
|
[open,refpage='VK_HEADER_VERSION',desc='Vulkan header file version number',type='defines']
|
|
--
|
|
|
|
dname:VK_HEADER_VERSION is the version number of the `vulkan_core.h` header.
|
|
This value is kept synchronized with the patch version of the released
|
|
Specification.
|
|
|
|
include::../api/defines/VK_HEADER_VERSION.txt[]
|
|
|
|
--
|
|
|
|
|
|
==== Vulkan Handle Macros
|
|
|
|
[open,refpage='VK_DEFINE_HANDLE',desc='Declare a dispatchable object handle',type='defines',xrefs='VkCommandBuffer VkDevice VkInstance VkPhysicalDevice VkQueue']
|
|
--
|
|
|
|
dname:VK_DEFINE_HANDLE defines a <<fundamentals-objectmodel-overview,
|
|
dispatchable handle>> type.
|
|
|
|
include::../api/defines/VK_DEFINE_HANDLE.txt[]
|
|
|
|
* pname:object is the name of the resulting C type.
|
|
|
|
The only dispatchable handle types are those related to device and instance
|
|
management, such as slink:VkDevice.
|
|
|
|
--
|
|
|
|
[open,refpage='VK_DEFINE_NON_DISPATCHABLE_HANDLE',desc='Declare a non-dispatchable object handle',type='defines',xrefs='VkBuffer']
|
|
--
|
|
|
|
dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE defines a
|
|
<<fundamentals-objectmodel-overview, non-dispatchable handle>> type.
|
|
|
|
include::../api/defines/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt[]
|
|
|
|
* pname:object is the name of the resulting C type.
|
|
|
|
Most Vulkan handle types, such as slink:VkBuffer, are non-dispatchable.
|
|
|
|
[NOTE]
|
|
.Note
|
|
====
|
|
The `vulkan_core.h` header allows the
|
|
dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE definition to be overridden by the
|
|
application.
|
|
If dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE is already defined when
|
|
`vulkan_core.h` is compiled, the default definition is skipped.
|
|
This allows the application to define a binary-compatible custom handle
|
|
which may: provide more type-safety or other features needed by the
|
|
application.
|
|
Behavior is undefined if the application defines a non-binary-compatible
|
|
handle and may: result in memory corruption or application termination.
|
|
Binary compatibility is platform dependent so the application must: be
|
|
careful if it overrides the default dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE
|
|
definition.
|
|
====
|
|
|
|
--
|
|
|
|
[open,refpage='VK_NULL_HANDLE',desc='Reserved non-valid object handle',type='defines']
|
|
--
|
|
|
|
dname:VK_NULL_HANDLE is a reserved value representing a non-valid object
|
|
handle.
|
|
It may be passed to and returned from Vulkan commands only when
|
|
<<fundamentals-validusage-handles, specifically allowed>>.
|
|
|
|
include::../api/defines/VK_NULL_HANDLE.txt[]
|
|
|
|
--
|
|
|
|
|
|
[[boilerplate-wsi-header]]
|
|
== Window System-Specific Header Control (Informative)
|
|
|
|
// @refBegin WSIheaders Control inclusion of window system interface extensions
|
|
|
|
To use a Vulkan extension supporting a platform-specific window system,
|
|
header files for that window systems must: be included at compile time, or
|
|
platform-specific types must: be forward-declared.
|
|
The Vulkan header files cannot determine whether or not an external header
|
|
is available at compile time, so platform-specific extensions are provided
|
|
in separate headers from the core API and platform-independent extensions,
|
|
allowing applications to decide which ones should be defined and how the
|
|
external headers are included.
|
|
|
|
Extensions dependent on particular sets of platform headers, or that
|
|
forward-declare platform-specific types, are declared in a header named for
|
|
that platform.
|
|
Before including these platform-specific Vulkan headers, applications must:
|
|
include both `vulkan_core.h` and any external native headers the platform
|
|
extensions depend on.
|
|
|
|
As a convenience for applications that do not need the flexibility of
|
|
separate platform-specific Vulkan headers, `vulkan.h` includes
|
|
`vulkan_core.h`, and then conditionally includes platform-specific Vulkan
|
|
headers and the external headers they depend on.
|
|
Applications control which platform-specific headers are included by
|
|
#defining macros before including `vulkan.h`.
|
|
|
|
The correspondence between platform-specific extensions, external headers
|
|
they require, the platform-specific header which declares them, and the
|
|
preprocessor macros which enable inclusion by `vulkan.h` are shown in the
|
|
<<boilerplate-wsi-header-table,following table>>.
|
|
|
|
[[boilerplate-wsi-header-table]]
|
|
.Window System Extensions and Headers
|
|
[options="header"]
|
|
|====
|
|
| Extension Name | Window System Name | Platform-specific Header | Required External Headers | Controlling `vulkan.h` Macro
|
|
| `<<VK_KHR_android_surface>>` | Android | `vulkan_android.h` | None | dname:VK_USE_PLATFORM_ANDROID_KHR
|
|
| `<<VK_KHR_mir_surface>>` | Mir | `vulkan_mir.h` | `<mir_toolkit/client_types.h>` | dname:VK_USE_PLATFORM_MIR_KHR
|
|
| `<<VK_KHR_wayland_surface>>` | Wayland | `vulkan_wayland.h` | `<wayland-client.h>` | dname:VK_USE_PLATFORM_WAYLAND_KHR
|
|
| `<<VK_KHR_win32_surface>>`,
|
|
`<<VK_KHR_external_memory_win32>>`,
|
|
`<<VK_KHR_win32_keyed_mutex>>`,
|
|
`<<VK_KHR_external_semaphore_win32>>`,
|
|
`<<VK_KHR_external_fence_win32>>`,
|
|
ifdef::VK_NV_external_memory_win32[]
|
|
`<<VK_NV_external_memory_win32>>`,
|
|
endif::VK_NV_external_memory_win32[]
|
|
ifdef::VK_NV_win32_keyed_mutex[]
|
|
`<<VK_NV_win32_keyed_mutex>>`
|
|
endif::VK_NV_win32_keyed_mutex[]
|
|
| Microsoft Windows | `vulkan_win32.h` | `<windows.h>` | dname:VK_USE_PLATFORM_WIN32_KHR
|
|
| `<<VK_KHR_xcb_surface>>` | X11 Xcb | `vulkan_xcb.h` | `<xcb/xcb.h>` | dname:VK_USE_PLATFORM_XCB_KHR
|
|
| `<<VK_KHR_xlib_surface>>` | X11 Xlib | `vulkan_xlib.h` | `<X11/Xlib.h>` | dname:VK_USE_PLATFORM_XLIB_KHR
|
|
ifdef::VK_EXT_acquire_xlib_display[]
|
|
| `<<VK_EXT_acquire_xlib_display>>` | X11 XRAndR | `vulkan_xlib_xrandr.h` | `<X11/Xlib.h>`,
|
|
`<X11/extensions/Xrandr.h>` | dname:VK_USE_PLATFORM_XLIB_XRANDR_EXT
|
|
endif::VK_EXT_acquire_xlib_display[]
|
|
ifdef::VK_MVK_ios_surface[]
|
|
| `<<VK_MVK_ios_surface>>` | iOS | `vulkan_ios.h` | None | dname:VK_USE_PLATFORM_IOS_MVK
|
|
endif::VK_MVK_ios_surface[]
|
|
ifdef::VK_MVK_macos_surface[]
|
|
| `<<VK_MVK_macos_surface>>` | macOS | `vulkan_macos.h` | None | dname:VK_USE_PLATFORM_MACOS_MVK
|
|
endif::VK_MVK_macos_surface[]
|
|
ifdef::VK_NN_vi_surface[]
|
|
| `<<VK_NN_vi_surface>>` | VI | `vulkan_vi.h` | None | dname:VK_USE_PLATFORM_VI_NN
|
|
endif::VK_NN_vi_surface[]
|
|
|====
|
|
|
|
[NOTE]
|
|
.Note
|
|
====
|
|
This section describes the purpose of the headers independently of the
|
|
specific underlying functionality of the window system extensions
|
|
themselves.
|
|
Each extension name will only link to a description of that extension when
|
|
viewing a specification built with that extension included.
|
|
====
|
|
|
|
// @refEnd WSIheaders
|