status-im
/
Vulkan-Docs
mirror of https://github.com/status-im/Vulkan-Docs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Change log for April 29, 2016 Vulkan 1.0.12 spec update: 

* Bump API patch number and header version number to 12 for this
    update.

Github Issues:

  * Change valid usage statements intended to be "sub-points" to
    be actual sub-points (public issue 66).
  * Replace double negation in description of
    slink:VkRenderPassBeginInfo::pname:pClearValues (based on public
    merge 142).
  * Cleanup minor typos in spec, ref pages and XML, including those
    proposed in public pull requests 144, 150, 151, 167, 168, 181, and
    186.
  * Use *strict subset* in describing the partial order of memory
    property types for slink:VkMemoryType, and update the style guide
    accordingly (public issue 190).
  * Fix various "a image" -> "an image" typos (public issue 191).
  * Note in the <<fundamentals-validusage,Valid Usage>> and
    <<extensions-interactions,Extension Interactions>> sections that
    structures defined by extensions which may be passed in structure
    chains using the ptext:pNext member must: include initial
    ptext:sType and ptext:pNext members (public issue 192).

Internal Issues:

  * Remove duplicate language from the description of the pname:fence
    parameter to flink:vkQueueSubmit and improve validity language
    (internal issue 91).
  * Added documentation for "optional" attribute to XML readme.tex/pdf
    (internal issue 149).
  * Clarify the host-side data validity rules and behavior of
    flink:vkFlushMappedMemoryRanges and
    flink:vkInvalidateMappedMemoryRanges (internal issue 266).

Other Commits:

  * Added clarification to flink:vkCmdFillBuffer regarding the use of
    ename:VK_WHOLE_SIZE.
  * Fixed and documented implementation of "validextensionstructs"
    attribute. in XML processing scripts and readme.tex/pdf.
  * Add missing validity statements to flink:vkResetEvent and
    flink:vkCmdResetEvent.
  * Fix validity for the
    ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag.
    Correct all the draw/dispatch commands to mention optimally tiled
    images as well as linear tiled images, and say image VIEWS instead
    of images. Add validity statement to flink:vkCmdBlitImage
  * Replace the {apiname} macro with hardcoded "Vulkan", now that we've
    committed to that name.
  * Add the VK_AMD_rasterization_order extension to vk.xml.
This commit is contained in:
Jon Leech 2016-04-29 14:53:46 +02:00
parent 6db51e9241
commit 75bbb5f4d5
69 changed files with 2270 additions and 1453 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
ChangeLog.txt
View File

@ -526,3 +526,57 @@ Other Commits:
on relevant script/XML/header files. This does not affect the
specification source copyright.
-----------------------------------------------------
Change log for April 29, 2016 Vulkan 1.0.12 spec update:
* Bump API patch number and header version number to 12 for this
update.
Github Issues:
* Change valid usage statements intended to be "sub-points" to
be actual sub-points (public issue 66).
* Replace double negation in description of
slink:VkRenderPassBeginInfo::pname:pClearValues (based on public
merge 142).
* Cleanup minor typos in spec, ref pages and XML, including those
proposed in public pull requests 144, 150, 151, 167, 168, 181, and
186.
* Use *strict subset* in describing the partial order of memory
property types for slink:VkMemoryType, and update the style guide
accordingly (public issue 190).
* Fix various "a image" -> "an image" typos (public issue 191).
* Note in the <<fundamentals-validusage,Valid Usage>> and
<<extensions-interactions,Extension Interactions>> sections that
structures defined by extensions which may be passed in structure
chains using the ptext:pNext member must: include initial
ptext:sType and ptext:pNext members (public issue 192).
Internal Issues:
* Remove duplicate language from the description of the pname:fence
parameter to flink:vkQueueSubmit and improve validity language
(internal issue 91).
* Added documentation for "optional" attribute to XML readme.tex/pdf
(internal issue 149).
* Clarify the host-side data validity rules and behavior of
flink:vkFlushMappedMemoryRanges and
flink:vkInvalidateMappedMemoryRanges (internal issue 266).
Other Commits:
* Added clarification to flink:vkCmdFillBuffer regarding the use of
ename:VK_WHOLE_SIZE.
* Fixed and documented implementation of "validextensionstructs"
attribute. in XML processing scripts and readme.tex/pdf.
* Add missing validity statements to flink:vkResetEvent and
flink:vkCmdResetEvent.
* Fix validity for the
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag.
Correct all the draw/dispatch commands to mention optimally tiled
images as well as linear tiled images, and say image VIEWS instead
of images. Add validity statement to flink:vkCmdBlitImage
* Replace the {apiname} macro with hardcoded "Vulkan", now that we've
committed to that name.
* Add the VK_AMD_rasterization_order extension to vk.xml.

7
doc/specs/vulkan/Makefile
View File

@ -26,7 +26,6 @@ allchecks: checkinc checklinks
# Note that the := assignments below are immediate, not deferred, and
# are therefore order-dependent in the Makefile
APINAME=Vulkan
QUIET?=@
ASCIIDOC ?= asciidoc.py
A2X ?= a2x.py
@ -64,14 +63,14 @@ KEEP =
# asciidoc / a2x attributes to set.
# XMLLINT normally unset - to detect problems with intermediate files
# NOTEOPTS sets options controlling which NOTEs are generated
# ATTRIBOPTS sets {apiname} to "Vulkan" and enables MathJax generation
# ATTRIBOPTS sets the api revision and enables MathJax generation
# VKCONF contains Vulkan-specific Asciidoc macros
# ADOCOPTS options for asciidoc->HTML output
# ADOCPDFOPTS options for asciidoc->PDF output via dblatex (not using a2x)
# A2XOPTS options for a2x->{HTML,PDF} output
XMLLINT = --no-xmllint
NOTEOPTS = -a editing-notes -a implementation-guide
ATTRIBOPTS = -a apiname=$(APINAME)@ -a apirevision="$(SPECREVISION)" -a mathjax
ATTRIBOPTS = -a apirevision="$(SPECREVISION)" -a mathjax
VKCONF = config/vkspec.conf
ADOCOPTS = $(ATTRIBOPTS) $(NOTEOPTS) -f config/mathjax-asciidoc.conf \
-f $(VKCONF) $(VERBOSE)
@ -126,7 +125,7 @@ INCLUDES := $(wildcard protos/*.txt structs/*.txt flags/*.txt enums/*.txt funcpo
COMMONDOCS := $(CHAPTERS) $(INCLUDES)
# A generated included file with the spec version, date, and git commit
SPECVERSION = specversion.txt
SPECREVISION = 1.0.11
SPECREVISION = 1.0.12
SPECREMARK =
# Spec targets

2
doc/specs/vulkan/appendices/VK_KHR_sampler_mirror_clamp_to_edge.txt
View File

@ -7,7 +7,7 @@
*Last Modified Date*:: 16/02/2016
*Revision*:: 1
*Dependencies*::
- This extension is written against version 1.0. of the {apiname} API.
- This extension is written against version 1.0. of the Vulkan API.
*Contributors*::
- Tobias Hector, Imagination Technologies
*Contacts*::

6
doc/specs/vulkan/appendices/compressedtex.txt
View File

@ -26,7 +26,7 @@ Format Specification.
[[appendix-compressedtex-bc]]
== Block-Compressed Image Formats
.Mapping of {apiname} BC formats to descriptions
.Mapping of Vulkan BC formats to descriptions
[width="90%",options="header",cols="5,4"]
|==============================
| VkFormat | Data Format Specification description
@ -59,7 +59,7 @@ Format Specification.
The following formats are described in the ``ETC2 Compressed Texture Image
Formats'' chapter of the Khronos Data Format Specification.
.Mapping of {apiname} ETC formats to descriptions
.Mapping of Vulkan ETC formats to descriptions
[options="header",cols="1,1"]
|==============================
| VkFormat | Data Format Specification description
@ -83,7 +83,7 @@ Formats'' chapter of the Khronos Data Format Specification.
ASTC formats are described in the ``ASTC Compressed Texture Image Formats''
chapter of the Khronos Data Format Specification.
.Mapping of {apiname} ASTC formats to descriptions
.Mapping of Vulkan ASTC formats to descriptions
[width="75%",options="header",cols="63%,15%,22%"]
|==============================
| VkFormat ^| Compressed texel block dimensions ^| sRGB-encoded

86
doc/specs/vulkan/appendices/extensions.txt
View File

@ -6,9 +6,9 @@
[[extensions]]
= Layers & Extensions
Extensions to the {apiname} API can: be defined by authors, groups of
authors, and the Khronos {apiname} Working Group. In order not to compromise
the readability of the {apiname} Specification, the core Specification does
Extensions to the Vulkan API can: be defined by authors, groups of
authors, and the Khronos Vulkan Working Group. In order not to compromise
the readability of the Vulkan Specification, the core Specification does
not incorporate most extensions. The online registry of extensions is
available at URL
@ -41,7 +41,7 @@ several purposes:
* Provides a central repository for documentation and header changes
associated with extensions
{apiname}'s design and general software development trends introduces two
Vulkan's design and general software development trends introduces two
new paradigms that require rethinking the existing mechanisms:
* Layers, and with them a focus on a more open ecosystem where non-Khronos
@ -63,7 +63,7 @@ Some general rules to simplify the specific rules below:
* All extensions must: be registered with Khronos.
* Extensions must: be strictly additive and backwards-compatible. That is,
extensions mustnot: remove existing functionality, or change existing
default behaviors. A {apiname} implementation may: support any
default behaviors. A Vulkan implementation may: support any
combination of extensions, but applications written using only the core
API, or a subset of the supported extensions, must: continue to work in
such an implementation without changes in behavior.
@ -78,8 +78,8 @@ Both extensions and layer names include a +VK_+ prefix. In addition, layers
add a +LAYER_+ prefix. Extension and layer names also contain an _author
prefix_ identifying the author of the extension/layer. This prefix is a
short, capitalized, registered string identifying an author, such as a
Khronos member developing {apiname} implementations for their devices, or a
non-Khronos developer creating {apiname} layers.
Khronos member developing Vulkan implementations for their devices, or a
non-Khronos developer creating Vulkan layers.
Some authors have platform communities they wish to distinguish between, and
can: register additional author prefixes for that purpose. For example,
@ -98,7 +98,7 @@ only for layers.
will use the prefix +VK_KHR_+.
** The following author prefixes are reserved and mustnot: be used:
*** +VK+ - To avoid confusion with the top-level +VK_+ prefix.
*** +VULKAN+ - To avoid confusion with the name of the {apiname} API.
*** +VULKAN+ - To avoid confusion with the name of the Vulkan API.
*** +LAYER+ - To avoid confusion with the higher-level ``LAYER'' prefix.
*** +KHRONOS+ - To avoid confusion with the Khronos organization.
** Multi-author extensions that have not been ratified by Khronos (those
@ -143,7 +143,7 @@ browser.
== Extension Command, Type, and Token Naming Conventions
Extensions may: add new commands, types, and tokens, or collectively
``objects'', to the {apiname} API. These objects are given globally unique
``objects'', to the Vulkan API. These objects are given globally unique
names by appending the author prefix defined above for the extension name
according to the following templates.
@ -184,10 +184,10 @@ enum VkSomeValuesGRPHX {
[[extensions-api-registry]]
== The {apiname} Registry
== The Vulkan Registry
The canonical definition of the {apiname} APIs is kept in an XML file known
as the *{apiname} registry*. The registry is kept in +src/spec/vk.xml+ in
The canonical definition of the Vulkan APIs is kept in an XML file known
as the *Vulkan registry*. The registry is kept in +src/spec/vk.xml+ in
the branch of the vulkan project containing the most recently released core
API specification. The registry contains reserved author prefixes, core and
extension interface definitions, definitions of individual commands and
@ -202,7 +202,7 @@ documentation used in generating the API specification and reference pages.
== Registering an Author Prefix with Khronos
Previous Khronos APIs could only officially be modified by Khronos members.
In an effort to build a more flexible platform, {apiname} allows non-Khronos
In an effort to build a more flexible platform, Vulkan allows non-Khronos
developers to extend and modify the API via layers and extensions in the
same manner as Khronos members. However, extensions must: still be
registered with Khronos. A mechanism for non-members to register layers and
@ -222,7 +222,7 @@ contact email address, respectively. The author prefix will be reserved only
once this merge request is accepted.
Please do not try to reserve author names which clearly belong to another
existing company or software project which may: wish to develop {apiname}
existing company or software project which may: wish to develop Vulkan
extensions or layers in the future, as a matter of courtesy and respect.
Khronos may: decline to register author names that are not requested in good
faith.
@ -231,7 +231,7 @@ faith.
[[extensions-vendor-id]]
== Registering a Vendor ID with Khronos
{apiname} implementers must report a valid vendor ID for their
Vulkan implementers must report a valid vendor ID for their
implementation, as reported by
<<devsandqueues-physical-device-enumeration,physical device queries>>. If
there is no valid PCI vendor ID defined for the physical device,
@ -251,7 +251,7 @@ available ID in the list of +<vendorid>+ tags. The vendor ID will be
reserved only once this merge request has been accepted.
Please do not try to reserve vendor IDs unless you are making a good faith
effort to develop a {apiname} implementation and require one for that
effort to develop a Vulkan implementation and require one for that
purpose.
@ -264,7 +264,7 @@ registration is strongly recommended. Registration means:
* Adding the extension or layer name to the list in +vk.xml+ and appearing
on the Khronos registry website, which will link to associated
documentation hosted on Khronos.
* For extensions which add to the {apiname} API, including definitions of
* For extensions which add to the Vulkan API, including definitions of
those additions to +vk.xml+.
Registration for Khronos members is handled by filing a merge request in the
@ -298,7 +298,7 @@ extension number assignment prior to extension publication:
* Develop and test the extension using the registered extension number.
* Publish the extension to Khronos using the previously registered
extension number, by creating a branch of the repository with
appropriate changes relative to the core {apiname} API branch.
appropriate changes relative to the core Vulkan API branch.
* Mark the extension as enabled, by proposing a merge to master changing
the +supported+ attribute value of the +<extension>+ to
+supported="vulkan"+. This should: be completely automated and under the
@ -326,15 +326,15 @@ endif::editing-notes[]
== Documenting Extensions
Extensions are documented as modifications to the {apiname} specification.
Extensions are documented as modifications to the Vulkan specification.
These modifications will be on Git branches that are named with the
following syntax: +<major.minor core spec version>-<extension_name>+
For example, the VK_KHR_surface extension will be documented relative
to version 1.0 of the {apiname} specification. As such, the branch name will
to version 1.0 of the Vulkan specification. As such, the branch name will
be: +1.0-VK_KHR_surface+
If the extension modifies an existing section of the {apiname}
If the extension modifies an existing section of the Vulkan
specification, those modifications are made in-place. Since the changes are
on a branch, the core-only specification can: be easily produced. A
specification with an extension is created by merging in the extension's
@ -347,7 +347,7 @@ higher-numbered extension should: take care to deal with any conflicts.
The WSI extensions were used to help pioneer what should: be done for
extensions. This includes the following:
* All extensions should: add to the appendix of the {apiname}
* All extensions should: add to the appendix of the Vulkan
specification. This should: be modeled after what was done for the
+VK_KHR_surface+ extension, which contains some high-level information
about the extension (as well as code examples, and revision history) in
@ -360,12 +360,12 @@ extensions. This includes the following:
multiple extensions' branches are merged in order to create the ``full''
branch specification.
* If there are any other places where 2 or more extensions will extend the
{apiname} specification, it is best to put that content in a file, and
Vulkan specification, it is best to put that content in a file, and
use an +include+ statement to put that content into the spec. Again,
this +include+ line should: be put on the master branch in order to
avoid merge conflicts.
* If an extension is more of an addition to the {apiname} specification,
the extension should: add a chapter to the {apiname} specification.
* If an extension is more of an addition to the Vulkan specification,
the extension should: add a chapter to the Vulkan specification.
== Assigning Extension Token Values
@ -443,7 +443,7 @@ all extensions must: define two additional tokens.
extension specification, and is incremented when significant changes
(bugfixes or added functionality) are made. Note that the revision of an
extension defined in +vulkan.h+ and the revision supported by the
{apiname} implementation (the pname:specVersion field of the
Vulkan implementation (the pname:specVersion field of the
slink:VkExtensionProperties structure corresponding to the extension and
returned by one of the <<extended-functionality-extensions,extension
queries>>) may: differ. In such cases, only the functionality and
@ -472,7 +472,7 @@ be included in the +vulkan.h+ header supplied by Khronos.
.Note
====
Application developers are encouraged to be careful when using +switch+
statements with {apiname} API enums. This is because extensions can: add new
statements with Vulkan API enums. This is because extensions can: add new
values to existing enums. The use of a +default:+ statement, within a
+switch+, may: avoid future compilation issues.
====
@ -481,23 +481,23 @@ values to existing enums. The use of a +default:+ statement, within a
[[extension-function_prototypes]]
== Extension Function Prototypes
Function pointer declarations and function prototypes for all core {apiname}
Function pointer declarations and function prototypes for all core Vulkan
API commands are included in the +vulkan.h+ file. These come from the
official XML specification of the {apiname} API hosted by Khronos.
official XML specification of the Vulkan API hosted by Khronos.
Function pointer declarations are also included in the +vulkan.h+ file for
all commands defined by registered extensions. Function prototypes for
extensions may: be included in +vulkan.h+. Extension commands that are part
of the {apiname} ABI must: be flagged in the XML. Function prototypes will
of the Vulkan ABI must: be flagged in the XML. Function prototypes will
be included in +vulkan.h+ for all extension commands that are part of the
{apiname} ABI.
Vulkan ABI.
An extension can: be considered platform specific, in which case its
interfaces in +vulkan.h+ are protected by #ifdefs. This is orthogonal to
whether an extension command is considered to be part of the {apiname} ABI.
whether an extension command is considered to be part of the Vulkan ABI.
The initial set of WSI extension commands are considered to be part of the
{apiname} ABI. Function prototypes for these WSI commands are included in
Vulkan ABI. Function prototypes for these WSI commands are included in
the +vulkan.h+ provided by Khronos, though the platform-specific portions of
+vulkan.h+ are protected by #ifdefs.
@ -505,7 +505,7 @@ the +vulkan.h+ provided by Khronos, though the platform-specific portions of
.Note
====
Based on feedback from implementers, Khronos expects that the Android,
Linux, and Windows {apiname} SDKs will include our +vulkan.h+ and export
Linux, and Windows Vulkan SDKs will include our +vulkan.h+ and export
the supported WSI functions for those platforms from their loader
libraries. Other implementations can: make different choices for their
headers and loader libraries, but are encouraged to be consistent with
@ -518,8 +518,8 @@ these implementations.
flink:vkGetInstanceProcAddr and flink:vkGetDeviceProcAddr can: be used in
order to obtain function pointer addresses for core and extension commands
(per the description in <<initialization-functionpointers,Command Function
Pointers>>). Different {apiname} API loaders can: choose to statically
export functions for some or all of the core {apiname} API commands, and
Pointers>>). Different Vulkan API loaders can: choose to statically
export functions for some or all of the core Vulkan API commands, and
can: statically export functions for some or all extension commands. If a
loader statically exports a function, an application can: link against that
function without needing to call one of the ftext:vkGet*ProcAddr commands.
@ -527,8 +527,8 @@ function without needing to call one of the ftext:vkGet*ProcAddr commands.
[NOTE]
.Note
====
The Khronos-provided {apiname} API loader for Android, Linux, and Windows
exports functions for all core {apiname} API and WSI extension commands. The
The Khronos-provided Vulkan API loader for Android, Linux, and Windows
exports functions for all core Vulkan API and WSI extension commands. The
WSI functions are considered special, because they are required for many
applications.
====
@ -556,6 +556,7 @@ defined and locked down, it's safest to refer to the listed contact.
====
[[extensions-interactions]]
== Extension Interactions
Extensions modifying the behavior of existing commands should: provide
@ -563,7 +564,14 @@ additional parameters by using the pname:pNext field of an existing
structure, pointing to a new structure defined by the extension, as
described in the <<fundamentals-validusage,Valid Usage>> section. Extension
structures defined by multiple extensions affecting the same structure can
be chained together in this fashion.
be chained together in this fashion. Any structure which can: be chained
in this fashion must: begin with the following two members:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
VkStructureType sType;
const void* pNext;
------------------------------------------------------------------------------
It is in principle possible for extensions to provide additional parameters
through alternate means, such as passing a handle parameter to a structure

14
doc/specs/vulkan/appendices/glossary.txt
View File

@ -216,7 +216,7 @@ Device-Local Memory::
Dispatchable Handle::
A handle of a pointer handle type which may: be used by layers as part
of intercepting API commands. The first argument to each {apiname}
of intercepting API commands. The first argument to each Vulkan
command is a dispatchable handle type.
Dispatching Commands::
@ -229,7 +229,7 @@ Drawing Commands::
flink:vkCmdDrawIndexedIndirect.
Duration (Command)::
The _duration_ of a {apiname} command refers to the interval between
The _duration_ of a Vulkan command refers to the interval between
calling the command and its return to the caller.
Dynamic Storage Buffer::
@ -314,7 +314,7 @@ Global Workgroup::
A collection of local workgroups dispatched by a single dispatch command.
Handle::
An opaque integer or pointer value used to refer to a {apiname} object.
An opaque integer or pointer value used to refer to a Vulkan object.
Each object type has a unique handle type.
Happen-after::
@ -378,7 +378,7 @@ Immutable Sampler::
the layout, and cannot be changed.
Implicitly-Enabled Layer::
A layer enabled by a loader-defined mechanism outside the {apiname} API,
A layer enabled by a loader-defined mechanism outside the Vulkan API,
rather than explicitly by the application during instance or device
creation.
@ -402,7 +402,7 @@ Input Attachment::
view.
Instance::
The top-level {apiname} object, which represents the application's
The top-level Vulkan object, which represents the application's
connection to the implementation. Represented by a sname:VkInstance
object.
@ -427,7 +427,7 @@ Local Workgroup::
Logical Device::
An object that represents the application's interface to the physical
device. The logical device is the parent of most {apiname} objects.
device. The logical device is the parent of most Vulkan objects.
Represented by a sname:VkDevice object.
Logical Operation::
@ -802,7 +802,7 @@ A::
= Prefixes
Prefixes are used in the API to denote specific semantic meaning of
{apiname} names, or as a label to avoid name clashes, and are explained
Vulkan names, or as a label to avoid name clashes, and are explained
here:
VK/Vk/vk::

36
doc/specs/vulkan/appendices/invariance.txt
View File

@ -4,8 +4,8 @@
[appendix]
= Invariance
The {apiname} specification is not pixel exact. It therefore does not
guarantee an exact match between images produced by different {apiname}
The Vulkan specification is not pixel exact. It therefore does not
guarantee an exact match between images produced by different Vulkan
implementations. However, the specification does specify exact matches, in
some cases, for images produced by the same implementation. The purpose of
this appendix is to identify and provide justification for those cases that
@ -14,10 +14,10 @@ require exact matches.
== Repeatability
The obvious and most fundamental case is repeated issuance of a series of
{apiname} commands. For any given {apiname} and framebuffer state vector,
and for any {apiname} command, the resulting {apiname} and framebuffer state
Vulkan commands. For any given Vulkan and framebuffer state vector,
and for any Vulkan command, the resulting Vulkan and framebuffer state
must: be identical whenever the command is executed on that initial
{apiname} and framebuffer state. This repeatability requirement doesn't
Vulkan and framebuffer state. This repeatability requirement doesn't
apply when using shaders containing side effects (image and buffer variable
stores and atomic operations), because these memory operations are not
guaranteed to be processed in a defined order.
@ -38,7 +38,7 @@ Additional invariance rules are desirable to ensure useful operation.
== Multi-pass Algorithms
Invariance is necessary for a whole set of useful multi-pass algorithms.
Such algorithms render multiple times, each time with a different {apiname}
Such algorithms render multiple times, each time with a different Vulkan
mode vector, to eventually produce a result in the framebuffer. Examples of
these algorithms include:
@ -49,11 +49,11 @@ these algorithms include:
== Invariance Rules
For a given instantiation of an {apiname} rendering context:
For a given instantiation of an Vulkan rendering context:
*Rule 1* _For any given {apiname} and framebuffer state vector, and for any
given {apiname} command, the resulting {apiname} and framebuffer state must:
be identical each time the command is executed on that initial {apiname} and
*Rule 1* _For any given Vulkan and framebuffer state vector, and for any
given Vulkan command, the resulting Vulkan and framebuffer state must:
be identical each time the command is executed on that initial Vulkan and
framebuffer state._
*Rule 2* _Changes to the following state values have no side effects (the
@ -89,7 +89,7 @@ sequence, are pixel identical._
when run multiple times with the same input. The wording ``the same shader''
means a program object that is populated with the same SPIR-V binary, which
is used to create pipelines, possibly multiple times, and which program
object is then executed using the same {apiname} state vector. Invariance is
object is then executed using the same Vulkan state vector. Invariance is
relaxed for shaders with side effects, such as performing stores or
atomics._
@ -98,19 +98,19 @@ assign_ code:FragCoord.z _to_ code:FragDepth _are depth-invariant with
respect to each other, for those fragments where the assignment to_
code:FragDepth _actually is done._
If a sequence of {apiname} commands specifies primitives to be rendered with
If a sequence of Vulkan commands specifies primitives to be rendered with
shaders containing side effects (image and buffer variable stores and atomic
operations), invariance rules are relaxed. In particular, rule 1, corollary
2, and rule 4 do not apply in the presence of shader side effects.
The following weaker versions of rules 1 and 4 apply to {apiname} commands
The following weaker versions of rules 1 and 4 apply to Vulkan commands
involving shader side effects:
*Rule 6* _For any given {apiname} and framebuffer state vector, and for any
given {apiname} command, the contents of any framebuffer state not directly
*Rule 6* _For any given Vulkan and framebuffer state vector, and for any
given Vulkan command, the contents of any framebuffer state not directly
or indirectly affected by results of shader image or buffer variable stores
or atomic operations must: be identical each time the command is executed on
that initial {apiname} and framebuffer state._
that initial Vulkan and framebuffer state._
*Rule 7* _The same vertex or fragment shader will produce the same result
when run multiple times with the same input as long as:_
@ -121,8 +121,8 @@ when run multiple times with the same input as long as:_
* _no shader invocation, or other operation performed to process the
sequence of commands, reads memory written to by an image store._
When any sequence of {apiname} commands triggers shader invocations that
perform image stores or atomic operations, and subsequent {apiname} commands
When any sequence of Vulkan commands triggers shader invocations that
perform image stores or atomic operations, and subsequent Vulkan commands
read the memory written by those shader invocations, these operations must:
be explicitly synchronized.

20
doc/specs/vulkan/appendices/spirvenv.txt
View File

@ -3,16 +3,16 @@
[appendix]
[[spirvenv]]
= {apiname} Environment for SPIR-V
= Vulkan Environment for SPIR-V
Shaders for {apiname} are defined by the <<Khronos SPIR-V Specification>> as
Shaders for Vulkan are defined by the <<Khronos SPIR-V Specification>> as
well as the <<Khronos SPIR-V Extended Instructions for GLSL Specification>>.
This appendix defines additional SPIR-V requirements applying to {apiname}
This appendix defines additional SPIR-V requirements applying to Vulkan
shaders.
== Required Versions and Formats
A {apiname} 1.0 implementation must: support the 1.0 version of SPIR-V and
A Vulkan 1.0 implementation must: support the 1.0 version of SPIR-V and
the 1.0 version of the SPIR-V Extended Instructions for GLSL.
A SPIR-V module passed into flink:vkCreateShaderModule is interpreted as
@ -47,7 +47,7 @@ to that feature must: also be supported.
.SPIR-V Capabilities which are not required:, and corresponding feature names
[options="header"]
|====
| SPIR-V OpCapability | {apiname} feature name
| SPIR-V OpCapability | Vulkan feature name
| code:Geometry | <<features-features-geometryShader,geometryShader>>
| code:Tessellation | <<features-features-tessellationShader,tessellationShader>>
| code:Float64 | <<features-features-shaderFloat64,shaderFloat64>>
@ -81,7 +81,7 @@ following to flink:vkCreateShaderModule:
- any OpCapability not listed above,
- an unsupported capability, or
- a capability which corresponds to a {apiname} feature which has not been
- a capability which corresponds to a Vulkan feature which has not been
enabled.
@ -198,18 +198,18 @@ negative the result is undefined.
.Note
====
While the code:OpSRem and code:OpSMod instructions are supported by the
{apiname} environment, they require non-negative values and thus do not
Vulkan environment, they require non-negative values and thus do not
enable additional functionality beyond what code:OpUMod provides.
====
[[spirvenv-image-formats]]
Compatibility Between SPIR-V Image Formats And {apiname} Formats
----------------------------------------------------------------
Compatibility Between SPIR-V Image Formats And Vulkan Formats
-------------------------------------------------------------
[cols="2*", options="header"]
|===
|SPIR-V Image Format |{apiname} Format
|SPIR-V Image Format |Vulkan Format
|code:Rgba32f |ename:VK_FORMAT_R32G32B32A32_SFLOAT
|code:Rgba16f |ename:VK_FORMAT_R16G16B16A16_SFLOAT
|code:R32f |ename:VK_FORMAT_R32_SFLOAT

4
doc/specs/vulkan/chapters/clears.txt
View File

@ -221,7 +221,9 @@ include::../protos/vkCmdFillBuffer.txt[]
filling, and must: be a multiple of 4.
* pname:size is the number of bytes to fill, and must: be either a
multiple of 4, or ename:VK_WHOLE_SIZE to fill the range from
pname:offset to the end of the buffer.
pname:offset to the end of the buffer. If ename:VK_WHOLE_SIZE is used
and the remaining size of the buffer is not a multiple of 4, then the
nearest smaller multiple is used.
* pname:data is the 4-byte word written repeatedly to the buffer to fill
pname:size bytes of data. The data word is written to memory according
to the host endianness.

35
doc/specs/vulkan/chapters/cmdbuffers.txt
View File

@ -400,25 +400,13 @@ include::../protos/vkQueueSubmit.txt[]
which describe the work to submit. All work described by pname:pSubmits
must: be submitted to the queue before the command returns.
* pname:fence is an optional handle to a fence. If pname:fence is not
code:VK_NULL_HANDLE, the fence is signaled when execution of all
sname:VkSubmitInfo::pname:pCommandBuffers members of pname:pSubmits is
completed. If pname:submitCount is zero but pname:fence is not
code:VK_NULL_HANDLE, the fence will still be submitted to the queue and
will become signaled when all work previously submitted to the queue has
completed.
ifdef::editing-notes[]
[NOTE]
.editing-note
====
(Jon) The description of pname:fence here was added from the ref page
because it was missing from the starting point of MR #1048, which is just
about cleaning up the markup of command parameters. It needs to be resolved
with the description far below of pname:fence, as noted by @jbolz, because
they're not very similar and because most of the second description belongs
in validity XML language.
====
endif::editing-notes[]
code:VK_NULL_HANDLE, the fence is signaled when execution of all command
buffers specified in the sname:VkSubmitInfo::pname:pCommandBuffers
members of pname:pSubmits is complete, providing certain
<<synchronization-implicit-ordering,implicit ordering guarantees>>. If
pname:submitCount is zero but pname:fence is not code:VK_NULL_HANDLE,
the fence will still be submitted to the queue and will become signaled
when all work previously submitted to the queue has completed.
include::../validity/protos/vkQueueSubmit.txt[]
@ -444,7 +432,7 @@ signalled before executing any work, followed by a number of command buffers
that will be executed, and finally, zero or more semaphores that will be
signaled after command buffer execution completes. Each batch is represented
as an instance of the slink:VkSubmitInfo structure stored in an array, the
address of which is passed in pname:pSubmitInfo.
address of which is passed in pname:pSubmits.
The sname:VkSubmitInfo structure is defined as:
@ -473,13 +461,6 @@ include::../structs/VkSubmitInfo.txt[]
include::../validity/structs/VkSubmitInfo.txt[]
If pname:fence is provided, it must: be in the unsignaled state (see
<<synchronization-fences,Fences>>) and a fence must: only be associated with
a single submission until that submission completes, and the fence is
subsequently reset. When all command buffers in pname:pCommandBuffers have
completed execution, the status of pname:fence is set to signaled, providing
certain <<synchronization-implicit-ordering,implicit ordering guarantees>>.
[[commandbuffers-submission-progress]]
== Queue Forward Progress

2
doc/specs/vulkan/chapters/copies.txt
View File

@ -197,7 +197,7 @@ pname:extent.height is not a multiple of the compressed texel block height
then (pname:extent.height + pname:srcOffset.y) must: equal the image
subresource height and if pname:extent.depth is not a multiple of the
compressed texel block depth then (pname:extent.depth + pname:srcOffset.z)
must: equal the image subresource depth. Similarily if the pname:dstImage is
must: equal the image subresource depth. Similarly, if the pname:dstImage is
compressed and if pname:extent.width is not a multiple of the compressed
texel block width then (pname:extent.width + pname:dstOffset.x) must: equal
the image subresource width, if pname:extent.height is not a multiple of the

4
doc/specs/vulkan/chapters/descriptorsets.txt
View File

@ -79,7 +79,7 @@ layout (set=m, binding=n) uniform sampler2D variableNameArray[L];
== Descriptor Types
The following sections outline the various descriptor types supported by
{apiname}. Each section defines a descriptor type, and each descriptor type
Vulkan. Each section defines a descriptor type, and each descriptor type
has a manifestation in the shading language and SPIR-V as well as in
descriptor sets. There is mostly a one-to-one correspondence between
descriptor types and classes of opaque types in the shading language, where
@ -1478,7 +1478,7 @@ include::../validity/protos/vkCmdBindDescriptorSets.txt[]
As described above in section <<descriptorsets-pipelinelayout, Pipeline
Layouts>>, the pipeline layout defines shader push constants which are
updated via {apiname} commands rather than via writes to memory or copy
updated via Vulkan commands rather than via writes to memory or copy
commands.
[NOTE]

22
doc/specs/vulkan/chapters/devsandqueues.txt
View File

@ -4,10 +4,10 @@
[[devsandqueues]]
= Devices and Queues
Once {apiname} is initialized, devices and queues are the primary objects
used to interact with a {apiname} implementation.
Once Vulkan is initialized, devices and queues are the primary objects
used to interact with a Vulkan implementation.
{apiname} separates the concept of _physical_ and _logical_ devices. A
Vulkan separates the concept of _physical_ and _logical_ devices. A
physical device usually represents a single device in a system (perhaps made
up of several individual hardware devices working together), of which there
are a finite number. A logical device represents an application's view of
@ -21,7 +21,7 @@ physical devices installed in the system, call:
include::../protos/vkEnumeratePhysicalDevices.txt[]
* pname:instance is a handle to a {apiname} instance previously created
* pname:instance is a handle to a Vulkan instance previously created
with fname:vkCreateInstance.
* pname:pPhysicalDeviceCount is a pointer to an integer related to the
number of physical devices available or queried, as described below.
@ -60,7 +60,7 @@ The sname:VkPhysicalDeviceProperties structure is defined as:
include::../structs/VkPhysicalDeviceProperties.txt[]
* pname:apiVersion is the version of {apiname} supported by the device,
* pname:apiVersion is the version of Vulkan supported by the device,
encoded as described in the <<fundamentals-versionnum,API Version
Numbers and Semantics>> section.
* pname:driverVersion is the vendor-specified version of the driver.
@ -279,7 +279,7 @@ device exposes a number of _queue families_ each having one or more
_queues_. All queues in a queue family support the same operations.
As described in <<devsandqueues-physical-device-enumeration,Physical
Devices>>, a {apiname} application will first query for all physical devices
Devices>>, a Vulkan application will first query for all physical devices
in a system. Each physical device can: then be queried for its capabilities,
including its queue and queue family properties. Once an acceptable physical
device is identified, an application will create a corresponding logical
@ -418,7 +418,7 @@ error is largely informational and intended only to inform the user that
their hardware has probably developed a fault or become physically
disconnected, and should: be investigated further. In many cases, physical
device loss may: cause other more serious issues such as the operating
system crashing; in which case it may: not be reported via the {apiname}
system crashing; in which case it may: not be reported via the Vulkan
API.
====
@ -482,7 +482,7 @@ include::../validity/protos/vkDestroyDevice.txt[]
To ensure that no work is active on the device, flink:vkDeviceWaitIdle
can: be used to gate the destruction of the device. Prior to destroying a
device, an application is responsible for destroying/freeing any {apiname}
device, an application is responsible for destroying/freeing any Vulkan
objects that were created using that device as the first parameter of the
corresponding ftext:vkCreate* or ftext:vkAllocate* command.
@ -581,7 +581,7 @@ include::../validity/protos/vkGetDeviceQueue.txt[]
[[devsandqueues-index]]
=== Queue Family Index
The queue family index is used in multiple places in {apiname} in order to
The queue family index is used in multiple places in Vulkan in order to
tie operations to a specific family of queues.
When retrieving a handle to the queue via fname:vkGetDeviceQueue, the queue
@ -647,7 +647,7 @@ binding operations in the queue have completed.
include::../validity/protos/vkQueueWaitIdle.txt[]
Synchronization between queues is done using {apiname} semaphores as
Synchronization between queues is done using Vulkan semaphores as
described in the <<synchronization,Synchronization and Cache Control>>
chapter.
@ -655,7 +655,7 @@ chapter.
[[devsandqueues-sparsebinding]]
=== Sparse Memory Binding
In {apiname} it is possible to sparsely bind memory to buffers and
In Vulkan it is possible to sparsely bind memory to buffers and
images as described in the <<sparsememory,Sparse Resource>> chapter. Sparse
memory binding is a queue operation. A queue whose flags include the
ename:VK_QUEUE_SPARSE_BINDING_BIT must: be able to support the

18
doc/specs/vulkan/chapters/extensions.txt
View File

@ -5,7 +5,7 @@
= Extended Functionality
Additional functionality may: be provided by layers or extensions. A layer
cannot: add or modify {apiname} commands, while an extension may: do so.
cannot: add or modify Vulkan commands, while an extension may: do so.
There are two kinds of layers and extensions, instance and device. Instance
layers and extensions are general purpose and do not depend on a specific
@ -24,10 +24,10 @@ extensions tend to be hardware-specific. Examples of these might be:
[[extended-functionality-layers]]
== Layers
When a layer is enabled, it inserts itself into the call chain for {apiname}
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 {apiname} enums used by the application fall within
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.
@ -85,7 +85,7 @@ include::../structs/VkLayerProperties.txt[]
in the slink:VkInstanceCreateInfo and slink:VkDeviceCreateInfo
structures passed to flink:vkCreateInstance and flink:vkCreateDevice,
respectively, to enable this layer for an instance or device.
* pname:specVersion is the {apiname} version the layer was written to,
* 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
@ -95,7 +95,7 @@ include::../structs/VkLayerProperties.txt[]
include::../validity/structs/VkLayerProperties.txt[]
Loader implementations may: provide mechanisms outside the {apiname} API for
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:VkDeviceCreateInfo are
@ -108,7 +108,7 @@ effect.
[[extended-functionality-extensions]]
== Extensions
Extensions may: define new {apiname} commands, structures, and enumerants.
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.h+ together
@ -116,7 +116,7 @@ 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 {apiname} implementation.
as well as by a Vulkan implementation.
To query the available instance extensions, call:
@ -131,7 +131,7 @@ include::../protos/vkEnumerateInstanceExtensionProperties.txt[]
include::../validity/protos/vkEnumerateInstanceExtensionProperties.txt[]
When pLayerName parameter is NULL, only extensions provided by the {apiname}
When 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.
@ -154,7 +154,7 @@ include::../protos/vkEnumerateDeviceExtensionProperties.txt[]
include::../validity/protos/vkEnumerateDeviceExtensionProperties.txt[]
When pLayerName parameter is NULL, only extensions provided by the {apiname}
When 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.

23
doc/specs/vulkan/chapters/features.txt
View File

@ -4,7 +4,7 @@
[[features]]
= Features, Limits, and Formats
{apiname} is designed to support a wide range of hardware and as such there
Vulkan is designed to support a wide range of hardware and as such there
are a number of features, limits, and formats which are not supported on all
hardware. Features describe functionality that is not required: and which
must: be explicitly enabled. Limits describe implementation-dependent
@ -20,7 +20,7 @@ by the implementation.
The features and limits are reported via basic structures (that is
slink:VkPhysicalDeviceFeatures and slink:VkPhysicalDeviceLimits).
It is expected that when new features or limits are added in a future
{apiname} version, new structure(s) and entry point(s) will be added as
Vulkan version, new structure(s) and entry point(s) will be added as
necessary to query these. New functionality added by
<<extended-functionality-extensions,extensions>> is not expected to
modify the core feature and limit structures.
@ -30,7 +30,7 @@ modify the core feature and limit structures.
== Features
The Specification defines a set of fine-grained features that are not
required:, but may: be supported by a {apiname} implementation. Support for
required:, but may: be supported by a Vulkan implementation. Support for
features is reported and enabled on a per-feature basis. Features are
properties of the physical device.
@ -565,7 +565,7 @@ include::../validity/structs/VkPhysicalDeviceFeatures.txt[]
[[features-features-requirements]]
=== Feature Requirements
All {apiname} graphics implementations must: support the following features:
All Vulkan graphics implementations must: support the following features:
* robustBufferAccess.
@ -1233,7 +1233,7 @@ include::../validity/structs/VkPhysicalDeviceLimits.txt[]
[[features-limits-minmax]]
=== Limit Requirements
The following table specifies the required minimum/maximum for all {apiname}
The following table specifies the required minimum/maximum for all Vulkan
graphics implementations. Where a limit corresponds to a fine-grained
device feature which is optional:, the feature name is listed with two
required limits, one when the feature is supported and one when it is not
@ -3097,11 +3097,16 @@ ename:VK_FORMAT_FEATURE_BLIT_DST_BIT::
fname:vkCmdBlitImage command.
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT::
sname:VkImage can: be used with a sampler that has either of
If ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT is also set,
sname:VkImageView can: be used with a sampler that has either of
pname:magFilter or pname:minFilter set to ename:VK_FILTER_LINEAR,
or pname:mipmapMode set to ename:VK_SAMPLER_MIPMAP_MODE_LINEAR. This bit
must: only be exposed for formats that also support the
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT.
or pname:mipmapMode set to ename:VK_SAMPLER_MIPMAP_MODE_LINEAR.
If ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT is also set, sname:VkImage
can be used as the pname:srcImage to flink:vkCmdBlitImage
with a pname:filter of ename:VK_FILTER_LINEAR. This bit must: only be
exposed for formats that also support the
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT or
ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT.
+
If the format being queried is a depth/stencil format, this bit only indicates
that the depth aspect (not the stencil aspect) supports linear filtering,

2
doc/specs/vulkan/chapters/fragops.txt
View File

@ -432,7 +432,7 @@ include::../enums/VkCompareOp.txt[]
* ename:VK_COMPARE_OP_ALWAYS: the test always passes.
As described earlier, the pname:failOp, pname:passOp, and pname:depthFailOp
members of pname:VkStencilOpState indicate what happens to the stored
members of slink:VkStencilOpState indicate what happens to the stored
stencil value if this or certain subsequent tests fail or pass. Each enum is
of type elink:VkStencilOp, which is defined as:

2
doc/specs/vulkan/chapters/framebuffer.txt
View File

@ -326,7 +326,7 @@ include::../enums/VkLogicOp.txt[]
<<<
The logical operations supported by {apiname} are summarized in the
The logical operations supported by Vulkan are summarized in the
following table in which
* latexmath:[$\lnot$] is bitwise invert,

131
doc/specs/vulkan/chapters/fundamentals.txt
View File

@ -4,7 +4,7 @@
[[fundamentals]]
= Fundamentals
This chapter introduces fundamental concepts including the {apiname}
This chapter introduces fundamental concepts including the Vulkan
architecture and execution model, API syntax, queues, pipeline
configurations, numeric representation, state and state queries, and the
different types of objects and shaders. It provides a framework for
@ -55,9 +55,9 @@ external standards such as the Linux Standard Base.
[[fundamentals-execmodel]]
== Execution Model
This section outlines the execution model of a {apiname} system.
This section outlines the execution model of a Vulkan system.
{apiname} exposes one or more _devices_,
Vulkan exposes one or more _devices_,
each of which exposes one or more _queues_ which may: process work
asynchronously to one another. The set of queues supported by a device is
partitioned into _families_. Each family supports one or more types of
@ -94,8 +94,8 @@ an implementation include:
On other architectures, there may: only be a single heap that can: be used
for any purpose.
A {apiname} application controls a set of devices through the submission of
command buffers which have recorded device commands issued via {apiname}
A Vulkan application controls a set of devices through the submission of
command buffers which have recorded device commands issued via Vulkan
library calls. The content of command buffers is specific to the underlying
hardware and is opaque to the application. Once constructed, a command
buffer can: be submitted once or many times to a queue for execution.
@ -115,7 +115,7 @@ the responsibility of the application.
[[fundamentals-queueoperation]]
=== Queue Operation
{apiname} queues provide an interface to the execution engines of a device.
Vulkan queues provide an interface to the execution engines of a device.
Commands are recorded into command buffers ahead of execution time.
These command buffers are then submitted to queues for execution. Command
buffers submitted to a single queue are played back in the order they were
@ -128,7 +128,7 @@ specified. Therefore, the application must: explicitly synchronize work
between queues when needed.
In order to control relative order of execution of work both within a queue
and across multiple queues, {apiname} provides several synchronization
and across multiple queues, Vulkan provides several synchronization
primitives, which include _semaphores_, _events_, _pipeline barriers_, and
_fences_. These are covered in depth in <<synchronization,Synchronization
and Cache Control>>. In broad terms, semaphores are used to synchronize work
@ -142,7 +142,7 @@ to synchronize work between the device and the host.
====
Implementations have significant freedom to overlap execution of work
submitted to a queue, and this is common due to deep pipelining and
parallelism in {apiname} devices.
parallelism in Vulkan devices.
====
Work is submitted to queues using queue submission commands that typically
@ -246,8 +246,8 @@ command buffers to execute. This is covered in more detail in
[[fundamentals-objectmodel-overview]]
== Object Model
The devices, queues, and other entities in {apiname} are represented by
{apiname} objects. At the API level, all objects are referred to by handles.
The devices, queues, and other entities in Vulkan are represented by
Vulkan objects. At the API level, all objects are referred to by handles.
There are two classes of handles, dispatchable and non-dispatchable.
_Dispatchable_ handle types are a pointer to an opaque type. This pointer
may: be used by layers as part of intercepting API commands, and thus each
@ -280,19 +280,19 @@ ftext:vkDestroy* and ftext:vkFree* commands, respectively.
Objects that are allocated (rather than created) take resources from an
existing pool object or memory heap, and when freed return resources to that
pool or heap. While object creation and destruction are generally expected
to be low-frequency occurences during runtime, allocating and freeing
to be low-frequency occurrences during runtime, allocating and freeing
objects can: occur at high frequency. Pool objects help accommodate improved
performance of the allocations and frees.
It is an application's responsibility to track the lifetime of {apiname}
It is an application's responsibility to track the lifetime of Vulkan
objects, and not to destroy them while they are still in use.
Application-owned memory is immediately consumed by any {apiname} command it
Application-owned memory is immediately consumed by any Vulkan command it
is passed into. The application can: alter or free this memory as soon as
the commands that consume it have returned.
The following object types are consumed when they are passed into a
{apiname} command and not further accessed by the objects they are used to
Vulkan command and not further accessed by the objects they are used to
create. They can: be destroyed at any time they are not in use by an API
command:
@ -306,11 +306,11 @@ sets mustnot: be updated with flink:vkUpdateDescriptorSets after the
descriptor set layout has been destroyed. Otherwise, descriptor set layouts
can: be destroyed any time they are not in use by an API command.
The application mustnot: destroy any other type of {apiname} object until
The application mustnot: destroy any other type of Vulkan object until
all uses of that object by the device (such as via command buffer execution)
have completed.
The following {apiname} objects can: be destroyed when no command buffers
The following Vulkan objects can: be destroyed when no command buffers
using the object are executing:
* sname:VkEvent
@ -328,7 +328,7 @@ using the object are executing:
* sname:VkDeviceMemory
* sname:VkDescriptorSet
The following {apiname} objects can: be destroyed when work on the queue
The following Vulkan objects can: be destroyed when work on the queue
that uses the object has been completed:
* sname:VkFence
@ -354,7 +354,7 @@ sname:VkDescriptorPool objects are parents of sname:VkDescriptorSet objects.
sname:VkDevice objects are parents of many object types (all that take a
sname:VkDevice as a parameter to their creation).
The following {apiname} objects have specific restrictions for when they
The following Vulkan objects have specific restrictions for when they
can: be destroyed:
* sname:VkQueue objects cannot: be explicitly destroyed. Instead, they are
@ -399,32 +399,32 @@ can: be destroyed:
[[fundamentals-commandsyntax]]
== Command Syntax and Duration
The Specification describes {apiname} commands as functions or procedures
The Specification describes Vulkan commands as functions or procedures
using C99 syntax. Language bindings for other languages such as C++ and
Javascript may: allow for stricter parameter passing, or object-oriented
interfaces.
With few exceptions, {apiname} uses the standard C types for parameters (int
With few exceptions, Vulkan uses the standard C types for parameters (int
types from stdint.h, etc). Exceptions to this are using basetype:VkResult
for return values, using basetype:VkBool32 for boolean values,
basetype:VkDeviceSize for sizes and offsets pertaining to device address
space, and basetype:VkFlags for passing bits or sets of bits of predefined
values.
Commands that create {apiname} objects are of the form ftext:vkCreate* and
Commands that create Vulkan objects are of the form ftext:vkCreate* and
take stext:Vk*CreateInfo structures with the parameters needed to create the
object. These {apiname} objects are destroyed with commands of the form
object. These Vulkan objects are destroyed with commands of the form
ftext:vkDestroy*.
The last in-parameter to each command that creates or destroys a {apiname}
The last in-parameter to each command that creates or destroys a Vulkan
object is pname:pAllocator. The pname:pAllocator parameter can: be set to a
non-`NULL` value such that allocations for the given object are delegated to
an application provided callback; refer to the <<memory-allocation,Memory
Allocation>> chapter for further details.
Commands that allocate {apiname} objects owned by pool objects are of the
Commands that allocate Vulkan objects owned by pool objects are of the
form ftext:vkAllocate*, and take stext:Vk*AllocateInfo structures. These
{apiname} objects are freed with commands of the form ftext:vkFree*.
Vulkan objects are freed with commands of the form ftext:vkFree*.
These objects do not take allocators; if host memory is needed, they will
use the allocator that was specified when their parent pool was created.
@ -438,21 +438,21 @@ and/or outside a render pass, and in one or more of the supported queue
types. These restrictions are documented together with the definition of
each such command.
The _duration_ of a {apiname} command refers to the interval between calling
The _duration_ of a Vulkan command refers to the interval between calling
the command and its return to the caller.
[[fundamentals-threadingbehavior]]
== Threading Behavior
{apiname} is intended to provide scalable performance when used on multiple
Vulkan is intended to provide scalable performance when used on multiple
host threads. All commands support being called concurrently from multiple
threads, but certain parameters, or components of parameters are defined to
be _externally synchronized_. This means that the caller must: guarantee
that no more than one thread is using such a parameter at a given time.
More precisely, {apiname} commands use simple stores to update software
structures representing {apiname} objects. A parameter declared as
More precisely, Vulkan commands use simple stores to update software
structures representing Vulkan objects. A parameter declared as
externally synchronized may: have its software
structures updated at any time during the host execution of the command. If
two commands operate on the same object and at least one of the commands
@ -468,7 +468,7 @@ Memory barriers are particularly relevant on the ARM CPU architecture
which is more weakly ordered than many developers are accustomed to from
x86/x64 programming. Fortunately, most higher-level synchronization
primitives (like the pthread library) perform memory barriers as a part of
mutual exclusion, so mutexing {apiname} objects via these primitives will
mutual exclusion, so mutexing Vulkan objects via these primitives will
have the desired effect.
====
@ -513,11 +513,11 @@ include::../hostsynctable/implicit.txt[]
[[fundamentals-errors]]
== Errors
{apiname} is a layered API. The lowest layer is the core {apiname} layer, as
Vulkan is a layered API. The lowest layer is the core Vulkan layer, as
defined by this Specification. The application can: use additional layers
above the core for debugging, validation, and other purposes.
One of the core principles of {apiname} is that building and submitting
One of the core principles of Vulkan is that building and submitting
command buffers should: be highly efficient. Thus error checking and
validation of state in the core layer is minimal, although more rigorous
validation can: be enabled through the use of layers.
@ -602,18 +602,21 @@ ename:VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO.
The values ename:VK_STRUCTURE_TYPE_LOADER_INSTANCE_CREATE_INFO and
ename:VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO are reserved for internal
use by the loader, and don't have corresponding {apiname} structures in this
use by the loader, and don't have corresponding Vulkan structures in this
specification.
Any parameter that is a structure containing a basetype:void* ptext:pNext
member must: have a value of ptext:pNext that is either `NULL`, or points to a
valid structure defined by an extension. If that extension is supported by
the implementation, then it must: be enabled.
Any component of the implementation (the loader, any enabled layers, and
drivers) must: ignore extension structures with pname:sType values defined
by extensions not supported by that component.
member must: have a value of ptext:pNext that is either `NULL`, or points to
a valid structure defined by an extension, containing ptext:sType and
ptext:pNext members as described in the <<extensions-interactions,Extension
Interactions>> section. If that extension is supported by the
implementation, then it must: be enabled. Any component of the
implementation (the loader, any enabled layers, and drivers) must: skip
over, without processing (other than reading the pname:sType and pname:pNext
members) any chained structures with pname:sType values not defined by
extensions supported by that component.
Extension structures are not described in the base {apiname} specification,
Extension structures are not described in the base Vulkan specification,
but either in layered specifications incorporating those extensions,
or in separate vendor-provided documents.
@ -628,8 +631,8 @@ sections.
[[fundamentals-returncodes]]
=== Return Codes
While the core {apiname} API is not designed to capture incorrect usage,
some circumstances still require return codes. Commands in {apiname} return
While the core Vulkan API is not designed to capture incorrect usage,
some circumstances still require return codes. Commands in Vulkan return
their status via return codes that are in one of two categories:
* Successful completion codes are returned when a command needs to
@ -639,7 +642,7 @@ their status via return codes that are in one of two categories:
failure that could only be detected at run time. All run time error
codes are negative values.
All return codes in {apiname} are reported via basetype:VkResult return
All return codes in Vulkan are reported via basetype:VkResult return
values. The possible codes are:
include::../enums/VkResult.txt[]
@ -680,7 +683,7 @@ include::../enums/VkResult.txt[]
* ename:VK_ERROR_FEATURE_NOT_PRESENT
A requested feature is not supported.
* ename:VK_ERROR_INCOMPATIBLE_DRIVER
The requested version of {apiname} is not supported by the driver or
The requested version of Vulkan is not supported by the driver or
is otherwise incompatible for implementation-specific reasons.
* ename:VK_ERROR_TOO_MANY_OBJECTS
Too many objects of the type have already been created.
@ -690,7 +693,7 @@ include::../enums/VkResult.txt[]
If a command returns a run time error, it will leave any result pointers
unmodified.
Out of memory errors do not damage any currently existing {apiname} objects.
Out of memory errors do not damage any currently existing Vulkan objects.
Objects that have already been successfully created can: still be used by
the application.
@ -707,7 +710,7 @@ Implementations normally perform computations in floating-point, and must:
meet the range and precision requirements defined under
``Floating-Point Computation'' below.
These requirements only apply to computations performed in {apiname}
These requirements only apply to computations performed in Vulkan
operations outside of shader execution, such as texture image
specification and sampling, and per-fragment operations. Range and
precision requirements during shader execution differ and are specified
@ -716,7 +719,7 @@ Instructions>> section.
In some cases, the representation and/or precision of operations is
implicitly limited by the specified format of vertex or texel
data consumed by {apiname}. Specific floating-point formats are
data consumed by Vulkan. Specific floating-point formats are
described later in this section.
@ -765,12 +768,12 @@ arithmetic operations such as latexmath:[$0 / 0$]. Implementations may:
support latexmath:[$Inf$]s and latexmath:[$NaN$]s in their floating-point
computations.
Any representable floating-point value is legal as input to a {apiname}
Any representable floating-point value is legal as input to a Vulkan
command that requires floating-point data. The result of providing a value
that is not a floating-point number to such a command is unspecified, but
mustnot: lead to {apiname} interruption or termination. In <<IEEE 754>>
mustnot: lead to Vulkan interruption or termination. In <<IEEE 754>>
arithmetic, for example, providing a negative zero or a denormalized number
to an {apiname} command must: yield deterministic results, while providing a
to an Vulkan command must: yield deterministic results, while providing a
latexmath:[$NaN$] or latexmath:[$Inf$] yields unspecified results.
@ -782,11 +785,11 @@ latexmath:[$NaN$] or latexmath:[$Inf$] yields unspecified results.
section of the Khronos Data Format Specification.
Any representable 16-bit floating-point value is legal as input to a
{apiname} command that accepts 16-bit floating-point data. The result of
Vulkan command that accepts 16-bit floating-point data. The result of
providing a value that is not a floating-point number (such as
latexmath:[$Inf$] or latexmath:[$NaN$]) to such a command is
unspecified, but mustnot: lead to {apiname} interruption or termination.
Providing a denormalized number or negative zero to {apiname} must: yield
unspecified, but mustnot: lead to Vulkan interruption or termination.
Providing a denormalized number or negative zero to Vulkan must: yield
deterministic results.
@ -810,11 +813,11 @@ converted to positive infinity; and both positive and negative
latexmath:[$NaN$] are converted to positive latexmath:[$NaN$].
Any representable unsigned 11-bit floating-point value is legal as input
to a {apiname} command that accepts 11-bit floating-point data. The
to a Vulkan command that accepts 11-bit floating-point data. The
result of providing a value that is not a floating-point number (such as
latexmath:[$Inf$] or latexmath:[$NaN$]) to such a command is
unspecified, but mustnot: lead to {apiname} interruption or termination.
Providing a denormalized number to {apiname} must: yield deterministic
unspecified, but mustnot: lead to Vulkan interruption or termination.
Providing a denormalized number to Vulkan must: yield deterministic
results.
@ -838,11 +841,11 @@ converted to positive infinity; and both positive and negative
latexmath:[$NaN$] are converted to positive latexmath:[$NaN$].
Any representable unsigned 10-bit floating-point value is legal as input to
a {apiname} command that accepts 10-bit floating-point data. The result of
a Vulkan command that accepts 10-bit floating-point data. The result of
providing a value that is not a floating-point number (such as
latexmath:[$Inf$] or latexmath:[$NaN$]) to such a command is unspecified,
but mustnot: lead to {apiname} interruption or termination. Providing a
denormalized number to {apiname} must: yield deterministic results.
but mustnot: lead to Vulkan interruption or termination. Providing a
denormalized number to Vulkan must: yield deterministic results.
[[fundamentals-general]]
@ -850,7 +853,7 @@ denormalized number to {apiname} must: yield deterministic results.
Some calculations require division. In such cases (including implied
divisions performed by vector normalization), division by zero produces an
unspecified result but mustnot: lead to {apiname} interruption or
unspecified result but mustnot: lead to Vulkan interruption or
termination.
@ -907,7 +910,7 @@ representation, one value (latexmath:[$-128$] in the example) is outside the
representable range, and must: be clamped before use. This equation is used
everywhere that signed normalized fixed-point values are converted to
floating-point, including for all signed normalized fixed-point parameters
in {apiname} commands, such as vertex attribute values, as well as for
in Vulkan commands, such as vertex attribute values, as well as for
specifying texture or framebuffer values using signed normalized
fixed-point.
@ -963,7 +966,7 @@ or framebuffer values using floating-point.
[[fundamentals-versionnum]]
== API Version Numbers and Semantics
The {apiname} version number is used in several places in the API. In each
The Vulkan version number is used in several places in the API. In each
such use, the API _major version number_, _minor version number_, and _patch
version number_ are packed into a 32-bit integer as follows:
@ -971,7 +974,7 @@ version number_ are packed into a 32-bit integer as follows:
* The minor version number is a 10-bit integer packed into bits 21-12.
* The patch version number is a 12-bit integer packed into bits 11-0.
Differences in any of the {apiname} version numbers indicates a change to
Differences in any of the Vulkan version numbers indicates a change to
the API in some way, with each part of the version number indicating a
different scope of changes.
@ -1001,7 +1004,7 @@ significant modification to an application in order for it to function.
[[fundamentals-common-objects]]
== Common Object Types
Some types of {apiname} objects are used in many different structures and
Some types of Vulkan objects are used in many different structures and
command parameters, and are described here. These types include _offsets_,
_extents_, and _rectangles_.

2
doc/specs/vulkan/chapters/fxvertex.txt
View File

@ -6,7 +6,7 @@
Some implementations have specialized fixed-function hardware for fetching
and format-converting vertex input data from buffers, rather than performing
the fetch as part of the vertex shader. {apiname} includes a vertex
the fetch as part of the vertex shader. Vulkan includes a vertex
attribute fetch stage in the graphics pipeline in order to take advantage of
this.

26
doc/specs/vulkan/chapters/initialization.txt
View File

@ -4,14 +4,14 @@
[[initialization]]
= Initialization
Before using {apiname}, an application must: initialize it by loading the
{apiname} commands, and creating a sname:VkInstance object.
Before using Vulkan, an application must: initialize it by loading the
Vulkan commands, and creating a sname:VkInstance object.
[[initialization-functionpointers]]
== Command Function Pointers
{apiname} commands are not necessarily exposed statically on a platform.
Function pointers for all {apiname} commands can: be obtained with the
Vulkan commands are not necessarily exposed statically on a platform.
Function pointers for all Vulkan commands can: be obtained with the
command:
include::../protos/vkGetInstanceProcAddr.txt[]
@ -27,8 +27,8 @@ specific manner. Typically, the loader library will export this command as a
function symbol, so applications can: link against the loader library, or
load it dynamically and look up the symbol using platform-specific APIs.
Loaders are encouraged to export function symbols for all other core
{apiname} commands as well; if this is done, then applications that use only
the core {apiname} commands have no need to use fname:vkGetInstanceProcAddr.
Vulkan commands as well; if this is done, then applications that use only
the core Vulkan commands have no need to use fname:vkGetInstanceProcAddr.
Function pointers to commands that don't operate on a specific instance can:
be obtained by using this command with pname:instance equal to `NULL`. The
@ -43,7 +43,7 @@ commands that operate on pname:instance or a child of pname:instance can: be
obtained. The returned function pointer must: only be called with a
dispatchable object (the first parameter) that is a child of pname:instance.
If pname:pName is not the name of a core {apiname} command, or is an
If pname:pName is not the name of a core Vulkan command, or is an
extension command for any extension not supported by any available layer or
implementation, then fname:vkGetInstanceProcAddr will return `NULL`.
@ -66,7 +66,7 @@ it.
====
endif::editing-notes[]
In order to support systems with multiple {apiname} implementations
In order to support systems with multiple Vulkan implementations
comprising heterogeneous collections of hardware and software, the function
pointers returned by fname:vkGetInstanceProcAddr may: point to dispatch
code, which calls a different real implementation for different
@ -79,13 +79,13 @@ command:
include::../protos/vkGetDeviceProcAddr.txt[]
* pname:device is the logical device that provides the function pointer.
* pname:pName is the name of any {apiname} command whose first parameter
* pname:pName is the name of any Vulkan command whose first parameter
is one of
** sname:VkDevice
** sname:VkQueue
** sname:VkCommandBuffer
If pname:pName is not the name of one of these {apiname} commands, and is
If pname:pName is not the name of one of these Vulkan commands, and is
not the name of an extension command belonging to an extension enabled for
pname:device, then fname:vkGetDeviceProcAddr will return `NULL`.
@ -94,9 +94,9 @@ include::../validity/protos/vkGetDeviceProcAddr.txt[]
[[initialization-instances]]
== Instances
There is no global state in {apiname} and all per-application state is
There is no global state in Vulkan and all per-application state is
stored in a sname:VkInstance object. Creating a sname:VkInstance object
initializes the {apiname} library and allows the application to pass
initializes the Vulkan library and allows the application to pass
information about itself to the implementation.
To create an instance object, call:
@ -160,7 +160,7 @@ include::../structs/VkApplicationInfo.txt[]
* pname:engineVersion is an unsigned integer variable containing the
developer-supplied version number of the engine used to create the
application.
* pname:apiVersion is the version of the {apiname} API against which the
* pname:apiVersion is the version of the Vulkan API against which the
application expects to run, encoded as described in the
<<fundamentals-versionnum,API Version Numbers and Semantics>> section.
If pname:apiVersion is 0 the implementation must: ignore it, otherwise

4
doc/specs/vulkan/chapters/interfaces.txt
View File

@ -889,9 +889,9 @@ within the local workgroup. The range of possible values for each component
of LocalInvocationID range from zero through the size of the workgroup in that
dimension minus one. If the size of the workgroup in a particular dimension is
one, then LocalInvocationID in that dimension will be zero. That is, if the
workgroup is effectively two-dimensional, then pname:LocalInvocationID.z will
workgroup is effectively two-dimensional, then code:LocalInvocationID.z will
be zero, and if the workgroup is one-dimensional, then both
pname:LocalInvocationID.y and pname:LocalInvocationID.z will be zero.
code:LocalInvocationID.y and code:LocalInvocationID.z will be zero.
+
The code:LocalInvocationID decoration is only supported in compute shaders.
+

34
doc/specs/vulkan/chapters/introduction.txt
View File

@ -7,23 +7,23 @@
This chapter is Informative except for the sections on Terminology and
Normative References.
This document, referred to as the ``{apiname} Specification'' or just the
``Specification'' hereafter, describes the {apiname} graphics system: what
This document, referred to as the ``Vulkan Specification'' or just the
``Specification'' hereafter, describes the Vulkan graphics system: what
it is, how it acts, and what is required to implement it. We assume that the
reader has at least a rudimentary understanding of computer graphics. This
means familiarity with the essentials of computer graphics algorithms and
terminology as well as with modern GPUs (Graphic Processing Units).
The canonical version of the Specification is available in the official
{apiname} Registry, located at URL
Vulkan Registry, located at URL
http://www.khronos.org/registry/vulkan/
[[introduction-whatis]]
== What is the {apiname} Graphics System?
== What is the Vulkan Graphics System?
{apiname} is an API (Application Programming Interface) for graphics and
Vulkan is an API (Application Programming Interface) for graphics and
compute hardware. The API consists of many commands that
allow a programmer to specify shader programs, compute kernels, objects, and
operations involved in producing high-quality graphical images, specifically
@ -31,18 +31,18 @@ color images of three-dimensional objects.
[[introduction-programmer]]
=== The Programmer's View of {apiname}
=== The Programmer's View of Vulkan
To the programmer, {apiname} is a set of commands that allow the
To the programmer, Vulkan is a set of commands that allow the
specification of _shader programs_ or _shaders_, _kernels_, data used by
kernels or shaders, and state controlling aspects of {apiname} outside the
kernels or shaders, and state controlling aspects of Vulkan outside the
scope of shaders. Typically, the data represents geometry in two or three
dimensions and texture images, while the shaders and kernels control the
processing of the data, rasterization of the geometry, and the lighting and
shading of _fragments_ generated by rasterization, resulting in the
rendering of geometry into the framebuffer.
A typical {apiname} program begins with platform-specific calls to open a
A typical Vulkan program begins with platform-specific calls to open a
window or otherwise prepare a display device onto which the program will
draw. Then, calls are made to open _queues_ to which _command buffers_ are
submitted. The command buffers contain lists of commands which will be
@ -56,24 +56,24 @@ transfer the resulting image to a display device or window.
[[introduction-implementor]]
=== The Implementor's View of {apiname}
=== The Implementor's View of Vulkan
To the implementor, {apiname} is a set of commands that allow the
To the implementor, Vulkan is a set of commands that allow the
construction and submission of command buffers to a device. Modern devices
accelerate virtually all {apiname} operations, storing data and framebuffer
accelerate virtually all Vulkan operations, storing data and framebuffer
images in high-speed memory and executing shaders in dedicated GPU
processing resources.
The implementor's task is to provide a software library on the host which
implements the {apiname} API, while mapping the work for each {apiname}
implements the Vulkan API, while mapping the work for each Vulkan
command to the graphics hardware as appropriate for the capabilities of the
device.
[[introduction-ourview]]
=== Our View of {apiname}
=== Our View of Vulkan
We view {apiname} as a pipeline having some programmable stages and some
We view Vulkan as a pipeline having some programmable stages and some
state-driven fixed-function stages that are invoked by a set of specific
drawing operations. We expect this model to result in a specification that
satisfies the needs of both programmers and implementors. It does not,
@ -86,7 +86,7 @@ efficient than the one specified.
[[introduction-bugs]]
== Filing Bug Reports
Issues with and bug reports on the {apiname} Specification and the API
Issues with and bug reports on the Vulkan Specification and the API
Registry can: be filed in the Khronos Vulkan Github repository, located at
URL
@ -173,7 +173,7 @@ endif::editing-notes[]
== Normative References
Normative references are references to external documents or resources to
which implementers of {apiname} must: comply.
which implementers of Vulkan must: comply.
[[IEEE 754]]:: _IEEE Standard for Floating-Point Arithmetic_,
IEEE Std 754-2008,

113
doc/specs/vulkan/chapters/memory.txt
View File

@ -4,20 +4,20 @@
[[memory]]
= Memory Allocation
{apiname} memory is broken up into two categories, _host memory_ and
Vulkan memory is broken up into two categories, _host memory_ and
_device memory_.
[[memory-host]]
== Host Memory
Host memory is memory needed by the {apiname} implementation for
Host memory is memory needed by the Vulkan implementation for
non-device-visible storage. This storage may: be used for e.g. internal
software structures.
[[memory-allocation]]
{apiname} provides applications the opportunity to perform host memory
allocations on behalf of the {apiname} implementation. If this feature is
Vulkan provides applications the opportunity to perform host memory
allocations on behalf of the Vulkan implementation. If this feature is
not used, the implementation will perform its own memory allocations. Since
most memory allocations are off the critical path, this is not meant as a
performance feature. Rather, this can: be useful for certain embedded
@ -31,7 +31,7 @@ include::../structs/VkAllocationCallbacks.txt[]
* pname:pUserData is a value to be interpreted by the implementation of
the callbacks. When any of the callbacks in sname:VkAllocationCallbacks
are called, the {apiname} implementation will pass this value as the
are called, the Vulkan implementation will pass this value as the
first parameter to the callback. This value can: vary each time an
allocator is passed into a command, even when the same object takes an
allocator in multiple commands.
@ -190,17 +190,17 @@ parameter and takes a value of type elink:VkSystemAllocationScope:
include::../enums/VkSystemAllocationScope.txt[]
* ename:VK_SYSTEM_ALLOCATION_SCOPE_COMMAND - The allocation is scoped to
the duration of the {apiname} command.
the duration of the Vulkan command.
* ename:VK_SYSTEM_ALLOCATION_SCOPE_OBJECT - The allocation is scoped to
the lifetime of the {apiname} object that is being created or used.
the lifetime of the Vulkan object that is being created or used.
* ename:VK_SYSTEM_ALLOCATION_SCOPE_CACHE - The allocation is scoped to the
lifetime of a sname:VkPipelineCache object.
* ename:VK_SYSTEM_ALLOCATION_SCOPE_DEVICE - The allocation is scoped to
the lifetime of the {apiname} device.
the lifetime of the Vulkan device.
* ename:VK_SYSTEM_ALLOCATION_SCOPE_INSTANCE - The allocation is scoped to
the lifetime of the {apiname} instance.
the lifetime of the Vulkan instance.
Most {apiname} commands operate on a single object, or there is a sole
Most Vulkan commands operate on a single object, or there is a sole
object that is being created or manipulated. When an allocation uses a scope
of ename:VK_SYSTEM_ALLOCATION_SCOPE_OBJECT or
ename:VK_SYSTEM_ALLOCATION_SCOPE_CACHE, the allocation is scoped to the
@ -292,7 +292,7 @@ If pname:pfnAllocation or pname:pfnReallocation fail, the implementation
may: fail object creation and/or generate an
ename:VK_ERROR_OUT_OF_HOST_MEMORY error, as appropriate.
Allocation callbacks must: not call any {apiname} commands.
Allocation callbacks must: not call any Vulkan commands.
The following sets of rules define when an implementation is permitted to
call the allocator callbacks.
@ -493,8 +493,8 @@ The memory types are sorted according to a preorder which serves to aid
in easily selecting an appropriate memory type. Given two memory types X and
Y, the preorder defines latexmath:[$X \leq Y$] if:
* the memory property bits set for X are a subset of the memory property
bits set for Y. Or,
* the memory property bits set for X are a strict subset of the memory
property bits set for Y. Or,
* the memory property bits set for X are the same as the memory property
bits set for Y, and X uses a memory heap with greater or equal
performance (as determined in an implementation-specific manner).
@ -539,7 +539,7 @@ accesses, as appropriate for the intended usage, and if such a memory type is
not present can: fallback to searching for a less optimal but guaranteed set of
properties such as "0" or "host-visible and coherent".
A {apiname} device operates on data in device memory via memory objects that
A Vulkan device operates on data in device memory via memory objects that
are represented in the API by a sname:VkDeviceMemory handle. Memory objects
are allocated by calling fname:vkAllocateMemory:
@ -657,16 +657,6 @@ include::../validity/protos/vkMapMemory.txt[]
It is an application error to call fname:vkMapMemory on a memory object that
is already mapped.
ifdef::editing-notes[]
[NOTE]
.editing-note
====
TODO (Tobias) - There's a circular section reference in this next section.
The information is all covered by both places, but it seems a bit weird to
have them reference each other. Not sure how to resolve it.
====
endif::editing-notes[]
[[memory-device-hostaccess-hazards]]
fname:vkMapMemory does not check whether the device memory is currently in
use before returning the host-accessible pointer. The application
@ -696,35 +686,11 @@ familiar with all of the mechanisms described in the chapter on
to maintaining memory access ordering.
====
Host-visible memory types that advertise the
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT property still require
<<synchronization-pipeline-barriers,memory barriers>> between host and
device in order to be coherent, but do not require additional cache
management operations (fname:vkFlushMappedMemoryRanges or
fname:vkInvalidateMappedMemoryRanges) to achieve coherency. For host writes
to be seen by subsequent command buffer operations, a pipeline barrier from
a source of ename:VK_ACCESS_HOST_WRITE_BIT and
ename:VK_PIPELINE_STAGE_HOST_BIT to a destination of the relevant device
pipeline stages and access types must: be performed. Note that such a
barrier is performed
<<synchronization-implicit-ordering-hostwrites,implicitly>> upon each
command buffer submission, so an explicit barrier is only rarely needed
(e.g. if a command buffer waits upon an event signaled by the host, where
the host wrote some data after submission). For device writes to be seen by
subsequent host reads, a pipeline barrier is required: to
<<synchronization-fences-devicewrites,make the writes visible>>.
Two commands are provided to enable applications to work with
non-coherent memory allocations: fname:vkFlushMappedMemoryRanges and
fname:vkInvalidateMappedMemoryRanges.
In order to enable applications to work with non-coherent memory
allocations, two entry points are provided. To flush host write caches, an
application must: use fname:vkFlushMappedMemoryRanges, while
fname:vkInvalidateMappedMemoryRanges allows invalidating host input caches
so that device writes become visible to the host.
fname:vkFlushMappedMemoryRanges must: be called after the host writes to
non-coherent memory have completed and before command buffers that will read
or write any of those memory locations are submitted to a queue. Similarly,
fname:vkInvalidateMappedMemoryRanges must: be called after command buffers
that execute and flush (via memory barriers) the device writes have
completed, and before the host will read or write any of those locations.
To flush ranges of non-coherent memory from the host caches, call:
include::../protos/vkFlushMappedMemoryRanges.txt[]
@ -736,6 +702,13 @@ include::../protos/vkFlushMappedMemoryRanges.txt[]
include::../validity/protos/vkFlushMappedMemoryRanges.txt[]
fname:vkFlushMappedMemoryRanges must: be used to guarantee that host writes to
non-coherent memory are visible to the device. It must: be called after the host
writes to non-coherent memory have completed and before command buffers that will
read or write any of those memory locations are submitted to a queue.
To invalidate ranges of non-coherent memory from the host caches, call:
include::../protos/vkInvalidateMappedMemoryRanges.txt[]
* pname:device is the logical device that owns the memory ranges.
@ -770,8 +743,42 @@ fname:vkFlushMappedMemoryRanges and fname:vkInvalidateMappedMemoryRanges are
unnecessary and may: have performance cost.
====
fname:vkInvalidateMappedMemoryRanges must: be used to guarantee that device writes to
non-coherent memory are visible to the host. It must: be called after command buffers
that execute and flush (via memory barriers) the device writes have completed, and
before the host will read or write any of those locations. If a range of non-coherent
memory is written by the host and then invalidated without first being flushed, its
contents are undefined.
ifdef::editing-notes[]
[NOTE]
.editing-note
====
TODO (Tobias) - There's a circular section reference between this next section
and the <<synchronization-fences-devicewrites,synchronization section>>. The
information is all covered by both places, but it seems a bit weird to have them
reference each other. Not sure how to resolve it.
====
endif::editing-notes[]
Host-visible memory types that advertise the
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT property still require
<<synchronization-pipeline-barriers,memory barriers>> between host and device
in order to be coherent, but do not require additional cache management
operations to achieve coherency. For host writes to
be seen by subsequent command buffer operations, a pipeline barrier from
a source of ename:VK_ACCESS_HOST_WRITE_BIT and ename:VK_PIPELINE_STAGE_HOST_BIT
to a destination of the relevant device pipeline stages and access types must:
be performed. Note that such a barrier is performed
<<synchronization-implicit-ordering-hostwrites,implicitly>> upon each
command buffer submission, so an explicit barrier is only rarely needed
(e.g. if a command buffer waits upon an event signaled by the host, where
the host wrote some data after submission). For device writes to be seen by
subsequent host reads, a pipeline barrier is required: to
<<synchronization-fences-devicewrites,make the writes visible>>.
Once host access to a memory object is no longer needed by the application,
it can: be unmapped by calling :
it can: be unmapped by calling:
include::../protos/vkUnmapMemory.txt[]

10
doc/specs/vulkan/chapters/pipelines.txt
View File

@ -5,7 +5,7 @@
= Pipelines
The following <<pipelines-block-diagram,figure>> shows a block diagram of
the {apiname} pipelines. Some {apiname} commands specify geometric objects
the Vulkan pipelines. Some Vulkan commands specify geometric objects
to be drawn or computational work to be performed, while others specify
state controlling how objects are handled by the various pipeline stages, or
control data transfer between memory organized as images and buffers.
@ -46,8 +46,8 @@ The <<pipelines-compute,compute pipeline>> is a separate pipeline from the
graphics pipeline, which operates on one-, two-, or three-dimensional
workgroups which can: read from and write to buffer and image memory.
This ordering is meant only as a tool for describing {apiname}, not as a
strict rule of how {apiname} is implemented, and we present it only as a
This ordering is meant only as a tool for describing Vulkan, not as a
strict rule of how Vulkan is implemented, and we present it only as a
means to organize the various operations of the pipelines.
[[pipelines-block-diagram]]
@ -98,7 +98,7 @@ include::../protos/vkCreateComputePipelines.txt[]
<<pipelines-cache,pipeline cache>> object, in which case use of that
cache is enabled for the duration of the command.
* pname:createInfoCount is the length of the pname:pCreateInfos and
pname:Pipelines arrays.
pname:pPipelines arrays.
* pname:pCreateInfos is an array of sname:VkComputePipelineCreateInfo
structures.
* pname:pAllocator controls host memory allocation as described in the
@ -183,7 +183,7 @@ include::../protos/vkCreateGraphicsPipelines.txt[]
<<pipelines-cache,pipeline cache>> object, in which case use of that
cache is enabled for the duration of the command.
* pname:createInfoCount is the length of the pname:pCreateInfos and
pname:Pipelines arrays.
pname:pPipelines arrays.
* pname:pCreateInfos is an array of sname:VkGraphicsPipelineCreateInfo
structures.
* pname:pAllocator controls host memory allocation as described in the

4
doc/specs/vulkan/chapters/primsrast.txt
View File

@ -122,7 +122,7 @@ stage in the pipeline before rasterization.
[[primsrast-multisampling]]
== Multisampling
Multisampling is a mechanism to antialias all {apiname} primitives: points,
Multisampling is a mechanism to antialias all Vulkan primitives: points,
lines, and polygons. The technique is to sample all primitives multiple
times at each pixel. Each sample in each framebuffer attachment has storage
for a color, depth, and/or stencil value, such that per-fragment operations
@ -131,7 +131,7 @@ _resolved_ to a single color (see <<copies-resolve,Resolving Multisample
Images>> and the <<renderpass,Render Pass>> chapter for more details on how
to resolve multisample images to non-multisample images).
{apiname} defines rasterization rules for single-sample modes in a way that
Vulkan defines rasterization rules for single-sample modes in a way that
is equivalent to a multisample mode with a single sample in the center of
each pixel.

8
doc/specs/vulkan/chapters/queries.txt
View File

@ -5,7 +5,7 @@
= Queries
_Queries_ provide a mechanism to return information about the processing of
a sequence of {apiname} commands. Query operations are asynchronous, and as
a sequence of Vulkan commands. Query operations are asynchronous, and as
such, their results are not returned immediately. Instead, their results,
and their availability status, are stored in a <<queries-pools, Query
Pool>>. The state of these queries can: be read back on the host, or copied
@ -246,7 +246,7 @@ These bits have the following meanings:
* ename:VK_QUERY_RESULT_64_BIT indicates the results will be written as an
array of 64-bit unsigned integer values. If this bit is not set, the
results will be written as an array of 32-bit unsigned integer values.
* ename:VK_QUERY_RESULT_WAIT_BIT indicates that {apiname} will wait for
* ename:VK_QUERY_RESULT_WAIT_BIT indicates that Vulkan will wait for
each query's status to become available before retrieving its results.
* ename:VK_QUERY_RESULT_WITH_AVAILABILITY_BIT indicates that the
availability status accompanies the results.
@ -263,7 +263,7 @@ If ename:VK_QUERY_RESULT_64_BIT is not set and the result overflows a
ename:VK_QUERY_RESULT_64_BIT is set and the result overflows a 64-bit
value, the value may: either wrap or saturate.
If ename:VK_QUERY_RESULT_WAIT_BIT is set, {apiname} will wait for each
If ename:VK_QUERY_RESULT_WAIT_BIT is set, Vulkan will wait for each
query to be in the available state before retrieving the numerical
results for that query. In this case, fname:vkGetQueryPoolResults is
guaranteed to succeed and return ename:VK_SUCCESS if the queries
@ -458,7 +458,7 @@ but still not be visible in a final image.
== Pipeline Statistics Queries
Pipeline statistics queries allow the application to sample a specified set
of sname:VkPipeline counters. These counters are accumulated by {apiname}
of sname:VkPipeline counters. These counters are accumulated by Vulkan
for a set of either draw or dispatch commands while a pipeline statistics
query is active. As such, pipeline statistics queries are available on
queue families supporting either graphics or compute operations. Further,

4
doc/specs/vulkan/chapters/renderpass.txt
View File

@ -758,8 +758,8 @@ include::../structs/VkRenderPassBeginInfo.txt[]
* pname:pClearValues is an array of slink:VkClearValue structures that
contains clear values for each attachment, if the attachment uses a
pname:loadOp value of ename:VK_ATTACHMENT_LOAD_OP_CLEAR. The array is
indexed by attachment number, with elements corresponding to uncleared
attachments being unused.
indexed by attachment number. Only elements corresponding to cleared
attachments are used. Other elements of pname:pClearValues are ignored.
include::../validity/structs/VkRenderPassBeginInfo.txt[]

6
doc/specs/vulkan/chapters/resources.txt
View File

@ -4,7 +4,7 @@
[[resources]]
= Resource Creation
{apiname} supports two primary resource types: _buffers_ and _images_.
Vulkan supports two primary resource types: _buffers_ and _images_.
Resources are views of memory with associated formatting and dimensionality.
Buffers are essentially unformatted arrays of bytes whereas images contain
format information, can: be multidimensional and may: have associated
@ -449,7 +449,7 @@ pname:depthPitch is defined only for 3D images.
For color formats, the pname:aspectMask member of sname:VkImageSubresource
must: be ename:VK_IMAGE_ASPECT_COLOR_BIT. For depth/stencil formats,
pname:aspect must: be either ename:VK_IMAGE_ASPECT_DEPTH_BIT or
pname:aspectMask must: be either ename:VK_IMAGE_ASPECT_DEPTH_BIT or
ename:VK_IMAGE_ASPECT_STENCIL_BIT. On implementations that store depth and
stencil aspects separately, querying each of these image subresource layouts
will return a different pname:offset and pname:size representing the region
@ -996,7 +996,7 @@ include::../protos/vkBindBufferMemory.txt[]
include::../validity/protos/vkBindBufferMemory.txt[]
To attach memory to a image object, call:
To attach memory to an image object, call:
include::../protos/vkBindImageMemory.txt[]

4
doc/specs/vulkan/chapters/samplers.txt
View File

@ -109,7 +109,7 @@ include::../enums/VkBorderColor.txt[]
** The functions mustnot: use offsets.
[NOTE]
.Mapping of OpenGL to {apiname} filter modes
.Mapping of OpenGL to Vulkan filter modes
==================
pname:magFilter values of ename:VK_FILTER_NEAREST and ename:VK_FILTER_LINEAR
directly correspond to code:GL_NEAREST and code:GL_LINEAR magnification
@ -120,7 +120,7 @@ ename:VK_FILTER_LINEAR and pname:mipmapMode of
ename:VK_SAMPLER_MIPMAP_MODE_NEAREST correspond to
code:GL_LINEAR_MIPMAP_NEAREST).
There are no {apiname} filter modes that directly correspond to OpenGL
There are no Vulkan filter modes that directly correspond to OpenGL
minification filters of code:GL_LINEAR or code:GL_NEAREST, but they can: be
emulated using ename:VK_SAMPLER_MIPMAP_MODE_NEAREST, pname:minLod = 0, and
pname:maxLod = 0.25, and using pname:minFilter = ename:VK_FILTER_LINEAR or

2
doc/specs/vulkan/chapters/shaders.txt
View File

@ -40,7 +40,7 @@ _Shader modules_ contain _shader code_ and one or more entry points. Shaders
are selected from a shader module by specifying an entry point as part of
<<pipelines,pipeline>> creation. The stages of a pipeline can: use shaders
that come from different modules. The shader code defining a shader module
must: be in the SPIR-V format, as described by the <<spirvenv,{apiname}
must: be in the SPIR-V format, as described by the <<spirvenv,Vulkan
Environment for SPIR-V>> appendix.
A shader module is created by calling:

6
doc/specs/vulkan/chapters/sparsemem.txt
View File

@ -5,7 +5,7 @@
= Sparse Resources
As documented in <<resources-association,Resource Memory Association>>,
sname:VkBuffer and sname:VkImage resources in {apiname} must: be bound
sname:VkBuffer and sname:VkImage resources in Vulkan must: be bound
completely and contiguously to a single sname:VkDeviceMemory object.
This binding must: be done before the resource is used, and the
binding is immutable for the lifetime of the resource.
@ -1027,7 +1027,7 @@ arrayMipTailOffset = imageMipTailOffset + arrayLayer * imageMipTailStride;
and the mip tail can: be bound with code:layerCount slink:VkSparseMemoryBind
structures, each using pname:size = pname:imageMipTailSize and
pname:resourceOffset = pname:arrayMipTailOffset as defined above.
pname:resourceOffset = ptext:arrayMipTailOffset as defined above.
Sparse memory binding is handled by the following APIs and related data
structures.
@ -1167,7 +1167,7 @@ include::../structs/VkSparseImageMemoryBind.txt[]
* pname:extent is the size in texels of the region within the image
subresource to bind. The extent must: be a multiple of the sparse image
block dimensions, except when binding sparse image blocks along the edge
of a image subresource it can: instead be such that any coordinate of
of an image subresource it can: instead be such that any coordinate of
latexmath:[$\mathit{offset} + \mathit{extent}$] equals the corresponding
dimensions of the image subresource.
* pname:memory is the sname:VkDeviceMemory object that the sparse image

18
doc/specs/vulkan/chapters/synchronization.txt
View File

@ -5,17 +5,17 @@
= Synchronization and Cache Control
Synchronization of access to resources is primarily the responsibility of
the application. In {apiname}, there are four forms of concurrency during
the application. In Vulkan, there are four forms of concurrency during
execution: between the host and device, between the queues, between
queue submissions, and between commands within a command buffer.
{apiname} provides the application with a set of
Vulkan provides the application with a set of
synchronization primitives for these purposes. Further, memory caches and
other optimizations mean that the normal flow of command execution does not
guarantee that all memory transactions from a command are immediately
visible to other agents with views into a given range of memory. {apiname}
visible to other agents with views into a given range of memory. Vulkan
also provides barrier operations to ensure this type of synchronization.
Four synchronization primitive types are exposed by {apiname}. These are:
Four synchronization primitive types are exposed by Vulkan. These are:
* <<synchronization-fences,Fences>>
* <<synchronization-semaphores,Semaphores>>
@ -225,7 +225,7 @@ include::../protos/vkDestroySemaphore.txt[]
include::../validity/protos/vkDestroySemaphore.txt[]
To signal a semaphore from a queue, include it in an element of the array
of slink:VkSubmitInfo structures passed through the pname:pSubmitInfo
of slink:VkSubmitInfo structures passed through the pname:pSubmits
parameter to a call to flink:vkQueueSubmit, or in an element of the array
of slink:VkBindSparseInfo structures passed through the pname:pBindInfo
parameter to a call to flink:vkQueueBindSparse.
@ -297,7 +297,7 @@ performed in between.
(The primary use case for this example is with the presentation extensions,
thus the etext:VK_IMAGE_LAYOUT_PRESENT_SRC_KHR token is used even though it
is not defined in the core {apiname} specification.)
is not defined in the core Vulkan specification.)
====
When a queue signals or waits upon a semaphore, certain
@ -313,7 +313,7 @@ the host.
Events represent a fine-grained synchronization primitive that can: be used
to gauge progress through a sequence of commands executed on a queue by
{apiname}. An event is initially in the unsignaled state. It can: be
Vulkan. An event is initially in the unsignaled state. It can: be
signaled by a device, using commands inserted into the command buffer, or by
the host. It can: also be reset to the unsignaled state by a device or the
host. The host can: query the state of an event. A device can: wait for one
@ -936,7 +936,7 @@ Enumeration>> and <<devsandqueues-queues,Queues>>.
_Memory barriers_ express the two halves of a memory dependency between an
earlier set of memory accesses against a later set of memory accesses.
{apiname} provides three types of memory barriers: global memory, buffer
Vulkan provides three types of memory barriers: global memory, buffer
memory, and image memory.
@ -1142,7 +1142,7 @@ include::../validity/structs/VkBufferMemoryBarrier.txt[]
The image memory barrier type is specified with an instance of the
sname:VkImageMemoryBarrier structure. This type of barrier only applies to
memory accesses involving a specific image subresource range of the
specified image object. That is, a memory dependency formed from a image
specified image object. That is, a memory dependency formed from an image
memory barrier is
<<synchronization-execution-and-memory-dependencies-types,scoped>> to the
specified image subresources of the image. It is also used to perform a

2
doc/specs/vulkan/copyright.txt
View File

@ -62,6 +62,6 @@ representatives be liable for any damages, whether direct, indirect, special or
consequential damages for lost revenues, lost profits, or otherwise, arising from or in
connection with these materials.
Khronos and {apiname} are trademarks of The Khronos Group Inc. OpenCL is a trademark of
Khronos and Vulkan are trademarks of The Khronos Group Inc. OpenCL is a trademark of
Apple Inc. and OpenGL is a registered trademark of Silicon Graphics International, both
used under license by Khronos.

2
doc/specs/vulkan/man/vkAllocateCommandBuffers.txt
View File

@ -25,7 +25,7 @@ pname:pCommandBuffers::
Description
-----------
fname::vkAllocateCommandBuffers allocates command buffers from an existing command pool. pname:pAllocateInfo
fname:vkAllocateCommandBuffers allocates command buffers from an existing command pool. pname:pAllocateInfo
is a pointer to an instance of the slink:VkCommandBufferAllocateInfo structure which
describes the command buffer allocation. The definition of slink:VkCommandBufferAllocateInfo is:

2
doc/specs/vulkan/man/vkCmdCopyBuffer.txt
View File

@ -39,7 +39,7 @@ the slink:VkBufferCopy structure, whose definition is:
include::../structs/VkBufferCopy.txt[]
If any two or more regions within pname:pRegions overlap, the resulting data will be
undefined. It is recomended, but not required, that the regions given in pname:pRegions
undefined. It is recommended, but not required, that the regions given in pname:pRegions
start on multiples of four bytes and have a length which is a multiple of four bytes.
include::../validity/protos/vkCmdCopyBuffer.txt[]

2
doc/specs/vulkan/man/vkCmdResolveImage.txt
View File

@ -14,7 +14,7 @@ Parameters
----------
pname:commandBuffer::
Ths command buffer into which the command is to be placed.
The command buffer into which the command is to be placed.
pname:srcImage::
The image that is the source of the resolve operation.

2
doc/specs/vulkan/man/vkCreateBuffer.txt
View File

@ -20,7 +20,7 @@ pname:pCreateInfo::
Pointer to data structure containing information about the object to be created.
pname:pBuffer::
Pointer to a variable to recieve a handle to the new buffer object.
Pointer to a variable to receive a handle to the new buffer object.
Description
-----------

2
doc/specs/vulkan/man/vkCreateComputePipelines.txt
View File

@ -66,7 +66,7 @@ to fname:vkCreateComputePipelines.
The parameters pname:basePipelineHandle and pname:basePipelineIndex are ignored
unless pname:flags has the ename:VK_PIPELINE_CREATE_DERIVATIVE_BIT bit set. If
using the pname:basePipelineIndex parameter, the index must refer to a
pname:pCreateInfos parameter pased to vkCreateComputePipelines that appeared
pname:pCreateInfos parameter passed to vkCreateComputePipelines that appeared
earlier than the current sname:VkComputePipelineCreateInfo in the list. The
parameters pname:basePipelineHandle and pname:basePipelineIndex are mutually
exclusive. If you specify a valid pname:basePipelineHandle,

2
doc/specs/vulkan/man/vkCreateImageView.txt
View File

@ -25,7 +25,7 @@ pname:pView::
Description
-----------
fname:vkCreateImageView creates a new view of a source image in a compatible format, alowing casting
fname:vkCreateImageView creates a new view of a source image in a compatible format, allowing casting
of image data from one format to another. Image views may be bound into descriptor sets to allow them
to be accessed in shaders, or be bound as color attachments. pname:device specifies the device that
is to be used to create the new view. pname:pCreateInfo is a pointer to an instance of the

2
doc/specs/vulkan/man/vkCreatePipelineLayout.txt
View File

@ -20,7 +20,7 @@ pname:pCreateInfo::
A pointer to structure specifying the properties of the new pipeline layout.
pname:pPipelineLayout::
Pointer to a variable to recieve a handle to the new pipeline layout object.
Pointer to a variable to receive a handle to the new pipeline layout object.
Description
-----------

2
doc/specs/vulkan/man/vkEnumeratePhysicalDevices.txt
View File

@ -41,7 +41,7 @@ If pname:pPhysicalDevices is not code:NULL, then pname:pPhysicalDeviceCount shou
to a variable that has been initialized with the size of the array pointed to by pname:pPhysicalDevices.
No more than this number of physical device handles will be written into the output array.
The actual number of device handles written into pname:pPhysicalDevices is then written into
the variable pointed to pname:pPhysicalDevices.
the variable pointed to by pname:pPhysicalDeviceCount.
include::../validity/protos/vkEnumeratePhysicalDevices.txt[]

2
doc/specs/vulkan/man/vkGetImageSubresourceLayout.txt
View File

@ -30,7 +30,7 @@ Description
-----------
fname:vkGetImageSubresourceLayout returns information about the memory
layout of a image subresource of an image. pname:device is a handle to the
layout of an image subresource of an image. pname:device is a handle to the
device that owns pname:image, which is the image about which to retrieve
information. A description of the image subresource is passsed to the
command through an instance of the slink:VkImageSubresource structure, the

2
doc/specs/vulkan/man/vkGetInstanceProcAddr.txt
View File

@ -30,7 +30,7 @@ different values of pname:instance.
If pname:instance is code:NULL, fname:vkGetInstanceProcAddr will return
non-code:NULL function pointers for the global commands
fname::vkEnumerateInstanceExtensionProperties,
fname:vkEnumerateInstanceExtensionProperties,
fname:vkEnumerateInstanceLayerProperties, and fname:vkCreateInstance. It will
return code:NULL for all other commands, since they may have different
implementations in different instances.

4
doc/specs/vulkan/man/vkGetPhysicalDeviceQueueFamilyProperties.txt
View File

@ -73,8 +73,8 @@ operations such as binding graphics state and graphics pipelines and executing d
* If a queue's ptext:queueFlags member contains ename:VK_QUEUE_COMPUTE_BIT, then it supports compute
operations such as binding compute pipelines and executing compute dispatches.
* If a queue's ptext:queueFlags member contains ename:VK_QUEUE_TRANSFER_BIT, then it supports transsfer
operations, which include copying data an images.
* If a queue's ptext:queueFlags member contains ename:VK_QUEUE_TRANSFER_BIT, then it supports transfer
operations, which include copying data and images.
* If a queue's ptext:queueFlags member contains ename:VK_QUEUE_SPARSE_BINDING_BIT, then it supports
binding memory to sparse buffer and image resources.

9
doc/specs/vulkan/style/styleguide.txt
View File

@ -583,6 +583,13 @@ See Gitlab issue #61.
====
=== Terms to Use With Caution
The term _subset_ is sometimes used to refer to a _strict subset_, and
sometimes used to refer to a subset which may be equal to the entire set.
This is particularly likely to come up when describing bitmasks. Make sure
to use either _subset_ or _strict subset_ as appropriate.
=== Terms to Avoid
Don't describe anything in the documentation using vague or wishy-washy
@ -852,7 +859,7 @@ autogenerated from vk.xml, and included from the `../validity/` directories:
include::../validity/protos/vkCreateCommandPool.txt[]
====
The sname:VkCommandPoolCreateInfo structure is defined as follows:
The sname:VkCommandPoolCreateInfo structure is defined as:
include::../structs/VkCommandPoolCreateInfo.txt[]

1
doc/specs/vulkan/validity/protos/vkCmdBlitImage.txt
View File

@ -35,6 +35,7 @@ endif::doctype-manpage[]
* If either of pname:srcImage or pname:dstImage was created with an unsigned integer elink:VkFormat, the other must: also have been created with an unsigned integer elink:VkFormat
* If either of pname:srcImage or pname:dstImage was created with a depth/stencil format, the other must: have exactly the same format
* If pname:srcImage was created with a depth/stencil format, pname:filter must: be ename:VK_FILTER_NEAREST
* If pname:filter is ename:VK_FILTER_LINEAR, pname:srcImage must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/protos/vkCmdClearColorImage.txt
View File

@ -20,7 +20,7 @@ endif::doctype-manpage[]
* pname:image must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* pname:imageLayout must: specify the layout of the image subresource ranges of pname:image specified in pname:pRanges at the time this command is executed on a sname:VkDevice
* pname:imageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
* The image range of any given element of pname:pRanges must: be a image subresource range that is contained within pname:image
* The image range of any given element of pname:pRanges must: be an image subresource range that is contained within pname:image
* pname:image mustnot: have a compressed or depth/stencil format
ifndef::doctype-manpage[]
********************************************************************************

2
doc/specs/vulkan/validity/protos/vkCmdClearDepthStencilImage.txt
View File

@ -20,7 +20,7 @@ endif::doctype-manpage[]
* pname:image must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
* pname:imageLayout must: specify the layout of the image subresource ranges of pname:image specified in pname:pRanges at the time this command is executed on a sname:VkDevice
* pname:imageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL
* The image range of any given element of pname:pRanges must: be a image subresource range that is contained within pname:image
* The image range of any given element of pname:pRanges must: be an image subresource range that is contained within pname:image
* pname:image must: have a depth/stencil format
ifndef::doctype-manpage[]
********************************************************************************

2
doc/specs/vulkan/validity/protos/vkCmdDispatch.txt
View File

@ -23,7 +23,7 @@ endif::doctype-manpage[]
* If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties
* Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/protos/vkCmdDispatchIndirect.txt
View File

@ -25,7 +25,7 @@ endif::doctype-manpage[]
* If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties
* Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/protos/vkCmdDraw.txt
View File

@ -24,7 +24,7 @@ endif::doctype-manpage[]
* If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties
* Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/protos/vkCmdDrawIndexed.txt
View File

@ -25,7 +25,7 @@ endif::doctype-manpage[]
* If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties
* Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/protos/vkCmdDrawIndexedIndirect.txt
View File

@ -32,7 +32,7 @@ endif::doctype-manpage[]
* If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties
* Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/protos/vkCmdDrawIndirect.txt
View File

@ -32,7 +32,7 @@ endif::doctype-manpage[]
* If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* If the <<features-features-robustBufferAccess,robust buffer access>> feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set
* Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties
* Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

1
doc/specs/vulkan/validity/protos/vkCmdResetEvent.txt
View File

@ -17,6 +17,7 @@ endif::doctype-manpage[]
* Each of pname:commandBuffer and pname:event must: have been created, allocated or retrieved from the same sname:VkDevice
* If the <<features-features-geometryShader,geometry shaders>> feature is not enabled, pname:stageMask mustnot: contain ename:VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT
* If the <<features-features-tessellationShader,tessellation shaders>> feature is not enabled, pname:stageMask mustnot: contain ename:VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT or ename:VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT
* When this command executes, pname:event mustnot: be waited on by a fname:vkCmdWaitEvents command that is currently executing
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

4
doc/specs/vulkan/validity/protos/vkQueueSubmit.txt
View File

@ -11,8 +11,8 @@ endif::doctype-manpage[]
* If pname:submitCount is not `0`, pname:pSubmits must: be a pointer to an array of pname:submitCount valid sname:VkSubmitInfo structures
* If pname:fence is not sname:VK_NULL_HANDLE, pname:fence must: be a valid sname:VkFence handle
* Each of pname:queue and pname:fence that are valid handles must: have been created, allocated or retrieved from the same sname:VkDevice
* pname:fence must: be unsignalled
* pname:fence mustnot: be associated with any other queue command that has not yet completed execution on that queue
* If pname:fence is not sname:VK_NULL_HANDLE, pname:fence must: be unsignalled
* If pname:fence is not sname:VK_NULL_HANDLE, pname:fence mustnot: be associated with any other queue command that has not yet completed execution on that queue
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

1
doc/specs/vulkan/validity/protos/vkResetEvent.txt
View File

@ -11,6 +11,7 @@ endif::doctype-manpage[]
* pname:event must: be a valid sname:VkEvent handle
* pname:event must: have been created, allocated or retrieved from pname:device
* Each of pname:device and pname:event must: have been created, allocated or retrieved from the same sname:VkPhysicalDevice
* pname:event mustnot: be waited on by a fname:vkCmdWaitEvents command that is currently executing
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

14
doc/specs/vulkan/validity/structs/VkBufferImageCopy.txt
View File

@ -16,13 +16,13 @@ endif::doctype-manpage[]
* pname:imageOffset.y and (imageExtent.height + pname:imageOffset.y) must: both be greater than or equal to `0` and less than or equal to the image subresource height
* pname:imageOffset.z and (imageExtent.depth + pname:imageOffset.z) must: both be greater than or equal to `0` and less than or equal to the image subresource depth
* If the calling command's sname:VkImage parameter is a compressed format image:
* pname:bufferRowLength must: be a multiple of the compressed texel block width
* pname:bufferImageHeight must: be a multiple of the compressed texel block height
* all members of pname:imageOffset must: be a multiple of the corresponding dimensions of the compressed texel block
* pname:bufferOffset must: be a multiple of the compressed texel block size in bytes
* pname:imageExtent.width must: be a multiple of the compressed texel block width or (pname:imageExtent.width + pname:imageOffset.x) must: equal the image subresource width
* pname:imageExtent.height must: be a multiple of the compressed texel block height or (pname:imageExtent.height + pname:imageOffset.y) must: equal the image subresource height
* pname:imageExtent.depth must: be a multiple of the compressed texel block depth or (pname:imageExtent.depth + pname:imageOffset.z) must: equal the image subresource depth
** pname:bufferRowLength must: be a multiple of the compressed texel block width
** pname:bufferImageHeight must: be a multiple of the compressed texel block height
** all members of pname:imageOffset must: be a multiple of the corresponding dimensions of the compressed texel block
** pname:bufferOffset must: be a multiple of the compressed texel block size in bytes
** pname:imageExtent.width must: be a multiple of the compressed texel block width or (pname:imageExtent.width + pname:imageOffset.x) must: equal the image subresource width
** pname:imageExtent.height must: be a multiple of the compressed texel block height or (pname:imageExtent.height + pname:imageOffset.y) must: equal the image subresource height
** pname:imageExtent.depth must: be a multiple of the compressed texel block depth or (pname:imageExtent.depth + pname:imageOffset.z) must: equal the image subresource depth
* pname:bufferOffset, pname:bufferRowLength, pname:bufferImageHeight and all members of pname:imageOffset and pname:imageExtent must: respect the image transfer granularity requirements of the queue family that it will be submitted against, as described in <<devsandqueues-physical-device-enumeration,Physical Device Enumeration>>
* The pname:aspectMask member of pname:imageSubresource must: specify aspects present in the calling command's sname:VkImage parameter
* The pname:aspectMask member of pname:imageSubresource must: only have a single bit set

8
doc/specs/vulkan/validity/structs/VkBufferViewCreateInfo.txt
View File

@ -15,10 +15,10 @@ endif::doctype-manpage[]
* pname:offset must: be less than the size of pname:buffer
* pname:offset must: be a multiple of sname:VkPhysicalDeviceLimits::pname:minTexelBufferOffsetAlignment
* If pname:range is not equal to ename:VK_WHOLE_SIZE:
* pname:range must: be greater than `0`
* pname:range must: be a multiple of the element size of pname:format
* pname:range divided by the size of an element of pname:format, must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxTexelBufferElements
* the sum of pname:offset and pname:range must: be less than or equal to the size of pname:buffer
** pname:range must: be greater than `0`
** pname:range must: be a multiple of the element size of pname:format
** pname:range divided by the size of an element of pname:format, must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxTexelBufferElements
** the sum of pname:offset and pname:range must: be less than or equal to the size of pname:buffer
* pname:buffer must: have been created with a pname:usage value containing at least one of ename:VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT or ename:VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT
* If pname:buffer was created with pname:usage containing ename:VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT, pname:format must: be supported for uniform texel buffers, as specified by the ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT flag in sname:VkFormatProperties::pname:bufferFeatures returned by fname:vkGetPhysicalDeviceFormatProperties
* If pname:buffer was created with pname:usage containing ename:VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT, pname:format must: be supported for storage texel buffers, as specified by the ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT flag in sname:VkFormatProperties::pname:bufferFeatures returned by fname:vkGetPhysicalDeviceFormatProperties

16
doc/specs/vulkan/validity/structs/VkImageCopy.txt
View File

@ -21,15 +21,15 @@ endif::doctype-manpage[]
* pname:dstOffset.y and (pname:extent.height + pname:dstOffset.y) must: both be greater than or equal to `0` and less than or equal to the destination image subresource height
* pname:dstOffset.z and (pname:extent.depth + pname:dstOffset.z) must: both be greater than or equal to `0` and less than or equal to the destination image subresource depth
* If the calling command's pname:srcImage is a compressed format image:
* all members of pname:srcOffset must: be a multiple of the corresponding dimensions of the compressed texel block
* pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:srcOffset.x) must: equal the source image subresource width
* pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:srcOffset.y) must: equal the source image subresource height
* pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:srcOffset.z) must: equal the source image subresource depth
** all members of pname:srcOffset must: be a multiple of the corresponding dimensions of the compressed texel block
** pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:srcOffset.x) must: equal the source image subresource width
** pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:srcOffset.y) must: equal the source image subresource height
** pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:srcOffset.z) must: equal the source image subresource depth
* If the calling command's pname:dstImage is a compressed format image:
* all members of pname:dstOffset must: be a multiple of the corresponding dimensions of the compressed texel block
* pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:dstOffset.x) must: equal the destination image subresource width
* pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:dstOffset.y) must: equal the destination image subresource height
* pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:dstOffset.z) must: equal the destination image subresource depth
** all members of pname:dstOffset must: be a multiple of the corresponding dimensions of the compressed texel block
** pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:dstOffset.x) must: equal the destination image subresource width
** pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:dstOffset.y) must: equal the destination image subresource height
** pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:dstOffset.z) must: equal the destination image subresource depth
* pname:srcOffset, pname:dstOffset, and pname:extent must: respect the image transfer granularity requirements of the queue family that it will be submitted against, as described in <<devsandqueues-physical-device-enumeration,Physical Device Enumeration>>
ifndef::doctype-manpage[]
********************************************************************************

5
doc/specs/vulkan/vkapi.py
View File

@ -113,7 +113,8 @@ consts['VK_STRUCTURE_TYPE_MIR_SURFACE_CREATE_INFO_KHR'] = 'VkStructureType'
consts['VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR'] = 'VkStructureType'
consts['VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR'] = 'VkStructureType'
consts['VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT'] = 'VkStructureType'
enums['VkStructureType'] = ['VK_STRUCTURE_TYPE_APPLICATION_INFO', 'VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO', 'VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO', 'VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO', 'VK_STRUCTURE_TYPE_SUBMIT_INFO', 'VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO', 'VK_STRUCTURE_TYPE_MAPPED_MEMORY_RANGE', 'VK_STRUCTURE_TYPE_BIND_SPARSE_INFO', 'VK_STRUCTURE_TYPE_FENCE_CREATE_INFO', 'VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO', 'VK_STRUCTURE_TYPE_EVENT_CREATE_INFO', 'VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO', 'VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO', 'VK_STRUCTURE_TYPE_BUFFER_VIEW_CREATE_INFO', 'VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO', 'VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO', 'VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_CACHE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_INPUT_ASSEMBLY_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_DEPTH_STENCIL_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_DYNAMIC_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO', 'VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_LAYOUT_CREATE_INFO', 'VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO', 'VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO', 'VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_CREATE_INFO', 'VK_STRUCTURE_TYPE_DESCRIPTOR_SET_ALLOCATE_INFO', 'VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET', 'VK_STRUCTURE_TYPE_COPY_DESCRIPTOR_SET', 'VK_STRUCTURE_TYPE_FRAMEBUFFER_CREATE_INFO', 'VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO', 'VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO', 'VK_STRUCTURE_TYPE_BUFFER_MEMORY_BARRIER', 'VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER', 'VK_STRUCTURE_TYPE_MEMORY_BARRIER', 'VK_STRUCTURE_TYPE_LOADER_INSTANCE_CREATE_INFO', 'VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO', 'VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_PRESENT_INFO_KHR', 'VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR', 'VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_MIR_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT']
consts['VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD'] = 'VkStructureType'
enums['VkStructureType'] = ['VK_STRUCTURE_TYPE_APPLICATION_INFO', 'VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO', 'VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO', 'VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO', 'VK_STRUCTURE_TYPE_SUBMIT_INFO', 'VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO', 'VK_STRUCTURE_TYPE_MAPPED_MEMORY_RANGE', 'VK_STRUCTURE_TYPE_BIND_SPARSE_INFO', 'VK_STRUCTURE_TYPE_FENCE_CREATE_INFO', 'VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO', 'VK_STRUCTURE_TYPE_EVENT_CREATE_INFO', 'VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO', 'VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO', 'VK_STRUCTURE_TYPE_BUFFER_VIEW_CREATE_INFO', 'VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO', 'VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO', 'VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_CACHE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_INPUT_ASSEMBLY_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_DEPTH_STENCIL_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_DYNAMIC_STATE_CREATE_INFO', 'VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO', 'VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_CREATE_INFO', 'VK_STRUCTURE_TYPE_PIPELINE_LAYOUT_CREATE_INFO', 'VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO', 'VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO', 'VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_CREATE_INFO', 'VK_STRUCTURE_TYPE_DESCRIPTOR_SET_ALLOCATE_INFO', 'VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET', 'VK_STRUCTURE_TYPE_COPY_DESCRIPTOR_SET', 'VK_STRUCTURE_TYPE_FRAMEBUFFER_CREATE_INFO', 'VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO', 'VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO', 'VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO', 'VK_STRUCTURE_TYPE_BUFFER_MEMORY_BARRIER', 'VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER', 'VK_STRUCTURE_TYPE_MEMORY_BARRIER', 'VK_STRUCTURE_TYPE_LOADER_INSTANCE_CREATE_INFO', 'VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO', 'VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_PRESENT_INFO_KHR', 'VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR', 'VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_MIR_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR', 'VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT', 'VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD']
# Unprocessed type: void
# Unprocessed type: uint32_t
# Unprocessed type: VkFlags category: basetype
@ -988,7 +989,7 @@ protos['vkCmdCopyBuffer'] = ['commandBuffer', 'srcBuffer', 'dstBuffer', 'region
structs['VkImageSubresourceLayers'] = ['aspectMask', 'mipLevel', 'baseArrayLayer', 'layerCount']
structs['VkImageCopy'] = ['srcSubresource', 'srcOffset', 'dstSubresource', 'dstOffset', 'extent']
protos['vkCmdCopyImage'] = ['commandBuffer', 'srcImage', 'srcImageLayout', 'dstImage', 'dstImageLayout', 'regionCount', 'pRegions']
structs['VkImageBlit'] = ['srcSubresource', 'srcOffsets[2]', 'dstSubresource', 'dstOffsets[2]']
structs['VkImageBlit'] = ['srcSubresource', 'srcOffsets', 'dstSubresource', 'dstOffsets']
protos['vkCmdBlitImage'] = ['commandBuffer', 'srcImage', 'srcImageLayout', 'dstImage', 'dstImageLayout', 'regionCount', 'pRegions', 'filter']
structs['VkBufferImageCopy'] = ['bufferOffset', 'bufferRowLength', 'bufferImageHeight', 'imageSubresource', 'imageOffset', 'imageExtent']
protos['vkCmdCopyBufferToImage'] = ['commandBuffer', 'srcBuffer', 'dstImage', 'dstImageLayout', 'regionCount', 'pRegions']

2
doc/specs/vulkan/vkspec.txt
View File

@ -3,7 +3,7 @@
include::specversion.txt[]
= {apiname} {apirevision} - A Specification
= Vulkan {apirevision} - A Specification
The Khronos Vulkan Working Group
:icons:
:toc2:

13
src/spec/generator.py
View File

@ -1745,11 +1745,14 @@ class ValidityOutputGenerator(OutputGenerator):
asciidoc += self.makeParameterName(paramname.text)
validextensionstructs = param.attrib.get('validextensionstructs')
if validextensionstructs is None:
asciidoc += ' must: be `NULL`'
else:
extensionstructs = validextensionstructs.split(',')
asciidoc += ' must: point to one of ' + extensionstructs[:-1].join(', ') + ' or ' + extensionstructs[-1] + 'if the extension that introduced them is enabled '
asciidoc += ' must: be `NULL`'
if validextensionstructs is not None:
extensionstructs = ['slink:' + x for x in validextensionstructs.split(',')]
asciidoc += ', or a pointer to a valid instance of '
if len(extensionstructs) == 1:
asciidoc += validextensionstructs
else:
asciidoc += (', ').join(extensionstructs[:-1]) + ' or ' + extensionstructs[-1]
asciidoc += '\n'

2736
src/spec/readme.pdf
View File

File diff suppressed because it is too large Load Diff

29
src/spec/readme.tex
View File

@ -411,6 +411,9 @@ member.
\paragraph{Attributes of \tag{member} tags}
\begin{itemize}
\item \attr{validextensionstructs} - only valid on the \code{pNext} member of a
struct. This is a comma-separated list of structures that may be
accepted by \code{pNext} instead of \code{NULL}
\item \attr{len} - if the member is an array, len may be one or more of the
following things, separated by commas (one for each array
indirection): another member of that struct; ``null-terminated'' for a
@ -419,9 +422,13 @@ member.
latexmath:[\$} and {\tt \$]}.
\item \attr{externsync} - denotes that the member should be externally
synchronized when accessed by Vulkan
\item \attr{optional} - whether this value can be omitted by providing
\code{NULL} (for pointers), \code{VK_NULL_HANDLE} (for handles) or 0
(for bitmasks/values)
\item \attr{optional} - a value of 'true' or 'false' determines whether this
member can be omitted by providing \code{NULL} (for pointers),
\code{VK_NULL_HANDLE} (for handles) or 0 (for bitmasks/values). If the
member is a pointer to one of those types, multiple values may be
provided, separated by commas - one for each pointer indirection.
Note that this only affects automatic validity statements - explicit
statements remain unchanged.
\item \attr{noautovalidity} - prevents automatic validity language being
generated for the tagged item. Only suppresses item-specific validity
- parenting issues etc. are still captured.
@ -795,9 +802,13 @@ members.
string; ``1'' to indicate it's just a pointer (used for nested
pointers); or an equation (a simple expression prefixed with
``math:'')
\item \attr{optional} - whether this value can be omitted by providing
\code{NULL} (for pointers), \code{VK_NULL_HANDLE} (for handles) or 0
(for bitmasks/values)
\item \attr{optional} - a value of 'true' or 'false' determines whether this
member can be omitted by providing \code{NULL} (for pointers),
\code{VK_NULL_HANDLE} (for handles) or 0 (for bitmasks/values). If the
member is a pointer to one of those types, multiple values may be
provided, separated by commas - one for each pointer indirection.
Note that this only affects automatic validity statements - explicit
statements remain unchanged.
\item \attr{noautovalidity} - prevents automatic validity language being
generated for the tagged item. Only suppresses item-specific validity
- parenting issues etc. are still captured.
@ -918,7 +929,7 @@ When processed into a C header for Vulkan, this results in:
#define VK_MAX_EXTENSION_NAME 256
#define VK_LOD_CLAMP_NONE MAX_FLOAT
typedef VkResult (VKAPI_PTR *PFN_vkCreateInstance)(const VkInstanceCreateInfo* pCreateInfo, VkInstance* pInstance);
#ifdef VK_PROTOTYPES
#ifndef VK_NO_PROTOTYPES
VKAPI_ATTR VkResult VKAPI_CALL vkCreateInstance(
const VkInstanceCreateInfo* pCreateInfo,
VkInstance* pInstance);
@ -1033,7 +1044,7 @@ typedef VkResult (VKAPI_PTR *PFN_vkCreateSharedSwapchainsKHR)(
const VkAllocationCallbacks* pAllocator,
VkSwapchainKHR* pSwapchains);
#ifdef VK_PROTOTYPES
#ifndef VK_NO_PROTOTYPES
VKAPI_ATTR VkResult VKAPI_CALL vkCreateSharedSwapchainsKHR(
VkDevice device,
uint32_t swapchainCount,
@ -1503,7 +1514,7 @@ VK_DEFINE_DISP_SUBCLASS_HANDLE(VkInstance, VkObject)
#define VK_MAX_PHYSICAL_DEVICE_NAME 256
#define VK_MAX_EXTENSION_NAME 256
typedef VkResult (VKAPI_PTR *PFN_vkCreateInstance)(const VkInstanceCreateInfo* pCreateInfo, VkInstance* pInstance);
#ifdef VK_PROTOTYPES
#ifndef VK_NO_PROTOTYPES
VKAPI_ATTR VkResult VKAPI_CALL vkCreateInstance(
const VkInstanceCreateInfo* pCreateInfo,
VkInstance* pInstance);

2
src/spec/registry.rnc
View File

@ -298,7 +298,7 @@ Command = element command {
# Each <feature> defines the interface of an API version (e.g. OpenGL 1.2)
# api - API tag (e.g. 'gl', 'gles2', etc. - used internally, not
# neccessarily an actual API name
# necessarily an actual API name
# name - version name (C preprocessor name, e.g. GL_VERSION_4_2)
# number - version number, e.g. 4.2
# protect - additional #ifdef symbol to place around the feature

2
src/spec/test.c
View File

@ -13,7 +13,7 @@ int main(int ac, const char **av) {
VkStructureType sType;
VkResult result;
// Supress warnings about unused variables
// Suppress warnings about unused variables
(void)sType; (void)result;
sType = VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR;

104
src/spec/vk.xml
View File

@ -101,7 +101,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<type category="define">// Vulkan 1.0 version number
#define <name>VK_API_VERSION_1_0</name> <type>VK_MAKE_VERSION</type>(1, 0, 0)</type> <!-- The patch version here should never be set to anything other than 0 -->
<type category="define">// Version of this file
#define <name>VK_HEADER_VERSION</name> 11</type>
#define <name>VK_HEADER_VERSION</name> 12</type>
<type category="define">
#define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@ -336,6 +336,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<type name="VkDebugReportFlagBitsEXT" category="enum"/>
<type name="VkDebugReportObjectTypeEXT" category="enum"/>
<type name="VkDebugReportErrorEXT" category="enum"/>
<type name="VkRasterizationOrderAMD" category="enum"/>
<!-- The PFN_vk*Function types are used by VkAllocationCallbacks below -->
<type category="funcpointer">typedef void (VKAPI_PTR *<name>PFN_vkInternalAllocationNotification</name>)(
@ -692,11 +693,11 @@ maintained in the master branch of the Khronos Vulkan Github project.
<validity>
<usage>pname:offset must: be less than the size of pname:buffer</usage>
<usage>pname:offset must: be a multiple of sname:VkPhysicalDeviceLimits::pname:minTexelBufferOffsetAlignment</usage>
<usage>If pname:range is not equal to ename:VK_WHOLE_SIZE:</usage>
<usage> pname:range must: be greater than `0`</usage>
<usage> pname:range must: be a multiple of the element size of pname:format</usage>
<usage> pname:range divided by the size of an element of pname:format, must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxTexelBufferElements</usage>
<usage> the sum of pname:offset and pname:range must: be less than or equal to the size of pname:buffer</usage>
<usage>If pname:range is not equal to ename:VK_WHOLE_SIZE:
** pname:range must: be greater than `0`
** pname:range must: be a multiple of the element size of pname:format
** pname:range divided by the size of an element of pname:format, must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxTexelBufferElements
** the sum of pname:offset and pname:range must: be less than or equal to the size of pname:buffer</usage>
<usage>pname:buffer must: have been created with a pname:usage value containing at least one of ename:VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT or ename:VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT</usage>
<usage>If pname:buffer was created with pname:usage containing ename:VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT, pname:format must: be supported for uniform texel buffers, as specified by the ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT flag in sname:VkFormatProperties::pname:bufferFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>If pname:buffer was created with pname:usage containing ename:VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT, pname:format must: be supported for storage texel buffers, as specified by the ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT flag in sname:VkFormatProperties::pname:bufferFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
@ -977,24 +978,24 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>pname:dstOffset.x and (pname:extent.width + pname:dstOffset.x) must: both be greater than or equal to `0` and less than or equal to the destination image subresource width</usage>
<usage>pname:dstOffset.y and (pname:extent.height + pname:dstOffset.y) must: both be greater than or equal to `0` and less than or equal to the destination image subresource height</usage>
<usage>pname:dstOffset.z and (pname:extent.depth + pname:dstOffset.z) must: both be greater than or equal to `0` and less than or equal to the destination image subresource depth</usage>
<usage>If the calling command's pname:srcImage is a compressed format image:</usage>
<usage> all members of pname:srcOffset must: be a multiple of the corresponding dimensions of the compressed texel block</usage>
<usage> pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:srcOffset.x) must: equal the source image subresource width</usage>
<usage> pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:srcOffset.y) must: equal the source image subresource height</usage>
<usage> pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:srcOffset.z) must: equal the source image subresource depth</usage>
<usage>If the calling command's pname:dstImage is a compressed format image:</usage>
<usage> all members of pname:dstOffset must: be a multiple of the corresponding dimensions of the compressed texel block</usage>
<usage> pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:dstOffset.x) must: equal the destination image subresource width</usage>
<usage> pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:dstOffset.y) must: equal the destination image subresource height</usage>
<usage> pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:dstOffset.z) must: equal the destination image subresource depth</usage>
<usage>If the calling command's pname:srcImage is a compressed format image:
** all members of pname:srcOffset must: be a multiple of the corresponding dimensions of the compressed texel block
** pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:srcOffset.x) must: equal the source image subresource width
** pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:srcOffset.y) must: equal the source image subresource height
** pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:srcOffset.z) must: equal the source image subresource depth</usage>
<usage>If the calling command's pname:dstImage is a compressed format image:
** all members of pname:dstOffset must: be a multiple of the corresponding dimensions of the compressed texel block
** pname:extent.width must: be a multiple of the compressed texel block width or (pname:extent.width + pname:dstOffset.x) must: equal the destination image subresource width
** pname:extent.height must: be a multiple of the compressed texel block height or (pname:extent.height + pname:dstOffset.y) must: equal the destination image subresource height
** pname:extent.depth must: be a multiple of the compressed texel block depth or (pname:extent.depth + pname:dstOffset.z) must: equal the destination image subresource depth</usage>
<usage>pname:srcOffset, pname:dstOffset, and pname:extent must: respect the image transfer granularity requirements of the queue family that it will be submitted against, as described in &lt;&lt;devsandqueues-physical-device-enumeration,Physical Device Enumeration&gt;&gt;</usage>
</validity>
</type>
<type category="struct" name="VkImageBlit">
<member><type>VkImageSubresourceLayers</type> <name>srcSubresource</name></member>
<member><type>VkOffset3D</type> <name>srcOffsets[2]</name></member> <!-- Specified in pixels for both compressed and uncompressed images -->
<member><type>VkOffset3D</type> <name>srcOffsets</name>[2]</member> <!-- Specified in pixels for both compressed and uncompressed images -->
<member><type>VkImageSubresourceLayers</type> <name>dstSubresource</name></member>
<member><type>VkOffset3D</type> <name>dstOffsets[2]</name></member> <!-- Specified in pixels for both compressed and uncompressed images -->
<member><type>VkOffset3D</type> <name>dstOffsets</name>[2]</member> <!-- Specified in pixels for both compressed and uncompressed images -->
<validity>
<usage>The pname:aspectMask member of pname:srcSubresource and pname:dstSubresource must: match</usage>
<usage>The pname:layerCount member of pname:srcSubresource and pname:dstSubresource must: match</usage>
@ -1024,14 +1025,14 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>pname:imageOffset.x and (pname:imageExtent.width + pname:imageOffset.x) must: both be greater than or equal to `0` and less than or equal to the image subresource width</usage>
<usage>pname:imageOffset.y and (imageExtent.height + pname:imageOffset.y) must: both be greater than or equal to `0` and less than or equal to the image subresource height</usage>
<usage>pname:imageOffset.z and (imageExtent.depth + pname:imageOffset.z) must: both be greater than or equal to `0` and less than or equal to the image subresource depth</usage>
<usage>If the calling command's sname:VkImage parameter is a compressed format image:</usage>
<usage> pname:bufferRowLength must: be a multiple of the compressed texel block width</usage>
<usage> pname:bufferImageHeight must: be a multiple of the compressed texel block height</usage>
<usage> all members of pname:imageOffset must: be a multiple of the corresponding dimensions of the compressed texel block</usage>
<usage> pname:bufferOffset must: be a multiple of the compressed texel block size in bytes</usage>
<usage> pname:imageExtent.width must: be a multiple of the compressed texel block width or (pname:imageExtent.width + pname:imageOffset.x) must: equal the image subresource width</usage>
<usage> pname:imageExtent.height must: be a multiple of the compressed texel block height or (pname:imageExtent.height + pname:imageOffset.y) must: equal the image subresource height</usage>
<usage> pname:imageExtent.depth must: be a multiple of the compressed texel block depth or (pname:imageExtent.depth + pname:imageOffset.z) must: equal the image subresource depth</usage>
<usage>If the calling command's sname:VkImage parameter is a compressed format image:
** pname:bufferRowLength must: be a multiple of the compressed texel block width
** pname:bufferImageHeight must: be a multiple of the compressed texel block height
** all members of pname:imageOffset must: be a multiple of the corresponding dimensions of the compressed texel block
** pname:bufferOffset must: be a multiple of the compressed texel block size in bytes
** pname:imageExtent.width must: be a multiple of the compressed texel block width or (pname:imageExtent.width + pname:imageOffset.x) must: equal the image subresource width
** pname:imageExtent.height must: be a multiple of the compressed texel block height or (pname:imageExtent.height + pname:imageOffset.y) must: equal the image subresource height
** pname:imageExtent.depth must: be a multiple of the compressed texel block depth or (pname:imageExtent.depth + pname:imageOffset.z) must: equal the image subresource depth</usage>
<usage>pname:bufferOffset, pname:bufferRowLength, pname:bufferImageHeight and all members of pname:imageOffset and pname:imageExtent must: respect the image transfer granularity requirements of the queue family that it will be submitted against, as described in &lt;&lt;devsandqueues-physical-device-enumeration,Physical Device Enumeration&gt;&gt;</usage>
<usage>The pname:aspectMask member of pname:imageSubresource must: specify aspects present in the calling command's sname:VkImage parameter</usage>
<usage>The pname:aspectMask member of pname:imageSubresource must: only have a single bit set</usage>
@ -1251,7 +1252,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
</type>
<type category="struct" name="VkPipelineRasterizationStateCreateInfo">
<member><type>VkStructureType</type> <name>sType</name></member> <!-- Must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_CREATE_INFO -->
<member>const <type>void</type>* <name>pNext</name></member> <!-- Pointer to next structure -->
<member validextensionstructs="VkPipelineRasterizationStateRasterizationOrderAMD">const <type>void</type>* <name>pNext</name></member> <!-- Pointer to next structure -->
<member optional="true"><type>VkPipelineRasterizationStateCreateFlags</type> <name>flags</name></member> <!-- Reserved -->
<member><type>VkBool32</type> <name>depthClampEnable</name></member>
<member><type>VkBool32</type> <name>rasterizerDiscardEnable</name></member>
@ -2129,6 +2130,11 @@ maintained in the master branch of the Khronos Vulkan Github project.
<member><type>PFN_vkDebugReportCallbackEXT</type> <name>pfnCallback</name></member> <!-- Function pointer of a callback function-->
<member optional="true"><type>void</type>* <name>pUserData</name></member> <!-- User data provided to callback function -->
</type>
<type category="struct" name="VkPipelineRasterizationStateRasterizationOrderAMD">
<member><type>VkStructureType</type> <name>sType</name></member> <!-- Must be VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD -->
<member>const <type>void</type>* <name>pNext</name></member> <!-- Pointer to next structure -->
<member><type>VkRasterizationOrderAMD</type> <name>rasterizationOrder</name></member> <!-- Rasterization order to use for the pipeline -->
</type>
</types>
<!-- SECTION: Vulkan enumerant (token) definitions. -->
@ -2630,12 +2636,12 @@ maintained in the master branch of the Khronos Vulkan Github project.
<enum value="2" name="VK_TIMEOUT" comment="A wait operation has not completed in the specified time"/>
<enum value="3" name="VK_EVENT_SET" comment="An event is signaled"/>
<enum value="4" name="VK_EVENT_RESET" comment="An event is unsignalled"/>
<enum value="5" name="VK_INCOMPLETE" comment="A return array was too small for the resul"/>
<enum value="5" name="VK_INCOMPLETE" comment="A return array was too small for the result"/>
<!-- Error codes (negative values) -->
<enum value="-1" name="VK_ERROR_OUT_OF_HOST_MEMORY" comment="A host memory allocation has failed"/>
<enum value="-2" name="VK_ERROR_OUT_OF_DEVICE_MEMORY" comment="A device memory allocation has failed"/>
<enum value="-3" name="VK_ERROR_INITIALIZATION_FAILED" comment="The logical device has been lost. See &lt;&lt;devsandqueues-lost-device&gt;&gt;"/>
<enum value="-4" name="VK_ERROR_DEVICE_LOST" comment="Initialization of a object has failed"/>
<enum value="-3" name="VK_ERROR_INITIALIZATION_FAILED" comment="Initialization of a object has failed"/>
<enum value="-4" name="VK_ERROR_DEVICE_LOST" comment="The logical device has been lost. See &lt;&lt;devsandqueues-lost-device&gt;&gt;"/>
<enum value="-5" name="VK_ERROR_MEMORY_MAP_FAILED" comment="Mapping of a memory object has failed"/>
<enum value="-6" name="VK_ERROR_LAYER_NOT_PRESENT" comment="Layer specified does not exist"/>
<enum value="-7" name="VK_ERROR_EXTENSION_NOT_PRESENT" comment="Extension specified does not exist"/>
@ -2933,6 +2939,10 @@ maintained in the master branch of the Khronos Vulkan Github project.
<enum value="0" name="VK_DEBUG_REPORT_ERROR_NONE_EXT"/> <!-- Used for INFO & other non-error messages -->
<enum value="1" name="VK_DEBUG_REPORT_ERROR_CALLBACK_REF_EXT"/> <!-- Callbacks were not destroyed prior to calling DestroyInstance -->
</enums>
<enums name="VkRasterizationOrderAMD" type="enum">
<enum value="0" name="VK_RASTERIZATION_ORDER_STRICT_AMD"/> <!-- Rasterization order strictly follows API order -->
<enum value="1" name="VK_RASTERIZATION_ORDER_RELAXED_AMD"/> <!-- Rasterization order may not follow API order -->
</enums>
<!-- SECTION: Vulkan command definitions -->
<commands>
@ -3077,8 +3087,8 @@ maintained in the master branch of the Khronos Vulkan Github project.
<param len="submitCount" externsync="pSubmits[].pWaitSemaphores[],pSubmits[].pSignalSemaphores[]">const <type>VkSubmitInfo</type>* <name>pSubmits</name></param>
<param optional="true" externsync="true"><type>VkFence</type> <name>fence</name></param>
<validity>
<usage>pname:fence must: be unsignalled</usage>
<usage>pname:fence mustnot: be associated with any other queue command that has not yet completed execution on that queue</usage>
<usage>If pname:fence is not sname:VK_NULL_HANDLE, pname:fence must: be unsignalled</usage>
<usage>If pname:fence is not sname:VK_NULL_HANDLE, pname:fence mustnot: be associated with any other queue command that has not yet completed execution on that queue</usage>
</validity>
</command>
<command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY,VK_ERROR_DEVICE_LOST">
@ -3327,6 +3337,9 @@ maintained in the master branch of the Khronos Vulkan Github project.
<proto><type>VkResult</type> <name>vkResetEvent</name></proto>
<param><type>VkDevice</type> <name>device</name></param>
<param externsync="true"><type>VkEvent</type> <name>event</name></param>
<validity>
<usage>pname:event mustnot: be waited on by a fname:vkCmdWaitEvents command that is currently executing</usage>
</validity>
</command>
<command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
<proto><type>VkResult</type> <name>vkCreateQueryPool</name></proto>
@ -3918,7 +3931,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
</validity>
</command>
<command queues="graphics" renderpass="inside" cmdbufferlevel="primary,secondary">
@ -3944,7 +3957,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
</validity>
</command>
<command queues="graphics" renderpass="inside" cmdbufferlevel="primary,secondary">
@ -3974,7 +3987,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
</validity>
</command>
<command queues="graphics" renderpass="inside" cmdbufferlevel="primary,secondary">
@ -4004,7 +4017,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
</validity>
</command>
<command queues="compute" renderpass="outside" cmdbufferlevel="primary,secondary">
@ -4026,7 +4039,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
</validity>
</command>
<command queues="compute" renderpass="outside" cmdbufferlevel="primary,secondary">
@ -4047,7 +4060,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If any sname:VkSampler object that is accessed from a shader by the sname:VkPipeline currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE uses unnormalized coordinates, it mustnot: be used with any of the SPIR-V `OpImageSample*` or `OpImageSparseSample*` instructions that includes a lod bias or any offset values, in any shader stage</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a uniform buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>If the &lt;&lt;features-features-robustBufferAccess,robust buffer access&gt;&gt; feature is not enabled, and any shader stage in the sname:VkPipeline object currently bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE accesses a storage buffer, it mustnot: access values outside of the range of that buffer specified in the currently bound descriptor set</usage>
<usage>Any sname:VkImage being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>Any sname:VkImageView being sampled with ename:VK_FILTER_LINEAR as a result of this command must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
</validity>
</command>
<command queues="transfer,graphics,compute" renderpass="outside" cmdbufferlevel="primary,secondary">
@ -4118,6 +4131,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If either of pname:srcImage or pname:dstImage was created with an unsigned integer elink:VkFormat, the other must: also have been created with an unsigned integer elink:VkFormat</usage>
<usage>If either of pname:srcImage or pname:dstImage was created with a depth/stencil format, the other must: have exactly the same format</usage>
<usage>If pname:srcImage was created with a depth/stencil format, pname:filter must: be ename:VK_FILTER_NEAREST</usage>
<usage>If pname:filter is ename:VK_FILTER_LINEAR, pname:srcImage must: be of a format which supports linear filtering, as specified by the ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT flag in sname:VkFormatProperties::pname:linearTilingFeatures (for a linear image) or sname:VkFormatProperties::pname:optimalTilingFeatures(for an optimally tiled image) returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
</validity>
</command>
<command queues="transfer,graphics,compute" renderpass="outside" cmdbufferlevel="primary,secondary">
@ -4203,7 +4217,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>pname:image must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag</usage>
<usage>pname:imageLayout must: specify the layout of the image subresource ranges of pname:image specified in pname:pRanges at the time this command is executed on a sname:VkDevice</usage>
<usage>pname:imageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL</usage>
<usage>The image range of any given element of pname:pRanges must: be a image subresource range that is contained within pname:image</usage>
<usage>The image range of any given element of pname:pRanges must: be an image subresource range that is contained within pname:image</usage>
<usage>pname:image mustnot: have a compressed or depth/stencil format</usage>
</validity>
</command>
@ -4219,7 +4233,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>pname:image must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag</usage>
<usage>pname:imageLayout must: specify the layout of the image subresource ranges of pname:image specified in pname:pRanges at the time this command is executed on a sname:VkDevice</usage>
<usage>pname:imageLayout must: be either of ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL or ename:VK_IMAGE_LAYOUT_GENERAL</usage>
<usage>The image range of any given element of pname:pRanges must: be a image subresource range that is contained within pname:image</usage>
<usage>The image range of any given element of pname:pRanges must: be an image subresource range that is contained within pname:image</usage>
<usage>pname:image must: have a depth/stencil format</usage>
</validity>
</command>
@ -4278,6 +4292,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<validity>
<usage>If the &lt;&lt;features-features-geometryShader,geometry shaders&gt;&gt; feature is not enabled, pname:stageMask mustnot: contain ename:VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT</usage>
<usage>If the &lt;&lt;features-features-tessellationShader,tessellation shaders&gt;&gt; feature is not enabled, pname:stageMask mustnot: contain ename:VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT or ename:VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT</usage>
<usage>When this command executes, pname:event mustnot: be waited on by a fname:vkCmdWaitEvents command that is currently executing</usage>
</validity>
</command>
<command queues="graphics,compute" renderpass="both" cmdbufferlevel="primary,secondary">
@ -5168,10 +5183,13 @@ maintained in the master branch of the Khronos Vulkan Github project.
<enum value="&quot;VK_AMD_extension_2&quot;" name="VK_AMD_EXTENSION_2_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_3" number="19" author="AMD" contact="Daniel Rakos @aqnuep" supported="disabled">
<extension name="VK_AMD_rasterization_order" number="19" author="AMD" contact="Daniel Rakos @aqnuep" supported="vulkan">
<require>
<enum value="0" name="VK_AMD_EXTENSION_3_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_3&quot;" name="VK_AMD_EXTENSION_3_EXTENSION_NAME"/>
<enum value="1" name="VK_AMD_RASTERIZATION_ORDER_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_rasterization_order&quot;" name="VK_AMD_RASTERIZATION_ORDER_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD"/>
<type name="VkRasterizationOrderAMD"/>
<type name="VkPipelineRasterizationStateRasterizationOrderAMD"/>
</require>
</extension>
<extension name="VK_AMD_extension_4" number="20" author="AMD" contact="Daniel Rakos @aqnuep" supported="disabled">

25
src/vulkan/vulkan.h
View File

@ -43,7 +43,7 @@ extern "C" {
#define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
#define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
// Version of this file
#define VK_HEADER_VERSION 11
#define VK_HEADER_VERSION 12
#define VK_NULL_HANDLE 0
@ -210,6 +210,7 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR = 1000008000,
VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR = 1000009000,
VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT = 1000011000,
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD = 1000018000,
VK_STRUCTURE_TYPE_BEGIN_RANGE = VK_STRUCTURE_TYPE_APPLICATION_INFO,
VK_STRUCTURE_TYPE_END_RANGE = VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO,
VK_STRUCTURE_TYPE_RANGE_SIZE = (VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO - VK_STRUCTURE_TYPE_APPLICATION_INFO + 1),
@ -3828,6 +3829,28 @@ VKAPI_ATTR void VKAPI_CALL vkDebugReportMessageEXT(
#define VK_IMG_FILTER_CUBIC_EXTENSION_NAME "VK_IMG_filter_cubic"
#define VK_AMD_rasterization_order 1
#define VK_AMD_RASTERIZATION_ORDER_SPEC_VERSION 1
#define VK_AMD_RASTERIZATION_ORDER_EXTENSION_NAME "VK_AMD_rasterization_order"
typedef enum VkRasterizationOrderAMD {
VK_RASTERIZATION_ORDER_STRICT_AMD = 0,
VK_RASTERIZATION_ORDER_RELAXED_AMD = 1,
VK_RASTERIZATION_ORDER_BEGIN_RANGE_AMD = VK_RASTERIZATION_ORDER_STRICT_AMD,
VK_RASTERIZATION_ORDER_END_RANGE_AMD = VK_RASTERIZATION_ORDER_RELAXED_AMD,
VK_RASTERIZATION_ORDER_RANGE_SIZE_AMD = (VK_RASTERIZATION_ORDER_RELAXED_AMD - VK_RASTERIZATION_ORDER_STRICT_AMD + 1),
VK_RASTERIZATION_ORDER_MAX_ENUM_AMD = 0x7FFFFFFF
} VkRasterizationOrderAMD;
typedef struct VkPipelineRasterizationStateRasterizationOrderAMD {
VkStructureType sType;
const void* pNext;
VkRasterizationOrderAMD rasterizationOrder;
} VkPipelineRasterizationStateRasterizationOrderAMD;
#ifdef __cplusplus
}
#endif