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 July 15, 2016 Vulkan 1.0.21 spec update: 

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

Github Issues:

  * Clarify how <<features-supported-sample-counts,sample count queries>>
    relate to the limits in slink:VkPhysicalDeviceLimits. (public issue
    185).
  * Clarify in the <<interfaces-iointerfaces,Shader Input and Output
    Interfaces>> section that shader output variables have undefined values
    until the shader writes to them (public issue 240).
  * Specify the implicit value of image parameters that cannot be set in
    slink:VkSwapchainCreateInfo::pname:flags, pname:imageType,
    pname:mipLevels, pname:samples, pname:tiling, and pname:initialLayout
    (public issue 243).
  * Make use of code:NULL and code:VK_NULL_HANDLE consistent in the
    VK_KHR_swapchain extension (public issue 276).

Internal Issues:

  * Clarify that presenting an image to a display surface swapchain applies
    the display surface's mode, and that destroying a display surface
    swapchain may reset the display's mode, in the VK_KHR_display_swapchain
    extension (internal issue 247).
  * Better describe what a slink:VkSurfaceKHR is, and that creating one does
    not set a mode, in the VK_KHR_display extension. This is a round-about
    way of pointing out that mode setting is not covered by the extension,
    but rather is performed as a side effect of presentation (internal issue
    247).
  * Add more valid usage statements to flink:vkQueuePresentKHR command when
    the VK_KHR_display_swapchain extension is present (internal issue
    247).
  * Add more includes to the VK_KHR_swapchain extension to better document
    interactions with VK_KHR_display_swapchain (internal issue 247).
  * Clarify restrictions on location aliasing in the
    <<fxvertex,Fixed-Function Vertex Processing>> section (internal issue
    370).
  * Add mathematical description of blitting to flink:vkCmdBlitImage, and
    link it to the <<textures,Image Operations>> chapter. Use mathematical
    notation for ranges of texel coordinates in the <<textures,Image
    Operations>> chapter. Fixed miscellaneous validity statements for
    flink:vkCmdBlit and slink:VkImageBlit (internal issue 382).

Other Commits:

  * Added a valid usage rule to flink:VkGraphicsPipelineCreateInfo that the
    ename:VK_PRIMITIVE_TOPOLOGY_PATCH_LIST topology must only be used when
    tessellation shaders are used.
  * Expand the style guide into a formal "Procedures and Conventions"
    document. Add a API Naming Conventions section, move most of the API
    Specification Appendix C (Layers and Extensions) content into the new
    document, and define the resulting procedures as mandatory (where
    relevant). This more clearly separates use vs. specification of Vulkan
    APIs.
  * Update vk_platform.h to handle 32-bit ARMv8 binaries.
  * Various minor cleanups to the Makefile and build process.
This commit is contained in:
Jon Leech 2016-07-15 19:05:43 -07:00
parent e71db8fc50
commit f4c4113d07
84 changed files with 2522 additions and 1714 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

114
ChangeLog.txt
View File

@ -23,7 +23,7 @@ Change log for February 25, 2015 Vulkan 1.0.4 spec update:
memory areas (public issue 5).
* Use standards-compliant preprocessor guard symbols on headers
(public issue 7).
* Note that Github users can't currently set labels on issues, and
* Note that Github users cannot currently set labels on issues, and
recommend a fallback approach (public issue 15).
* Use latexmath prefix on len= attributes (public issue 29).
* Make flink:vkCmdUpdateBuffer pname:dataSize limit consistent (public
@ -60,7 +60,7 @@ Change log for February 25, 2015 Vulkan 1.0.4 spec update:
design choices and pointing to the public repository to file issues.
* Put include of validity in the core spec extensions chapter on its
own line, so that asciidoc is happy.
* Fix vertexOffset language to specify that it's the value added to
* Fix vertexOffset language to specify that it is the value added to
the vertex index before indexing into the vertex buffer, not the
base offset within the index buffer.
* Fix error in the description of flink:vkCmdNextSubpass.
@ -176,7 +176,7 @@ Github Issues:
section (public issues 80, 81).
* Remove discussion of return codes from
flink:vkGetPhysicalDeviceSparseImageFormatProperties and
flink:vkGetImageSparseMemoryRequirements, which don't return values
flink:vkGetImageSparseMemoryRequirements, which do not return values
(public issue 82).
* Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect
pname:drawCount of 0, as well as 1, when the multiDrawIndirect
@ -213,7 +213,7 @@ Github Issues:
in the PDF title. Fix label on <<fig-non-strict-lines,Non
strict lines>> diagram. Use more easily distinguished symbols in
tables in the <<features-required-format-support,Required
Format Support>> section. Don't require FQDNs used as layer names be
Format Support>> section. Do not require FQDNs used as layer names be
encoded in lower case if not possible, in the
<<extensions-naming-conventions, Extension and Layer Naming
Conventions>> section (public issues 101, 119, 121).
@ -269,7 +269,7 @@ Github Issues:
aliasing issues (public issue 14).
* Clarify the meaning of "matching" in flink:vkCmdBindDescriptorSets
validity language (public issue 33).
* Add stub reference pages so xrefs to not-yet-written pages don't
* Add stub reference pages so xrefs to not-yet-written pages do not
generate 404 errors. However, the actual content of these pages
still needs to be filled in as time allows (public issue 44, but
does not close that issue out).
@ -336,7 +336,7 @@ Change log for April 1, 2016 Vulkan 1.0.8 spec update:
Github Issues:
* Specify in the validity language for flink:vkBeginCommandBuffer that
pname:commandBuffer mustnot: currently be pending execution (public
pname:commandBuffer must not currently be pending execution (public
issue 96).
* Describe depth comparison using the correct temporary variable names
in the <<textures-depth-compare-operation,Depth Compare Operation>>
@ -550,7 +550,7 @@ Github Issues:
* 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
chains using the ptext:pNext member must include initial
ptext:sType and ptext:pNext members (public issue 192).
Internal Issues:
@ -577,7 +577,7 @@ Other Commits:
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
* Replace the {apiname} macro with hardcoded "Vulkan", now that we have
committed to that name.
* Add the VK_AMD_rasterization_order extension to vk.xml.
@ -782,9 +782,9 @@ Github Issues:
Internal Issues:
* Document deprecation of ename:VK_COLORSPACE_SRGB_NONLINEAR_KHR in the
VK_KHR_surface extension branch, and of
VK_KHR_surface extension, and of
ename:VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT in the
VK_EXT_debug_report branch (internal issue 328).
VK_EXT_debug_report extension (internal issue 328).
* Added language to define what a valid usage statement is and should be,
with a note about some apparent weirdnesses this might entail (internal
issue 357).
@ -835,7 +835,7 @@ Github Issues:
sure these terms are referenced correctly (public issue 163).
* Update valid usage for ftext:vkGet*ProcAddr to only include
conditions that must be met to get a valid result. In particular,
it's okay to call flink:vkGetDeviceProcAddr with any string and will
it is okay to call flink:vkGetDeviceProcAddr with any string and will
get a code:NULL if that string is not a core Vulkan function or an
enabled extension function (addresses but does not fully close
public issue 214).
@ -893,8 +893,8 @@ Github Issues:
flink:vkGetImageMemoryRequirements (public issue 257).
* Remove ename:VK_ERROR_LAYER_NOT_PRESENT error code from
flink:vkCreateDevice (public issue 259).
* Change "must not" to "should not" in constraint on when
flink:vkAcquireNextImageKHR is called in the +VK_KHR_swapchain+ branch
* Change "must: not" to "should: not" in constraint on when
flink:vkAcquireNextImageKHR is called in the VK_KHR_swapchain branch
(public issue 262).
* Change type of flink:vkCmdUpdateBuffer::pname:pData from
basetype:uint32_t* to basetype:void* (public issue 263).
@ -913,34 +913,96 @@ Internal Issues:
Integration,wsi>> chapter (internal issue 374).
* The language of a Note was too broad, and implied that loaders for a
given OS would statically export functions for WSI extensions that
weren't relevant to (or supported on) the OS. Also, removed
"Khronos-provided" since the Android loader isn't (internal issue 380)
were not relevant to (or supported on) the OS. Also, removed
"Khronos-provided" since the Android loader is not (internal issue 380)
Other Commits:
* Add ename:VK_INCOMPLETE to list of return values for
flink:vkGetPipelineCacheData. Spec says this value is returnable, but it
wasn't listed in the error codes.
was not listed in the error codes.
* Fix "correponds" typo in member definitions for
slink:VkSubpassDescription.
-----------------------------------------------------
Change log for July 10, 2016 Vulkan 1.0.20 spec update:
Change log for July 8, 2016 Vulkan 1.0.20 spec update:
* Bump API patch number and header version number to 20 for this
update.
Github Issues:
* Replaced existing reference pages by text automatically extracted
from the specification source, or generated from vk.xml in some
cases. This isn't a complete solution for the reference pages, but
puts them in a much better state. The ref pages (only) are now
placed under a CC BY open source license, which is more current than
the obsolete license previously used.
* Replaced existing reference pages by text automatically extracted from
the specification source, or generated from vk.xml in some cases. This
is not a complete solution for the reference pages, but puts them in a
much better state. The ref pages (only) are now placed under a CC BY
open source license, which is more current than the obsolete license
previously used. Various minor tweaks to the Specification sources were
made to enable this, and a new ``API Boilerplate'' chapter added to
include definitions of all the entities in the API and +vulkan.h+ which
were not already described in some form in the document.
Further improvements to the pages should not edit them directly, but
instead concentrate on the specification source from which the ref
pages are being extracted (public issues 44, 55, 160; internal issue
389).
instead concentrate on the specification source from which the ref pages
are being extracted (public issues 44, 55, 160; internal issue 389).
-----------------------------------------------------
Change log for July 15, 2016 Vulkan 1.0.21 spec update:
* Bump API patch number and header version number to 21 for this update.
Github Issues:
* Clarify how <<features-supported-sample-counts,sample count queries>>
relate to the limits in slink:VkPhysicalDeviceLimits. (public issue
185).
* Clarify in the <<interfaces-iointerfaces,Shader Input and Output
Interfaces>> section that shader output variables have undefined values
until the shader writes to them (public issue 240).
* Specify the implicit value of image parameters that cannot be set in
slink:VkSwapchainCreateInfo::pname:flags, pname:imageType,
pname:mipLevels, pname:samples, pname:tiling, and pname:initialLayout
(public issue 243).
* Make use of code:NULL and code:VK_NULL_HANDLE consistent in the
VK_KHR_swapchain extension (public issue 276).
Internal Issues:
* Clarify that presenting an image to a display surface swapchain applies
the display surface's mode, and that destroying a display surface
swapchain may reset the display's mode, in the VK_KHR_display_swapchain
extension (internal issue 247).
* Better describe what a slink:VkSurfaceKHR is, and that creating one does
not set a mode, in the VK_KHR_display extension. This is a round-about
way of pointing out that mode setting is not covered by the extension,
but rather is performed as a side effect of presentation (internal issue
247).
* Add more valid usage statements to flink:vkQueuePresentKHR command when
the VK_KHR_display_swapchain extension is present (internal issue
247).
* Add more includes to the VK_KHR_swapchain extension to better document
interactions with VK_KHR_display_swapchain (internal issue 247).
* Clarify restrictions on location aliasing in the
<<fxvertex,Fixed-Function Vertex Processing>> section (internal issue
370).
* Add mathematical description of blitting to flink:vkCmdBlitImage, and
link it to the <<textures,Image Operations>> chapter. Use mathematical
notation for ranges of texel coordinates in the <<textures,Image
Operations>> chapter. Fixed miscellaneous validity statements for
flink:vkCmdBlit and slink:VkImageBlit (internal issue 382).
Other Commits:
* Added a valid usage rule to flink:VkGraphicsPipelineCreateInfo that the
ename:VK_PRIMITIVE_TOPOLOGY_PATCH_LIST topology must only be used when
tessellation shaders are used.
* Expand the style guide into a formal "Procedures and Conventions"
document. Add a API Naming Conventions section, move most of the API
Specification Appendix C (Layers and Extensions) content into the new
document, and define the resulting procedures as mandatory (where
relevant). This more clearly separates use vs. specification of Vulkan
APIs.
* Update vk_platform.h to handle 32-bit ARMv8 binaries.
* Various minor cleanups to the Makefile and build process.

97
doc/specs/vulkan/Makefile
View File

@ -17,7 +17,7 @@ all: alldocs allchecks
alldocs: allspecs allman
allspecs: xhtml chunked pdf
allspecs: xhtml chunked pdf styleguide
allman: manhtml manpdf manpages manhtmlpages
@ -48,6 +48,7 @@ HTMLDIR := $(OUTDIR)/html
XHTMLDIR := $(OUTDIR)/xhtml
PDFDIR := $(OUTDIR)/pdf
CHECKDIR := $(OUTDIR)/checks
STYLEXHTMLDIR := $(OUTDIR)/style
# Images used in the API spec
IMAGEPATH :=images
ICONPATH :=$(IMAGEPATH)/icons
@ -64,20 +65,20 @@ KEEP =
# XMLLINT normally unset - to detect problems with intermediate files
# NOTEOPTS sets options controlling which NOTEs are generated
# ATTRIBOPTS sets the api revision and enables MathJax generation
# VKCONF contains Vulkan-specific Asciidoc macros
# CONFIG Vulkan-specific Asciidoc macros. File used depends on target.
# 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 apirevision="$(SPECREVISION)" -a mathjax
VKCONF = config/vkspec.conf
CONFIG = config/vkspec.conf
ADOCOPTS = $(ATTRIBOPTS) $(NOTEOPTS) -f config/mathjax-asciidoc.conf \
-f $(VKCONF) $(VERBOSE)
-f $(CONFIG) $(VERBOSE)
ADOCPDFOPTS= $(ATTRIBOPTS) $(NOTEOPTS) -f config/mathjax-docbook.conf \
-f $(VKCONF) $(VERBOSE)
-f $(CONFIG) $(VERBOSE)
A2XOPTS = $(ATTRIBOPTS) $(NOTEOPTS) \
--asciidoc-opts="-f config/mathjax-docbook.conf -f $(VKCONF)" \
--asciidoc-opts="-f config/mathjax-docbook.conf -f $(CONFIG)" \
--xsltproc-opts="--param generate.consistent.ids 1" \
$(XMLLINT) $(VERBOSE) --icons
@ -95,23 +96,12 @@ DIRT = $(SPECVERSION)
.PHONY: directories $(MANHTMLDIR) $(MANPAGEDIR)
ICONFILES := \
$(ICONPATH)/caution.png \
$(ICONPATH)/example.png \
$(ICONPATH)/home.png \
$(ICONPATH)/important.png \
$(ICONPATH)/next.png \
$(ICONPATH)/note.png \
$(ICONPATH)/prev.png \
$(ICONPATH)/tip.png \
$(ICONPATH)/up.png \
$(ICONPATH)/warning.png
ICONFILES := $(wildcard $(ICONPATH)/*.png)
PNGFILES := $(ICONFILES) $(wildcard $(IMAGEPATH)/*.png)
# This is a horrible hack to avoid pulling in vulkantexture0.svg
SVGFILES := $(wildcard $(IMAGEPATH)/[A-Za-uw-z]*.svg)
# Don't use vulkantexture0.svg as a source SVG file, PNG is available
SVGFILES := $(filter-out $(IMAGEPATH)/vulkantexture0.svg,$(wildcard $(IMAGEPATH)/*.svg))
PDFFILES := $(SVGFILES:.svg=.pdf)
# Some random directories and files that need to be copied into spec
# output directory
# Misc. directories and files that need to be copied into output directory
WEBIMAGES := $(SVGFILES:%=$(HTMLDIR)/%) $(PNGFILES:%=$(HTMLDIR)/%)
# File suffix for image targets for HTML and PDF Builds - Asciidoc {svgtype} attribute
SVGTYPEHTML := svg
@ -126,7 +116,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.20
SPECREVISION = 1.0.21
SPECREMARK =
# Spec targets
@ -135,13 +125,14 @@ SPECREMARK =
html: $(HTMLDIR)/vkspec.html $(TOPDOC) $(COMMONDOCS) $(WEBIMAGES)
$(HTMLDIR)/vkspec.html: $(VKCONF) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS) $(WEBIMAGES)
$(HTMLDIR)/vkspec.html: $(CONFIG) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS) $(WEBIMAGES)
$(QUIET)if test ! -d $(HTMLDIR) ; then $(MKDIR) $(HTMLDIR) ; fi
$(QUIET)$(ASCIIDOC) -b html5 $(ADOCOPTS) -o $(HTMLDIR)/vkspec.html -a svgpdf=$(SVGTYPEHTML) $(TOPDOC)
$(QUIET)$(ASCIIDOC) -b html5 $(ADOCOPTS) \
-o $(HTMLDIR)/vkspec.html -a svgpdf=$(SVGTYPEHTML) $(TOPDOC)
xhtml: $(XHTMLDIR)/vkspec.html $(TOPDOC) $(COMMONDOCS)
$(XHTMLDIR)/vkspec.html: $(VKCONF) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS)
$(XHTMLDIR)/vkspec.html: $(CONFIG) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS)
$(QUIET)if test ! -d $(XHTMLDIR) ; then $(MKDIR) $(XHTMLDIR) ; fi
$(QUIET)$(A2X) $(A2XOPTS) -f xhtml $(TOPDOC) \
--xsl-file=$(XHTMLXSL) \
@ -150,7 +141,7 @@ $(XHTMLDIR)/vkspec.html: $(VKCONF) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS)
chunked: $(OUTDIR)/vkspec.chunked/index.html $(TOPDOC) $(COMMONDOCS)
$(OUTDIR)/vkspec.chunked/index.html: $(VKCONF) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS)
$(OUTDIR)/vkspec.chunked/index.html: $(CONFIG) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS)
$(QUIET)if test ! -d $(OUTDIR)/chunked ; then $(MKDIR) $(OUTDIR) ; fi
$(QUIET)$(A2X) $(A2XOPTS) -f chunked $(TOPDOC) \
--xsl-file=$(CHUNKEDXSL) \
@ -165,7 +156,7 @@ $(PDFDIR)/vkspec.pdf: $(PDFXSL) $(PDFSTY) $(PDFDIR)/vkspec.xml
-p $(PDFXSL) -s $(PDFSTY) \
$(PDFDIR)/vkspec.xml -O $(PDFDIR)
$(PDFDIR)/vkspec.xml: $(VKCONF) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS) $(PDFDIR) $(PDFFILES)
$(PDFDIR)/vkspec.xml: $(CONFIG) $(SPECVERSION) $(TOPDOC) $(COMMONDOCS) $(PDFDIR) $(PDFFILES)
$(QUIET)$(ASCIIDOC) --backend docbook $(ADOCPDFOPTS) \
-a a2x-format=pdf -a svgpdf=pdf \
--out-file $(PDFDIR)/vkspec.xml $(TOPDOC)
@ -196,12 +187,14 @@ $(SPECVERSION): $(GITHEAD)
"commit:" `git log -1 --format="%H"` >> $@
endif
STYLESRC = styleguide.txt
STYLEFILES = $(wildcard style/[A-Za-z]*.txt)
styleguide: $(OUTDIR)/styleguide.html
STYLESRC = style/styleguide.txt
$(OUTDIR)/styleguide.html: $(VKCONF) $(SPECVERSION) $(STYLESRC)
$(OUTDIR)/styleguide.html: $(CONFIG) $(SPECVERSION) $(STYLESRC) $(STYLEFILES)
$(QUIET)$(ASCIIDOC) -b html5 $(ADOCOPTS) \
-o $(OUTDIR)/styleguide.html -a svgpdf=$(SVGTYPEHTML) \
-o $@ -a svgpdf=$(SVGTYPEHTML) \
$(STYLESRC)
clean: clean_html clean_pdf clean_chunked clean_checks clean_dirt clean_man
@ -213,11 +206,15 @@ clean_man:
$(RMRF) $(MANPAGEDIR)
clean_html:
$(QUIET)$(RMRF) $(HTMLDIR) $(XHTMLDIR)
$(QUIET)$(RM) $(OUTDIR)/apispec.html
$(QUIET)$(RMRF) $(HTMLDIR) $(XHTMLDIR) $(STYLEXHTMLDIR)
$(QUIET)$(RM) $(OUTDIR)/apispec.html $(OUTDIR)/styleguide.html
clean_pdf:
$(QUIET)$(RM) $(PDFDIR)/vkspec.pdf $(PDFDIR)/vkspec.xml $(OUTDIR)/apispec.pdf
$(QUIET)$(RM) \
$(PDFDIR)/vkspec.pdf \
$(PDFDIR)/vkspec.xml \
$(OUTDIR)/apispec.pdf \
$(OUTDIR)/apispec.xml
clean_chunked:
$(QUIET)$(RMRF) $(OUTDIR)/vkspec.chunked
@ -254,8 +251,6 @@ manpages: $(MANPAGEDIR) $(MANPAGES)
manhtmlpages: $(MANHTMLDIR) $(MANHTML)
manhtmlpages: VKCONF=config/manpages.conf
# Automatic generation of ref pages. Needs to have a proper dependency
# causing the man page sources to be generated by running genRef (once),
# but adding $(MANSOURCES) to the targets causes genRef to run
@ -268,13 +263,19 @@ man/apispec.txt: $(CHAPTERS) genRef.py reflib.py vkapi.py
$(MANPAGEDIR)/%.$(MANSECTION): $(MANDIR)/%.$(MANSECTION)
$(QUIET)mv $< $@
$(MANDIR)/%.$(MANSECTION): CONFIG=config/manpages.conf
$(MANDIR)/%.$(MANSECTION): $(MANDIR)/%.txt $(MANCOPYRIGHT) config/manpages.conf
$(QUIET)$(ECHO) Building $@
$(QUIET)$(A2X) -d manpage -f manpage --asciidoc-opts "-f config/manpages.conf" $(A2XOPTS) $<
$(MANHTMLDIR)/%.html: CONFIG=config/manpages.conf
$(MANHTMLDIR)/%.html: $(MANDIR)/%.txt $(MANCOPYRIGHT) config/manpages.conf
$(QUIET)$(ECHO) Building $@
$(QUIET)$(A2X) -d manpage -f xhtml --asciidoc-opts "-f config/manpages.conf" --stylesheet=vkman.css $(A2XOPTS) --destination-dir=$(@D) $<
$(QUIET)$(ASCIIDOC) -b html5 -d manpage $(ADOCOPTS) \
-a themedir=$(CURDIR)/config -a theme=vkman \
-o $@ -a svgpdf=$(SVGTYPEHTML) $<
$(MANHTMLDIR):
$(QUIET)$(MKDIR) $@
@ -288,13 +289,22 @@ manpdf: $(OUTDIR)/apispec.pdf
manhtml: $(OUTDIR)/apispec.html
$(OUTDIR)/apispec.pdf: $(CONFFILE) man/apispec.txt $(MANSOURCES) $(MANCOPYRIGHT) $(PDFXSL)
$(QUIET)if test ! -d $(OUTDIR) ; then $(MKDIR) $(OUTDIR) ; fi
$(QUIET)$(A2X) -f pdf $(A2XDBLATEXOPTS) $(A2XOPTS) --icons man/apispec.txt --destination-dir=$(OUTDIR)
$(OUTDIR)/apispec.pdf: $(PDFXSL) $(PDFSTY) $(OUTDIR)/apispec.xml
$(QUIET)$(DBLATEX) -b pdftex $(DBLATEXOPTS) \
-p "$(DBLATEXPREFIX)/asciidoc-dblatex.xsl" \
-p $(PDFXSL) -s $(PDFSTY) \
$(OUTDIR)/apispec.xml -O $(OUTDIR)
$(OUTDIR)/apispec.html: $(CONFFILE) man/apispec.txt $(MANSOURCES) $(MANCOPYRIGHT) $(SVGFILES)
$(OUTDIR)/apispec.xml: $(CONFIG) $(SPECVERSION) man/apispec.txt $(MANSOURCES) $(MANCOPYRIGHT) $(PDFXSL) $(PDFSTY)
$(QUIET)$(ASCIIDOC) --backend docbook $(ADOCPDFOPTS) \
-a a2x-format=pdf -a svgpdf=pdf \
-o $@ man/apispec.txt
$(OUTDIR)/apispec.html: $(CONFIG) $(SPECVERSION) man/apispec.txt $(MANSOURCES) $(MANCOPYRIGHT) $(SVGFILES)
$(QUIET)if test ! -d $(OUTDIR) ; then $(MKDIR) $(OUTDIR) ; fi
$(QUIET)$(ASCIIDOC) -b html5 $(ADOCOPTS) -d book -b html --out-file=$(OUTDIR)/apispec.html man/apispec.txt
$(QUIET)$(ASCIIDOC) -b html5 -d book $(ADOCOPTS) \
-a themedir=$(CURDIR)/config -a theme=vkspec-xhtml \
-o $@ -a svgpdf=$(SVGTYPEHTML) man/apispec.txt
$(HTMLDIR)/images/%: images/%
$(QUIET)$(MKDIR) $(@D)
@ -344,5 +354,6 @@ checklinks:
$(QUIET)$(PYTHON) checkLinks.py -follow $(CHAPTERS) > $(CHECKDIR)/specErrs.txt
# README file with build instructions
README.html: README.txt
$(ASCIIDOC) -b html5 README.txt
README.html: $(CONFIG) $(SPECVERSION) README.txt
$(QUIET)$(ASCIIDOC) -b html5 $(ADOCOPTS) \
-o $@ README.txt

107
doc/specs/vulkan/README.html
View File

@ -729,6 +729,14 @@ install: function(toclevels) {
asciidoc.install();
/*]]>*/
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
MathML: { extensions: ["content-mathml.js"] },
tex2jax: { inlineMath: [['$','$'], ['\\(','\\)']] }
});
</script>
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
</head>
<body class="article">
<div id="header">
@ -789,6 +797,35 @@ asciidoc.install();
<div class="sect1">
<h2 id="intro">Introduction</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="http://www.khronos.org/">http://www.khronos.org/</a></p></div>
<div class="paragraph"><p><code><a href="#www.khronos.org">www.khronos.org</a></code></p></div>
<div class="paragraph"><p><code><a href="#out/apispec.pdf">out/apispec.pdf</a></code></p></div>
<div class="ulist"><ul>
<li>
<p>
link\:{path}/apispec.html#vkWaitForFences
</p>
<div class="ulist"><ul>
<li>
<p>
link:../vulkan/out/apispec.html#vkWaitForFences
</p>
</li>
</ul></div>
</li>
<li>
<p>
link\:{path}/apispec.html#vkWaitForFences\[Relpath\]
</p>
<div class="ulist"><ul>
<li>
<p>
<code><a href="#../vulkan/out/apispec.html#vkWaitForFences">../vulkan/out/apispec.html#vkWaitForFences</a></code>
</p>
</li>
</ul></div>
</li>
</ul></div>
<div class="paragraph"><p>This README describes important stuff for getting the Vulkan API
specification and reference pages building properly.</p></div>
</div>
@ -796,8 +833,14 @@ specification and reference pages building properly.</p></div>
<div class="sect1">
<h2 id="building">Building The Spec</h2>
<div class="sectionbody">
<div class="paragraph"><p>Assuming you have all the right tools installed (see <a href="#depends">Software Dependencies</a> below), you should be able to go to
<span class="monospaced">&#8230;path-to-git-repo/vulkan/doc/specs/vulkan</span> and:</p></div>
<div class="paragraph"><p>Assuming you have all the right tools installed (see <a href="#depends">Software Dependencies</a> below), go to
<span class="monospaced">&#8230;path-to-git-repo/vulkan/doc/specs/vulkan</span> .</p></div>
<div class="paragraph"><p>If the default values of ASCIIDOC and A2X are not correct for the
<span class="monospaced">asciidoc</span> and <span class="monospaced">a2x</span> scripts on your platform, change them via
environment variables, command line options, or by modifying the
<span class="monospaced">Makefile</span>. The default script names have <span class="monospaced">.py</span> suffixes. These suffixes
should be removed for Linux platforms, and possibly for other
non-Windows environments.</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>$ make all</pre>
@ -807,7 +850,7 @@ specification and reference pages building properly.</p></div>
<div class="content monospaced">
<pre>$ make xhtml chunked pdf manhtml manpdf manpages manhtmlpages checkinc checklinks</pre>
</div></div>
<div class="paragraph"><p>This should generate a variety of targets under <span class="monospaced">$(OUTDIR)</span> (by default,
<div class="paragraph"><p>This will generate a variety of targets under <span class="monospaced">$(OUTDIR)</span> (by default,
<span class="monospaced">../../../out/1.0</span>). The checked-in file <span class="monospaced">$(OUTDIR)/index.html</span> links to
them all, or they can individually be found as follows:</p></div>
<div class="ulist"><ul>
@ -818,39 +861,44 @@ API spec:
<div class="ulist"><ul>
<li>
<p>
Single-file XHTML (from a2x) - <span class="monospaced">$(OUTDIR)/xhtml/vkspec.html</span>
<span class="monospaced">xhtml</span> - Single-file XHTML in <span class="monospaced">$(OUTDIR)/xhtml/vkspec.html</span>
</p>
</li>
<li>
<p>
Chunked HTML (from a2x) - <span class="monospaced">$(OUTDIR)/vkspec.chunked/index.html</span>
<span class="monospaced">chunked</span> - Chunked HTML in <span class="monospaced">$(OUTDIR)/vkspec.chunked/index.html</span>
</p>
</li>
<li>
<p>
PDF (from a2x) - <span class="monospaced">$(OUTDIR)/pdf/vkspec.pdf</span>
<span class="monospaced">pdf</span> - PDF in <span class="monospaced">$(OUTDIR)/pdf/vkspec.pdf</span>
</p>
</li>
</ul></div>
</li>
<li>
<p>
Man pages:
Reference pages:
</p>
<div class="ulist"><ul>
<li>
<p>
Single-file HTML - <span class="monospaced">$(OUTDIR)/apispec.html</span>
<span class="monospaced">manhtml</span> - Single-file HTML in <span class="monospaced">$(OUTDIR)/apispec.html</span>
</p>
</li>
<li>
<p>
File-per-entry-point HTML - <span class="monospaced">$(OUTDIR)/man/html/*</span>
<span class="monospaced">manpdf</span> - Single-file PDF in <span class="monospaced">$(OUTDIR)/apispec.html</span>
</p>
</li>
<li>
<p>
File-per-entry-point nroff source - <span class="monospaced">$(OUTDIR)/man/3/*</span>
<span class="monospaced">manhtmlpages</span> - File-per-entry-point HTML in <span class="monospaced">$(OUTDIR)/man/html/*</span>
</p>
</li>
<li>
<p>
<span class="monospaced">manpages</span> - File-per-entry-point nroff source in <span class="monospaced">$(OUTDIR)/man/3/*</span>
</p>
</li>
</ul></div>
@ -862,31 +910,27 @@ Validator output:
<div class="ulist"><ul>
<li>
<p>
List of commands, structs, etc. missing from the API spec -
<span class="monospaced">checkinc</span> - List of commands, structs, etc. missing from the API spec in
<span class="monospaced">$(OUTDIR)/checks/notInSpec.txt</span>
</p>
</li>
<li>
<p>
Validator script output for API spec - +$(OUTDIR)/checks/specErrs.txt
</p>
</li>
<li>
<p>
Validator script output for reference pages -
<span class="monospaced">$(OUTDIR)/checks/manErrs.txt</span>
<span class="monospaced">checklinks</span> - Validator script output for API spec in
<span class="monospaced">$(OUTDIR)/checks/specErrs.txt and for reference pages in
+$(OUTDIR)/checks/manErrs.txt</span>
</p>
</li>
</ul></div>
</li>
</ul></div>
<div class="paragraph"><p>We strongly sugges that once you have the basic build working, you use e.g.</p></div>
<div class="paragraph"><p>Once you have the basic build working, an appropriate parallelization
option to make, such as</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>$ make -j 8</pre>
</div></div>
<div class="paragraph"><p>(or other appropriate number depending on the number of CPU cores you have)
to parallelize the reference page builds, since there are so many of them.</p></div>
<div class="paragraph"><p>will significantly speed up the reference page builds.</p></div>
<div class="paragraph"><p>If your asciidoc installation does not put the stylesheets and xsl files in
the standard <span class="monospaced">/etc/asciidoc/dblatex</span> directory, set the environment variable
<span class="monospaced">DBLATEXPREFIX</span> to the path to that directory (the one containing the
@ -983,9 +1027,10 @@ contents will not change.</p></div>
<td class="content">Section mostly TBD.</td>
</tr></table>
</div>
<div class="paragraph"><p>This branch introduces a Vulkan-specific XHTML CSS stylesheet
in <span class="monospaced">config/vkspec-xhtml.css</span> . Mostly it just clones the default
Asciidoc stylesheet, but adds some new features:</p></div>
<div class="paragraph"><p>This branch introduces a Vulkan-specific XHTML CSS stylesheet in
<span class="monospaced">config/vkspec-xhtml.css</span> . It started as a clone of the default
Asciidoc stylesheet, but added some new features. Similar CSS in
<span class="monospaced">config/vkman.css</span> is used for the reference pages.</p></div>
<div class="sect2">
<h3 id="_marking_changes">Marking Changes</h3>
<div class="paragraph"><p>There is the start of support for marking added, removed, and changed text
@ -1008,6 +1053,10 @@ removed words#.</pre>
<div class="paragraph"><p>The formatting of these roles text depends on the stylesheet. Currently it
all three roles are red text, and the "removed" role is also strike-through
text.</p></div>
<div class="paragraph"><p>We don&#8217;t use this capability yet; it&#8217;s just a proof of concept. It would
be a huge amount of work to insert this markup automatically for each
spec update, and it would be very difficult to do automatically based on
git diffs.</p></div>
</div>
<div class="sect2">
<h3 id="_marking_normative_language">Marking Normative Language</h3>
@ -1016,11 +1065,11 @@ this is supported <strong>only</strong> in the XHTML targets (<span class="monos
<div class="paragraph"><p>Normative language is marked with the asciidoc <strong>role</strong> named <em>normative</em>.
It can be used to mark entire paragraphs or spans of words, in the
same fashion as change markings (described above). In addition, the
normative terminology macros, such as must: and may: and cannot:,
normative terminology macros, such as <span role="normative">must</span> and <span role="normative">may</span> and <span role="normative">cannot</span>,
always use this role.</p></div>
<div class="paragraph"><p>The formatting of normative language depends on the stylesheet. Currently it
just comes out in purple. There will be some way to turn this on or off at
build time shortly.</p></div>
just comes out in purple. We may add a way to disable this formatting at
build time.</p></div>
</div>
</div>
</div>
@ -1227,7 +1276,7 @@ Devel/git (2.5.1-1) - Needed for updating specversion.txt
</li>
<li>
<p>
2015/11/11 - Add new can: etc. macros and DBLATEXPREFIX variable.
2015/11/11 - Add new <span role="normative">can</span> etc. macros and DBLATEXPREFIX variable.
</p>
</li>
<li>
@ -1261,7 +1310,7 @@ Devel/git (2.5.1-1) - Needed for updating specversion.txt
<div id="footer">
<div id="footer-text">
Last updated
2016-07-10 02:24:54 PDT
2016-07-14 03:33:23 PDT
</div>
</div>
</body>

57
doc/specs/vulkan/README.txt
View File

@ -22,8 +22,15 @@ specification and reference pages building properly.
== Building The Spec ==
Assuming you have all the right tools installed (see <<depends,Software
Dependencies>> below), you should be able to go to
+...path-to-git-repo/vulkan/doc/specs/vulkan+ and:
Dependencies>> below), go to
+...path-to-git-repo/vulkan/doc/specs/vulkan+ .
If the default values of ASCIIDOC and A2X are not correct for the
+asciidoc+ and +a2x+ scripts on your platform, change them via
environment variables, command line options, or by modifying the
+Makefile+. The default script names have +.py+ suffixes. These suffixes
should be removed for Linux platforms, and possibly for other
non-Windows environments.
$ make all
@ -31,31 +38,32 @@ or equivalently:
$ make xhtml chunked pdf manhtml manpdf manpages manhtmlpages checkinc checklinks
This should generate a variety of targets under +$(OUTDIR)+ (by default,
This will generate a variety of targets under +$(OUTDIR)+ (by default,
+../../../out/1.0+). The checked-in file +$(OUTDIR)/index.html+ links to
them all, or they can individually be found as follows:
* API spec:
** Single-file XHTML (from a2x) - +$(OUTDIR)/xhtml/vkspec.html+
** Chunked HTML (from a2x) - +$(OUTDIR)/vkspec.chunked/index.html+
** PDF (from a2x) - +$(OUTDIR)/pdf/vkspec.pdf+
* Man pages:
** Single-file HTML - +$(OUTDIR)/apispec.html+
** File-per-entry-point HTML - +$(OUTDIR)/man/html/*+
** File-per-entry-point nroff source - +$(OUTDIR)/man/3/*+
** +xhtml+ - Single-file XHTML in +$(OUTDIR)/xhtml/vkspec.html+
** +chunked+ - Chunked HTML in +$(OUTDIR)/vkspec.chunked/index.html+
** +pdf+ - PDF in +$(OUTDIR)/pdf/vkspec.pdf+
* Reference pages:
** +manhtml+ - Single-file HTML in +$(OUTDIR)/apispec.html+
** +manpdf+ - Single-file PDF in +$(OUTDIR)/apispec.html+
** +manhtmlpages+ - File-per-entry-point HTML in +$(OUTDIR)/man/html/*+
** +manpages+ - File-per-entry-point nroff source in +$(OUTDIR)/man/3/*+
* Validator output:
** List of commands, structs, etc. missing from the API spec -
** +checkinc+ - List of commands, structs, etc. missing from the API spec in
+$(OUTDIR)/checks/notInSpec.txt+
** Validator script output for API spec - +$(OUTDIR)/checks/specErrs.txt
** Validator script output for reference pages -
** +checklinks+ - Validator script output for API spec in
+$(OUTDIR)/checks/specErrs.txt and for reference pages in
+$(OUTDIR)/checks/manErrs.txt+
We strongly sugges that once you have the basic build working, you use e.g.
Once you have the basic build working, an appropriate parallelization
option to make, such as
$ make -j 8
(or other appropriate number depending on the number of CPU cores you have)
to parallelize the reference page builds, since there are so many of them.
will significantly speed up the reference page builds.
If your asciidoc installation does not put the stylesheets and xsl files in
the standard +/etc/asciidoc/dblatex+ directory, set the environment variable
@ -156,9 +164,10 @@ contents will not change.
NOTE: Section mostly TBD.
This branch introduces a Vulkan-specific XHTML CSS stylesheet
in +config/vkspec-xhtml.css+ . Mostly it just clones the default
Asciidoc stylesheet, but adds some new features:
This branch introduces a Vulkan-specific XHTML CSS stylesheet in
+config/vkspec-xhtml.css+ . It started as a clone of the default
Asciidoc stylesheet, but added some new features. Similar CSS in
+config/vkman.css+ is used for the reference pages.
=== Marking Changes ===
@ -183,6 +192,12 @@ The formatting of these roles text depends on the stylesheet. Currently it
all three roles are red text, and the "removed" role is also strike-through
text.
We don't use this capability yet; it's just a proof of concept. It would
be a huge amount of work to insert this markup automatically for each
spec update, and it would be very difficult to do automatically based on
git diffs.
=== Marking Normative Language ===
@ -196,8 +211,8 @@ normative terminology macros, such as must: and may: and cannot:,
always use this role.
The formatting of normative language depends on the stylesheet. Currently it
just comes out in purple. There will be some way to turn this on or off at
build time shortly.
just comes out in purple. We may add a way to disable this formatting at
build time.
[[equations]]

10
doc/specs/vulkan/appendices/boilerplate.txt
View File

@ -140,10 +140,9 @@ include::../defines/VK_VERSION_PATCH.txt[]
// refBegin VK_API_VERSION_1_0 - Return API version number for Vulkan 1.0
dname:VK_API_VERSION_1_0 returns the API version number for Vulkan 1.0. The
patch version number in this macro will always be zero. The required patch
version is specified by the application when creating an instance with
flink:vkCreateInstance, and the supported patch version for a physical
device can: be queried with flink:vkGetPhysicalDeviceProperties.
patch version number in this macro will always be zero. The supported patch
version for a physical device can: be queried with
flink:vkGetPhysicalDeviceProperties.
include::../defines/VK_API_VERSION_1_0.txt[]
@ -151,7 +150,7 @@ include::../defines/VK_API_VERSION_1_0.txt[]
// refBegin VK_API_VERSION - Deprecated version number macro
dname:VK_API_VERSION is deprecated and should: no longer be used.
dname:VK_API_VERSION is now commented out of +vulkan.h+ and cannot: be used.
include::../defines/VK_API_VERSION.txt[]
@ -214,7 +213,6 @@ include::../defines/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt[]
* pname:object is the name of the resulting C type.
Most Vulkan handle types, such as slink:VkBuffer, are non-dispatchable.
Only one such type is listed in the See Also section below.
// refEnd VK_DEFINE_NON_DISPATCHABLE_HANDLE VkBuffer

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

@ -17,575 +17,10 @@ http://www.khronos.org/registry/vulkan/
and allows generating versions of the Specification incorporating different
extensions.
[NOTE]
.Note
====
The mechanism and process of specifying extensions is subject to change, as
we receive feedback from authors and further requirements of documentation
tooling. This appendix will be updated as this evolves.
====
== Introduction
The Khronos extension registries and extension naming conventions serve
several purposes:
* Avoiding naming collisions between extensions developed by mutually
unaware parties, both in the extension names themselves, as well as
their token, command, and type names.
* Allocating enumerant values for tokens added by extensions
* Creating a defined order between extensions. Extensions with higher
numbers may: have dependencies upon extensions with lower numbers, and
must: define any relevant interactions with lower-numbered extensions.
* Provides a central repository for documentation and header changes
associated with extensions
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
members are expected to extend a Khronos API using the Layer mechanism.
* Namespaced constants (enumerations) that do not necessarily draw from a
single global set of token values.
== General Rules/Guidelines
Some general rules to simplify the specific rules below:
* Extensions and layers must: each have a globally unique name.
* All commands and tokens must: have a globally unique name.
* Extensions can: expose new commands, types, and/or tokens, but layers
mustnot:.
** However, layers can: expose their own extensions, which in turn are
allowed to expose new commands and tokens.
* 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 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.
[[extensions-naming-conventions]]
== Extension and Layer Naming Conventions
* Extensions are named with the syntax: +VK_AUTHOR_<name>+.
* Layers are named with the syntax: +VK_LAYER_{AUTHOR|FQDN}_<name>+.
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 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,
Google has separate Android and Chrome communities.
Details on how to register an author prefix are provided below. Layer
authors not wishing to register an author prefix with Khronos can: instead
use a fully-qualified domain name (FQDN) as the prefix. The FQDN should: be
a domain name owned by the author. FQDNs cannot: be used for extensions,
only for layers.
* The following are examples of extension and layer names, demonstrating
the above syntax:
** Extension names all use the base prefix +VK_+.
** Khronos-ratified extensions add the special author prefix +KHR+, and
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 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
developed via cooperation between, and intended to be supported by two
or more registered authors) add the special author prefix +EXT+ to the
base prefix, and will use the prefix +VK_EXT_+.
** Traditional author-specific extensions developed by one author (or one
author in cooperation with non-authors) add the author prefix to the
base prefix. For example, NVIDIA will use the prefix +VK_NV_+, and
Valve will use the prefix +VK_VALVE_+. Some authors can: have
additional registered author prefixes for special purposes. For
example, an Android extension developed by Google - but part of an
Android open-source community project, and so not a proprietary Google
extension - will use the prefix +VK_ANDROID_+.
** Layer names follow the same conventions as extensions, but use the base
prefix +VK_LAYER_+.
** Because layers need not be registered with Khronos, an alternative
prefix mechanism is needed to allow creating unique layer names without
registering an author prefix. Layer authors that prefer not to register
an author prefix can: instead use a fully-qualified domain name (FQDN)
in reverse-order as an author prefix, replacing +.+ (period) with `_`
(underscore) characters. For example, a layer written by the owner of
www.3dxcl.invalid would use the prefix `VK_LAYER_invalid_3dxcl_www_`.
FQDNs must: be encoded in UTF-8, and should: be in lower case, if
possible for the domain FQDN in question.
[NOTE]
.Note
====
To avoid linking to a nonexistent domain, the reserved TLD +.invalid+ is
used.
``Lower case'' is not a straightforward concept for all possible
encodings of domain names. We suggest using RFC 5895 to interpret this
phrase. The recommendation is that the representation of a FQDN in a layer
name should be the same way one would naturally type that name into a web
browser.
====
[[extensions-naming]]
== Extension Command, Type, and Token Naming Conventions
Extensions may: add new commands, types, and tokens, or collectively
``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.
A command or type name simply appends the author prefix. For example, a
Khronos-blessed extension could expose the following command:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
void vkDoSomethingKHR(void);
------------------------------------------------------------------------------
A Google extension could expose the following command:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
void vkDoSomethingGOOGLE(void);
------------------------------------------------------------------------------
And a multi-author extension could expose the following type:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
typedef struct VkSomeDataEXT;
------------------------------------------------------------------------------
Enumeration or constant token names are constructed by following the token
name with `_` and the author prefix, so a non-Khronos extension could expose
this enumeration:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
enum VkSomeValuesGRPHX {
VK_SOME_VALUE_0_GRPHX = 0,
VK_SOME_VALUE_1_GRPHX = 1,
VK_SOME_VALUE_2_GRPHX = 2,
};
------------------------------------------------------------------------------
[[extensions-api-registry]]
== The Vulkan Registry
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
structures, and other information which must be agreed on by all
implementations. The registry is used to maintain a single, consistent
global namespace for the registered entities, to generate the
Khronos-supplied +vulkan.h+, and to create a variety of related
documentation used in generating the API specification and reference pages.
[[extensions-author-prefix]]
== 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, 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
extensions is provided.
Extension authors will be able to create an account on the Khronos github
project and, using this account, register an author prefix with
Khronos. This string must: be used as the author prefix in any extensions
the author registers. The same account will be used to request registration
of extensions or layers with Khronos, as described below.
To reserve an author prefix, propose a merge request against
<<extensions-api-registry,+vk.xml+>>. The merge must: add a +<tag>+ XML tag
and fill in the +name+, +author+ and +contact+ attributes with the requested
author prefix, the author's formal name (e.g. company or project name), and
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 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.
[[extensions-vendor-id]]
== Registering a Vendor ID with Khronos
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,
implementations must: obtain a Khronos vendor ID.
Khronos vendor IDs are reserved in a similar fashion to
<<extensions-author-prefix,author prefixes>>. While vendor IDs are not
directly related to API extensions, the reservation process is very similar
and so is described in this section.
To reserve an Khronos vendor ID, you must first have a Khronos author
prefix. Propose a merge request against
<<extensions-api-registry,+vk.xml+>>. The merge must: add a +<vendorid>+ tag
and fill in the +name+ and +id+ attributes. The +name+ attribute must: be
set to the author prefix. The +id+ attribute must: be the first sequentially
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 Vulkan implementation and require one for that
purpose.
== Registering Extensions and Layers
Extensions must: be registered with Khronos. Layers may: be registered, and
registration is strongly recommended. Registration means:
* Receiving an extension number.
* 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 Vulkan API, including definitions of
those additions to +vk.xml+.
Registration for Khronos members is handled by filing a merge request in the
internal gitlab repository against the branch containing the core
specification against which the extension or layer will be written. The
merge must: modify +vk.xml+ to define extension names, API interfaces, and
related information. Registration is not complete until the registry
maintainer has validated and accepted the merge.
Since this process could in principle be completely automated, this
suggests a scalable mechanism for accepting registration of non-Khronos
extensions. Non-Khronos members who want to create extensions must: register
with Khronos by creating a github account, and registering their author
prefix and/or FQDNs to that account. They can: then submit new extension
registration requests by proposing merges to +vk.xml+. On acceptance of the
merge, the extension will be registered, though its specification need not
be checked into the Khronos github repository at that point.
The registration process can: be split into several steps to accommodate
extension number assignment prior to extension publication:
* Acquire an extension number. This is done by proposing a merge request
against +vk.xml+ similarly to how <<extensions-author-prefix,author
prefixes are reserved>>. The merge should: add a new +<extension>+ tag
at the end of the file with attributes specifying the proposed extension
+name+, the next unused sequential extension +number+, the +author+ and
+contact+ information (if different than that already specified for the
author prefix used in the extension name), and finally, specifying
+supported="disabled"+. The extension number will be reserved only once
this merge request is accepted into the master branch.
* 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 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
control of the publishers, to allow them to align publication on Khronos
with product releases. However, complete automation might be difficult,
since steps such as regenerating and validating +vulkan.h+ are involved.
Once the merge is accepted and the corresponding updated header with the
new extension interface is committed to the master branch, publication
is complete.
The automated process does not exist yet, and would require significant
investment in infrastructure to support the process on the Khronos servers.
ifdef::editing-notes[]
[NOTE]
.editing-note
====
TODO: This section is subject to change and not complete yet, but in broad
is how we expect extension registration and specifications to work. The
process will be refined as members and outside authors define further
extensions.
====
endif::editing-notes[]
== Documenting Extensions
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 Vulkan specification. As such, the branch name will
be: +1.0-VK_KHR_surface+
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
branch contents.
Extensions should: be merged according to their registered extension number.
If two extensions both modify the same portion of the specification, the
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 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
the +appendices/vk_khr_surface.txt+ file.
* Each extension's appendix file is included by adding an +include+
statement to the +vkspec.txt+ file. Since most extensions will all put
their +include+ line at the same place in this file, they should: add
this statement on the master branch, even though the file will not actually
exist on the master branch. This will avoid merge conflicts when
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
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 Vulkan specification,
the extension should: add a chapter to the Vulkan specification.
== Assigning Extension Token Values
Extensions can: define their own enumeration types and assign any values to
their enumerants that they like. Each enumeration has a private namespace,
so collisions are not a problem. However, when extending existing
enumeration objects with new values, care must: be taken to preserve global
uniqueness of values. Enumerations which define new bits in a bitmask are
treated specially as described in
<<extensions-reserving-bitmask-values,Reserving Bitmask Values>> below.
Each extension is assigned a range of values that can: be used to create
globally-unique enum values. Most values will be negative numbers, but
positive numbers are also reserved. The ability to create both positive and
negative extension values is necessary to enable extending enumerations such
as stext:VkResult that assign special meaning to negative and positive
values. Therefore, 1000 positive and 1000 negative values are reserved for
each extension. Extensions must: not define enum values outside their
reserved range without explicit permission from the owner of those values
(e.g. from the author of another extension whose range is infringed on, or
from the Khronos Registrar if the values do not belong to any extension's
range).
[NOTE]
.Note
====
Typically, extensions use a unique offset for each enumeration constant they
add, yielding 1000 distinct token values per extension. Since each
enumeration object has its own namespace, if an extension needs to add many
enumeration constant values, it can: reuse offsets on a per-type basis.
====
The information needed to add new values to the XML are as follows:
* The **extension name** (e.g. +VK_KHR_swapchain+) that is adding the new
enumeration constant.
* The existing enumeration **type** being extended (e.g.
stext:VkStructureType).
* The name of the new enumeration **token** being added (e.g.
etext:VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR).
* The **offset**, which is an integer between 0 and 999 relative to the
base being used for the extension.
* The **direction** may: be specified to indicate a negative value
(+dir="-"+) when needed for negative elink:VkResult values indicating
errors, like etext:VK_ERROR_SURFACE_LOST_KHR. The default direction is
positive, if not specified.
Implicit is the registered number of an extension, which is used to create a
range of unused values offset against a global extension base value.
Individual enumerant values are calculated as offsets in that range. Values
are calculated as follows:
* base_value = 1000000000
* range_size = 1000
* enum_offset(extension_number,offset) = base_value +
(extension_number - 1) × range_size + offset
* Positive values: enum_offset(extension_number,offset)
* Negative values: -enum_offset(extension_number,offset)
The exact syntax for specifying extension enumerant values is defined in the
+readme.pdf+ specifying the format of +vk.xml+, and extension authors can:
also refer to existing extensions for examples.
== Required Extension Tokens
In addition to any tokens specific to the functionality of an extension,
all extensions must: define two additional tokens.
* VK_EXTNAME_SPEC_VERSION is an integer constant which is the revision of
the extension named +VK_extname+ (EXTNAME is all upper-case, while
extname is the capitalization of the actual extension name) in
+vulkan.h+. This value begins at 1 with the initial version of an
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
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
behavior of the lowest-numbered revision can: be used.
* VK_EXTNAME_EXTENSION_NAME is a string constant which is the name of the
extension.
For example, for the WSI extension +VK_KHR_surface+, at the time of writing
the following definitions were in effect:
[source,c]
---------------------------------------------------
#define VK_KHR_SURFACE_SPEC_VERSION 24
#define VK_KHR_SURFACE_EXTENSION_NAME "VK_KHR_surface"
---------------------------------------------------
== Extension Objects, Enums, and Typedefs
Expanding on previous discussion, extensions can: add values to existing
enums; and can: add their own commands, enums, typedefs, etc. This is done
by adding to <<extensions-api-registry,+vk.xml+>>. All such additions will
be included in the +vulkan.h+ header supplied by Khronos.
[NOTE]
.Note
====
Application developers are encouraged to be careful when using +switch+
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.
====
[[extension-function_prototypes]]
== Extension Function Prototypes
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 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 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
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 Vulkan ABI.
The initial set of WSI extension commands (i.e. for VK_KHR_surface,
VK_KHR_swapchain, and VK_KHR_*_surface) are considered to be part of the
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.
[NOTE]
.Note
====
Based on feedback from implementers, Khronos expects that the Android,
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
these implementations.
====
== Accessing Extension Functions from Programs
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 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.
[NOTE]
.Note
====
The Vulkan API loader for Android, Linux, and Windows exports functions for all
core Vulkan API commands, and for a set of WSI extension commands that
are applicable to those operating systems (see Vulkan loader documentation for
the relevant platform/OS for details). The
WSI functions are considered special, because they are required for many
applications.
====
[[extensions-reserving-bitmask-values]]
=== Reserving Bitmask Values
Enumerants which define bitmask values are a special case, since there are
only a small number of unused bits available for extensions. For core Vulkan
API and KHR extension bitmask types, reservations must: be approved by a
vote of the Vulkan Working Group. For EXT and vendor extension bitmask
types, reservations must: be approved by the listed contact of the
extension. Bits are not reserved, and mustnot: be used in a published
implementation or specification until the reservation is merged into
<<extensions-api-registry,+vk.xml+>> by the registry maintainer.
[NOTE]
.Note
====
In reality the approving authority for EXT and vendor extension bitmask
additions will probably be the owner of the github branch containing the
specification of that extension; however, until the github process is fully
defined and locked down, it is safest to refer to the listed contact.
====
[[extensions-interactions]]
== Extension Interactions
Extensions modifying the behavior of existing commands should: provide
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. 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
with a pname:sType defined by the extension, but this approach is
discouraged and shouldnot: be used.
When chaining multiple extensions to a structure, the implementation will
process the chain starting with the base parameter and proceeding through
each successive chained structure in turn. Extensions should: be defined to
accept any order of chaining, and must: define their interactions with other
extensions such that the results are deterministic. If an extension needs a
specific ordering of its extension structure with respect to other
extensions in a chain to provide deterministic results, it must: define the
required ordering and expected behavior as part of its specification.
Most of the content previously in this appendix does not specify *use* of
specific Vulkan extensions and layers, but rather specifies the processes by
which extensions and layers are created. As of version 1.0.21 of the Vulkan
Specification, this content has been migrated to the <<vulkan-styleguide,
Vulkan Documentation and Extensions>>
document. Authors creating extensions and layers must follow the mandatory
procedures in that document.

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

@ -174,7 +174,7 @@ required: to be at least as follows, unless decorated with RelaxedPrecision:
| conversions between types | Correctly rounded.
|====
Precision of GLSL.std.450 Instructions
.Precision of GLSL.std.450 Instructions
[options="header"]
|====
|Instruction | Precision

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

@ -418,28 +418,86 @@ include::../protos/vkCmdBlitImage.txt[]
blits require scaling.
fname:vkCmdBlitImage mustnot: be used for multisampled source or destination
images. Use flink:vkCmdResolveImage for this purpose.
images.
Use flink:vkCmdResolveImage for this purpose.
If sizes of source and destination extents do not match, scaling is
performed by applying the filtering mode specified by pname:filter
parameter. ename:VK_FILTER_LINEAR uses bilinear interpolation, and
ename:VK_FILTER_NEAREST uses point sampling. When using
ename:VK_FILTER_LINEAR, magnifying blits may: generate texel coordinates
outside of the source region. If those coordinates are outside the bounds of
the image level, the coordinates are clamped as in
ename:VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_EDGE address mode. However, if the
coordinates are outside the source region but inside the image level, the
implementation may: clamp coordinates to the source region.
As the sizes of the source and destination extents can: differ in any
dimension, texels in the source extent are scaled and filtered to the
destination extent.
Scaling occurs via the following operations:
If source and destination extents are identical, no filtering is performed.
Pixels in the axis-aligned region bounded by srcOffsets[0] and srcOffsets[1]
will be copied to the destination region bound by dstOffsets[0] and
dstOffsets[1]. In the case where dstOffsets[0].x > dstOffsets[1].x the
copied pixels are reversed in that direction. Likewise for y and z.
* For each destination texel, the integer coordinate of that texel is
converted to an unnormalized texture coordinate, using the effective
inverse of the equations described in
<<textures-unnormalized-to-integer, unnormalized to integer
conversion>>:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
u_{base} & = i + \frac{1}{2}\\
v_{base} & = j + \frac{1}{2}\\
w_{base} & = k + \frac{1}{2}\\
\end{align*}
++++++++++++++++++++++++
* These base coordinates are then offset by the first destination offset:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
u_{offset} & = u_{base} - x_{dst_0}\\
v_{offset} & = v_{base} - y_{dst_0}\\
w_{offset} & = w_{base} - z_{dst_0}\\
a_{offset} & = a - baseArrayCount_{dst}
\end{align*}
++++++++++++++++++++++++
* The scale is determined from the source and destination regions, and
applied to the offset coordinates:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
scale_u & = \frac{x_{src_1} - x_{src_0}}{x_{dst_1} - x_{dst_0}}\\
scale_v & = \frac{y_{src_1} - y_{src_0}}{y_{dst_1} - y_{dst_0}}\\
scale_w & = \frac{z_{src_1} - z_{src_0}}{z_{dst_1} - z_{dst_0}}\\
\\
u_{scaled} & = u_{offset} * scale_u\\
v_{scaled} & = v_{offset} * scale_v\\
w_{scaled} & = w_{offset} * scale_w
\end{align*}
++++++++++++++++++++++++
* Finally the source offset is added to the scaled coordinates, to
determine the final unnormalized coordinates used to sample from
pname:srcImage:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
u & = u_{scaled} + x_{src_0}\\
v & = v_{scaled} + y_{src_0}\\
w & = w_{scaled} + z_{src_0}\\
q & = mipLevel\\
a & = a_{offset} + baseArrayCount_{src}
\end{align*}
++++++++++++++++++++++++
These coordinates are used to sample from the source image, as described in
<<textures, Image Operations chapter>>, with the filter mode equal to that
of pname:filter, a mipmap mode of ename:VK_SAMPLER_MIPMAP_MODE_NEAREST and
an address mode of ename:VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_EDGE.
Implementations must: clamp at the edge of the source image, and may:
additionally clamp to the edge of the source region.
[NOTE]
.Note
====
Due to allowable rounding errors in the generation of the source texture
coordinates, it is not always possible to guarantee exactly which source
texels will be sampled for a given blit.
As rounding errors are implementation dependent, the exact results of a
blitting operation are also implementation dependent.
====
Blits are done layer by layer starting with the pname:baseArrayLayer member
of pname:srcSubresource for the source and pname:dstSubresource for the
destination. pname:layerCount layers are blitted to the destination image.
destination.
pname:layerCount layers are blitted to the destination image.
3D textures are blitted slice by slice. Slices in the source region bounded
by pname:srcOffsets[0].z and pname:srcOffsets[1].z are copied to slices in

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

@ -121,8 +121,9 @@ constraints and guidelines:
pname:vendorID as described above for PCI-based
implementations. Implementations that do not return a PCI vendor ID in
pname:vendorID must: return a valid Khronos vendor ID, obtained as
defined in the <<extensions-vendor-id,Registering a Vendor ID with
Khronos>> section. Khronos vendor IDs are allocated starting at 0x10000,
described in the <<vulkan-styleguide,Vulkan Documentation and Extensions>>
document in the section ``Registering a Vendor ID
with Khronos''. Khronos vendor IDs are allocated starting at 0x10000,
to distinguish them from the PCI vendor ID namespace.
* The vendor of the physical device is responsible for selecting
pname:deviceID. The value selected should: uniquely

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

@ -1088,16 +1088,16 @@ range.
or equal to this limit.
* [[features-limits-framebufferColorSampleCounts]]
pname:framebufferColorSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported color sample
counts for a framebuffer color attachment.
elink:VkSampleCountFlagBits bits indicating the color sample counts that
are supported for all framebuffer color attachments.
* [[features-limits-framebufferDepthSampleCounts]]
pname:framebufferDepthSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported depth sample
counts for a framebuffer depth/stencil attachment, when the format
counts for all framebuffer depth/stencil attachments, when the format
includes a depth component.
* pname:framebufferStencilSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported stencil sample
counts for a framebuffer depth/stencil attachment, when the format
counts for all framebuffer depth/stencil attachments, when the format
includes a stencil component.
* pname:framebufferNoAttachmentsSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported sample counts
@ -1110,23 +1110,30 @@ range.
* [[features-limits-sampledImageColorSampleCounts]]
pname:sampledImageColorSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images with a non-integer color format.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a non-integer color
format.
* [[features-limits-sampledImageIntegerSampleCounts]]
pname:sampledImageIntegerSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images with a integer color format.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and an integer color
format.
* [[features-limits-sampledImageDepthSampleCounts]]
pname:sampledImageDepthSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images with a depth format.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a depth format.
* [[features-limits-sampledImageStencilSampleCounts]]
pname:sampledImageStencilSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample supported for all
images with a stencil format.
elink:VkSampleCountFlagBits bits indicating the sample supported
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a stencil format.
* [[features-limits-storageImageSampleCounts]]
pname:storageImageSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images used for storage operations.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, and
pname:usage containing ename:VK_IMAGE_USAGE_STORAGE_BIT.
* [[features-limits-maxSampleMaskWords]] pname:maxSampleMaskWords is the
maximum number of array elements of a variable decorated with the
code:SampleMask built-in decoration.
@ -1228,10 +1235,8 @@ include::../enums/VkSampleCountFlagBits.txt[]
The sample count limits defined above represent the minimum
supported sample counts for each image type. Individual images may: support
additional sample counts, which are queried using
flink:vkGetPhysicalDeviceImageFormatProperties. The sample
count limits for images only apply to images created with the pname:tiling
set to ename:VK_IMAGE_TILING_OPTIMAL. For ename:VK_IMAGE_TILING_LINEAR
images the only supported sample count is ename:VK_SAMPLE_COUNT_1_BIT.
flink:vkGetPhysicalDeviceImageFormatProperties as described
in <<features-supported-sample-counts, Supported Sample Counts>>.
include::../validity/structs/VkPhysicalDeviceLimits.txt[]
@ -1342,7 +1347,7 @@ the same whether or not the feature is enabled.
|VkSampleCountFlags |sampledImageStencilSampleCounts |-
|VkSampleCountFlags |storageImageSampleCounts |shaderStorageImageMultisample
|uint32_t |maxSampleMaskWords |-
|vkBool32 |timestampComputeAndGraphics |-
|VkBool32 |timestampComputeAndGraphics |-
|float |timestampPeriod |-
|uint32_t |maxClipDistances |shaderClipDistance
|uint32_t |maxCullDistances |shaderCullDistance
@ -3642,6 +3647,7 @@ one of: this table, <<features-formats-mandatory-features-bcn>>, or
<<features-formats-mandatory-features-etc>>.
|=========================================
== Additional Image Capabilities
In addition to the minimum capabilities described in the previous sections
@ -3720,20 +3726,8 @@ include::../structs/VkImageFormatProperties.txt[]
is ename:VK_IMAGE_TILING_LINEAR or if pname:type is
ename:VK_IMAGE_TYPE_3D.
* pname:sampleCounts is a bitmask of elink:VkSampleCountFlagBits
specifying all the supported sample counts for this image. When
pname:tiling is ename:VK_IMAGE_TILING_LINEAR the pname:sampleCounts will
be set to ename:VK_SAMPLE_COUNT_1_BIT. Otherwise the bits set here are a
superset of the corresponding limits for the image type in the
sname:VkPhysicalDeviceLimits struct. For non-integer color images this
is pname:sampledImageColorSampleCounts, for integer format color images
this is pname:sampledImageIntegerSampleCounts, for depth/stencil images
with a depth component this is pname:sampledImageDepthSampleCounts, for
depth/stencil with a stencil component images this is
pname:sampledImageStencilSampleCounts, and if pname:usage has
ename:VK_IMAGE_USAGE_STORAGE_BIT set this is
pname:storageImageSampleCounts. For depth/stencil images with both a
depth and stencil component, both the depth and stencil limits must: be
satisfied.
specifying all the supported sample counts for this image as described
<<features-supported-sample-counts, below>>.
* pname:maxResourceSize is an upper bound on the total image size in bytes,
inclusive of all image subresources. Implementations may: have an
address space limit on total size of a resource, which is advertised by
@ -3758,6 +3752,49 @@ sname:VkImageFormatProperties will be filled with zero.
include::../validity/structs/VkImageFormatProperties.txt[]
[[features-supported-sample-counts]]
=== Supported Sample Counts
fname:vkGetPhysicalDeviceImageFormatProperties returns a bitmask of
elink:VkSampleCountFlagBits in pname:sampleCounts specifying the supported
sample counts for the image parameters.
pname:sampleCounts will be set to ename:VK_SAMPLE_COUNT_1_BIT if at least
one of the following conditions is true:
* pname:tiling is ename:VK_IMAGE_TILING_LINEAR
* pname:type is not ename:VK_IMAGE_TYPE_2D
* The ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT flag in
sname:VkFormatProperties::pname:optimalTilingFeatures returned by
flink:vkGetPhysicalDeviceFormatProperties is not set
Otherwise, the bits set in pname:sampleCounts will be the sample counts
supported for the specified values of pname:usage and pname:format. For
each bit set in pname:usage, the supported sample counts relate to the
limits in sname:VkPhysicalDeviceLimits as follows:
* If pname:usage includes ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
a superset of sname:VkPhysicalDeviceLimits::pname:framebufferColorSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT,
and pname:format includes a depth aspect, a superset of
sname:VkPhysicalDeviceLimits::pname:framebufferDepthSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT,
and pname:format includes a stencil aspect, a superset of
sname:VkPhysicalDeviceLimits::pname:framebufferStencilSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format
includes a color aspect, a superset of
sname:VkPhysicalDeviceLimits::pname:sampledImageColorSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format
includes a depth aspect, a superset of
sname:VkPhysicalDeviceLimits::pname:sampledImageDepthSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format
is an integer format, a superset of
sname:VkPhysicalDeviceLimits::pname:sampledImageIntegerSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_STORAGE_BIT, a superset of
sname:VkPhysicalDeviceLimits::pname:storageImageSampleCounts
If multiple bits are set in pname:usage, pname:sampleCounts will be the
intersection of the per-usage values described above.
[[features-extentperimagetype]]
=== Allowed Extent Values Based On Image Type

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

@ -705,8 +705,9 @@ an appendix.
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, containing ptext:sType and
ptext:pNext members as described in the <<extensions-interactions,Extension
Interactions>> section. If that extension is supported by the
ptext:pNext members as described in the <<vulkan-styleguide,Vulkan
Documentation and Extensions>> document in the section ``Extension
Interactions''. 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

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

@ -248,10 +248,8 @@ causing two variables to have the same location number. _Component aliasing_
is assigning the same (or overlapping) component number for
two location aliases. Location aliasing is allowed only if it does
not cause component aliasing. Further, when location aliasing, the
aliases sharing the location must: have the same underlying numerical
type (floating-point or integer). Failure to meet these requirements
will result in an invalid pipeline.
aliases sharing the location must: all have the same SPIR-V floating-point
component type or all have the same width integer-type components.
[[fxvertex-input]]

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

@ -35,6 +35,10 @@ operands to the code:OpEntryPoint instruction and are declared with the
code:Input or code:Output storage classes, respectively, in the SPIR-V
module.
code:Output variables of a shader stage have undefined values until the shader
writes to them or uses the code:Initializer operand when declaring the
variable.
[[interfaces-iointerfaces-builtin]]
=== Built-in Interface Block

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

@ -194,3 +194,8 @@ February 10, 2016.
SPIR-V Specification, Version 1.00_,
https://www.khronos.org/registry/spir-v/,
February 10, 2016.
[[vulkan-styleguide]]:: J. Leech and T. Hector,
_Vulkan Documentation and Extensions: Procedures and Conventions_,
https://www.khronos.org/registry/vulkan/,
July 11, 2016

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

@ -56,12 +56,9 @@ SPIR-V Image Instructions include the following functionality:
Images are addressed by _texel coordinates_. There are three _texel
coordinate systems_:
* normalized texel coordinates (coordinates ranging from 0 to 1 span the
image),
* unnormalized texel coordinates (floating point coordinates ranging from
0 to width/height/depth span the image), and
* integer texel coordinates (integer coordinates ranging from 0 to
width-1/height-1/depth-1 address the texels within the image).
* normalized texel coordinates latexmath:[$[0.0,1.0\]$]
* unnormalized texel coordinates latexmath:[$[0.0, width/height/depth)$]
* integer texel coordinates latexmath:[$[0, width/height/depth)$]
SPIR-V code:OpImageFetch, code:OpImageSparseFetch, code:OpImageRead,
code:OpImageSparseRead, and code:OpImageWrite instructions use integer texel
@ -1477,6 +1474,7 @@ constant offsets latexmath:[$(\Delta_{i},\Delta_{j},\Delta_{k})$] are added
to latexmath:[$(i,j,k)$] components of the integer texel coordinates.
[[textures-sample-operations]]
== Image Sample Operations

2
doc/specs/vulkan/config/manpages.conf
View File

@ -54,7 +54,7 @@ max-width="1024px"
(?su)(?P<name>ptext):(?P<target>[\w*]+(\.[\w*]+)*)=param
(?su)(?P<name>tlink):(?P<target>\w+)=link
(?su)(?P<name>tname):(?P<target>\w+)=strong
(?su)(?P<name>basetype):(?P<target>\w+)=code
(?su)(?P<name>basetype):(?P<target>\w+)=link
(?su)(?P<name>code):(?P<target>\w+)=strong
[normative-inlinemacro]

0
doc/specs/vulkan/man/vkman.css → doc/specs/vulkan/config/vkman.css
View File

4
doc/specs/vulkan/copyright-ccby.txt Normal file
View File

@ -0,0 +1,4 @@
Copyright (c) 2014-2016 Khronos Group. This work is licensed under a
http://creativecommons.org/licenses/by/4.0/[Creative Commons
Attribution 4.0 International License].

2
doc/specs/vulkan/defines/VK_HEADER_VERSION.txt
View File

@ -8,6 +8,6 @@ ifdef::doctype-manpage[]
endif::doctype-manpage[]
------------------------------------------------------------------------------
// Version of this file
#define VK_HEADER_VERSION 20
#define VK_HEADER_VERSION 21
------------------------------------------------------------------------------

30
doc/specs/vulkan/genRef.py
View File

@ -46,7 +46,7 @@ def printCopyrightBlock(fp, comment=True):
# (protos, structs, enums, etc.)
def macroPrefix(name):
if (name in basetypes.keys()):
return 'basetypes:' + name
return 'basetype:' + name
elif (name in defines.keys()):
return 'slink:' + name
elif (name in enums.keys()):
@ -134,31 +134,35 @@ def refPageHead(pageName, pageDesc, specText, fieldName, fieldText, descText, fp
sep='\n', file=fp)
def refPageTail(pageName, seeAlso, fp, auto = False):
# This is difficult to get working properly in asciidoc
# specURL = 'link:{vkspecpath}/vkspec.html'
# This needs to have the current repository branch path installed in
# place of '1.0'
specURL = 'https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html'
if (seeAlso == None):
seeAlso = 'No cross-references are available\n'
notes = [
'For more information, see the Vulkan Specification at URL',
'',
specURL + '#' + pageName,
'',
]
if (auto):
notes = [
'For more information, see the Vulkan Specification at URL',
'',
specURL + '#' + pageName,
'',
notes.extend([
'This page is a generated document.',
'Fixes and changes should be made to the generator scripts,'
'not directly.',
]
])
else:
notes = [
'For more information, see the Vulkan Specification at URL',
'',
specURL + '#' + pageName,
'',
notes.extend([
'This page is extracted from the Vulkan Specification.',
'Fixes and changes should be made to the Specification,'
'not directly.',
]
])
print('See Also',
'--------',

16
doc/specs/vulkan/genRelease
View File

@ -3,15 +3,15 @@
from genspec import *
buildBranch('1.0',
xmlTargets = 'clobber full_install pdf_install',
specTargets = 'xhtml styleguide manhtml manhtmlpages pdf',
repoDir = '/home/tree/git/Vulkan-Docs',
outDir = '/home/tree/git/Vulkan-Web-Registry/specs')
xmlTargets = 'clobber full_install pdf_install',
specTargets = 'xhtml styleguide manhtml manhtmlpages pdf manpdf',
repoDir = '/home/tree/git/vulkan',
outDir = '/home/tree/git/vulkan/out')
buildBranch('1.0-wsi_extensions',
xmlTargets = 'clobber full_install',
specTargets = 'xhtml manhtml',
repoDir = '/home/tree/git/Vulkan-Docs',
outDir = '/home/tree/git/Vulkan-Web-Registry/specs')
xmlTargets = 'clobber full_install',
specTargets = 'xhtml manhtml',
repoDir = '/home/tree/git/vulkan',
outDir = '/home/tree/git/vulkan/out')
print('echo Info: post-generation cleanup')
print('git checkout ' + coreBranch)

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

@ -14,7 +14,7 @@ C Specification
// refBegin VK_API_VERSION - Deprecated version number macro
dname:VK_API_VERSION is deprecated and should: no longer be used.
dname:VK_API_VERSION is now commented out of +vulkan.h+ and cannot: be used.
include::../defines/VK_API_VERSION.txt[]

7
doc/specs/vulkan/man/VK_API_VERSION_1_0.txt
View File

@ -15,10 +15,9 @@ C Specification
// refBegin VK_API_VERSION_1_0 - Return API version number for Vulkan 1.0
dname:VK_API_VERSION_1_0 returns the API version number for Vulkan 1.0. The
patch version number in this macro will always be zero. The required patch
version is specified by the application when creating an instance with
flink:vkCreateInstance, and the supported patch version for a physical
device can: be queried with flink:vkGetPhysicalDeviceProperties.
patch version number in this macro will always be zero. The supported patch
version for a physical device can: be queried with
flink:vkGetPhysicalDeviceProperties.
include::../defines/VK_API_VERSION_1_0.txt[]

1
doc/specs/vulkan/man/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt
View File

@ -26,7 +26,6 @@ Description
* pname:object is the name of the resulting C type.
Most Vulkan handle types, such as slink:VkBuffer, are non-dispatchable.
Only one such type is listed in the See Also section below.
// refEnd VK_DEFINE_NON_DISPATCHABLE_HANDLE VkBuffer

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

@ -38,7 +38,7 @@ include::../validity/structs/VkBufferCopy.txt[]
See Also
--------
basetypes:VkDeviceSize, flink:vkCmdCopyBuffer
basetype:VkDeviceSize, flink:vkCmdCopyBuffer
Document Notes

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

@ -116,7 +116,7 @@ include::../validity/structs/VkBufferCreateInfo.txt[]
See Also
--------
elink:VkBufferCreateFlags, elink:VkBufferUsageFlags, basetypes:VkDeviceSize, elink:VkSharingMode, elink:VkStructureType, flink:vkCreateBuffer
elink:VkBufferCreateFlags, elink:VkBufferUsageFlags, basetype:VkDeviceSize, elink:VkSharingMode, elink:VkStructureType, flink:vkCreateBuffer
Document Notes

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

@ -87,7 +87,7 @@ include::../validity/structs/VkBufferImageCopy.txt[]
See Also
--------
basetypes:VkDeviceSize, slink:VkExtent3D, slink:VkImageSubresourceLayers, slink:VkOffset3D, flink:vkCmdCopyBufferToImage, flink:vkCmdCopyImageToBuffer
basetype:VkDeviceSize, slink:VkExtent3D, slink:VkImageSubresourceLayers, slink:VkOffset3D, flink:vkCmdCopyBufferToImage, flink:vkCmdCopyImageToBuffer
Document Notes

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

@ -55,7 +55,7 @@ include::../validity/structs/VkBufferMemoryBarrier.txt[]
See Also
--------
elink:VkAccessFlags, slink:VkBuffer, basetypes:VkDeviceSize, elink:VkStructureType, flink:vkCmdPipelineBarrier, flink:vkCmdWaitEvents
elink:VkAccessFlags, slink:VkBuffer, basetype:VkDeviceSize, elink:VkStructureType, flink:vkCmdPipelineBarrier, flink:vkCmdWaitEvents
Document Notes

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

@ -47,7 +47,7 @@ include::../validity/structs/VkBufferViewCreateInfo.txt[]
See Also
--------
slink:VkBuffer, elink:VkBufferViewCreateFlags, basetypes:VkDeviceSize, elink:VkFormat, elink:VkStructureType, flink:vkCreateBufferView
slink:VkBuffer, elink:VkBufferViewCreateFlags, basetype:VkDeviceSize, elink:VkFormat, elink:VkStructureType, flink:vkCreateBufferView
Document Notes

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

@ -77,7 +77,7 @@ include::../validity/structs/VkCommandBufferInheritanceInfo.txt[]
See Also
--------
basetypes:VkBool32, slink:VkCommandBufferBeginInfo, slink:VkFramebuffer, elink:VkQueryControlFlags, elink:VkQueryPipelineStatisticFlags, slink:VkRenderPass, elink:VkStructureType
basetype:VkBool32, slink:VkCommandBufferBeginInfo, slink:VkFramebuffer, elink:VkQueryControlFlags, elink:VkQueryPipelineStatisticFlags, slink:VkRenderPass, elink:VkStructureType
Document Notes

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

@ -45,7 +45,7 @@ include::../validity/structs/VkDescriptorBufferInfo.txt[]
See Also
--------
slink:VkBuffer, basetypes:VkDeviceSize, slink:VkWriteDescriptorSet
slink:VkBuffer, basetype:VkDeviceSize, slink:VkWriteDescriptorSet
Document Notes

18
doc/specs/vulkan/man/VkImageFormatProperties.txt
View File

@ -42,20 +42,8 @@ Members
is ename:VK_IMAGE_TILING_LINEAR or if pname:type is
ename:VK_IMAGE_TYPE_3D.
* pname:sampleCounts is a bitmask of elink:VkSampleCountFlagBits
specifying all the supported sample counts for this image. When
pname:tiling is ename:VK_IMAGE_TILING_LINEAR the pname:sampleCounts will
be set to ename:VK_SAMPLE_COUNT_1_BIT. Otherwise the bits set here are a
superset of the corresponding limits for the image type in the
sname:VkPhysicalDeviceLimits struct. For non-integer color images this
is pname:sampledImageColorSampleCounts, for integer format color images
this is pname:sampledImageIntegerSampleCounts, for depth/stencil images
with a depth component this is pname:sampledImageDepthSampleCounts, for
depth/stencil with a stencil component images this is
pname:sampledImageStencilSampleCounts, and if pname:usage has
ename:VK_IMAGE_USAGE_STORAGE_BIT set this is
pname:storageImageSampleCounts. For depth/stencil images with both a
depth and stencil component, both the depth and stencil limits must: be
satisfied.
specifying all the supported sample counts for this image as described
<<features-supported-sample-counts, below>>.
* pname:maxResourceSize is an upper bound on the total image size in bytes,
inclusive of all image subresources. Implementations may: have an
address space limit on total size of a resource, which is advertised by
@ -87,7 +75,7 @@ include::../validity/structs/VkImageFormatProperties.txt[]
See Also
--------
basetypes:VkDeviceSize, slink:VkExtent3D, elink:VkSampleCountFlags, flink:vkGetPhysicalDeviceImageFormatProperties
basetype:VkDeviceSize, slink:VkExtent3D, elink:VkSampleCountFlags, flink:vkGetPhysicalDeviceImageFormatProperties
Document Notes

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

@ -41,7 +41,7 @@ include::../validity/structs/VkMappedMemoryRange.txt[]
See Also
--------
slink:VkDeviceMemory, basetypes:VkDeviceSize, elink:VkStructureType, flink:vkFlushMappedMemoryRanges, flink:vkInvalidateMappedMemoryRanges
slink:VkDeviceMemory, basetype:VkDeviceSize, elink:VkStructureType, flink:vkFlushMappedMemoryRanges, flink:vkInvalidateMappedMemoryRanges
Document Notes

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

@ -39,7 +39,7 @@ include::../validity/structs/VkMemoryAllocateInfo.txt[]
See Also
--------
basetypes:VkDeviceSize, elink:VkStructureType, flink:vkAllocateMemory
basetype:VkDeviceSize, elink:VkStructureType, flink:vkAllocateMemory
Document Notes

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

@ -45,7 +45,7 @@ include::../validity/structs/VkMemoryHeap.txt[]
See Also
--------
basetypes:VkDeviceSize, elink:VkMemoryHeapFlags, slink:VkPhysicalDeviceMemoryProperties
basetype:VkDeviceSize, elink:VkMemoryHeapFlags, slink:VkPhysicalDeviceMemoryProperties
Document Notes

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

@ -41,7 +41,7 @@ include::../validity/structs/VkMemoryRequirements.txt[]
See Also
--------
basetypes:VkDeviceSize, flink:vkGetBufferMemoryRequirements, flink:vkGetImageMemoryRequirements
basetype:VkDeviceSize, flink:vkGetBufferMemoryRequirements, flink:vkGetImageMemoryRequirements
Document Notes

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

@ -513,7 +513,7 @@ include::../validity/structs/VkPhysicalDeviceFeatures.txt[]
See Also
--------
basetypes:VkBool32, slink:VkDeviceCreateInfo, flink:vkGetPhysicalDeviceFeatures
basetype:VkBool32, slink:VkDeviceCreateInfo, flink:vkGetPhysicalDeviceFeatures
Document Notes

35
doc/specs/vulkan/man/VkPhysicalDeviceLimits.txt
View File

@ -515,16 +515,16 @@ range.
or equal to this limit.
* [[features-limits-framebufferColorSampleCounts]]
pname:framebufferColorSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported color sample
counts for a framebuffer color attachment.
elink:VkSampleCountFlagBits bits indicating the color sample counts that
are supported for all framebuffer color attachments.
* [[features-limits-framebufferDepthSampleCounts]]
pname:framebufferDepthSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported depth sample
counts for a framebuffer depth/stencil attachment, when the format
counts for all framebuffer depth/stencil attachments, when the format
includes a depth component.
* pname:framebufferStencilSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported stencil sample
counts for a framebuffer depth/stencil attachment, when the format
counts for all framebuffer depth/stencil attachments, when the format
includes a stencil component.
* pname:framebufferNoAttachmentsSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the supported sample counts
@ -537,23 +537,30 @@ range.
* [[features-limits-sampledImageColorSampleCounts]]
pname:sampledImageColorSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images with a non-integer color format.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a non-integer color
format.
* [[features-limits-sampledImageIntegerSampleCounts]]
pname:sampledImageIntegerSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images with a integer color format.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and an integer color
format.
* [[features-limits-sampledImageDepthSampleCounts]]
pname:sampledImageDepthSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images with a depth format.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a depth format.
* [[features-limits-sampledImageStencilSampleCounts]]
pname:sampledImageStencilSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample supported for all
images with a stencil format.
elink:VkSampleCountFlagBits bits indicating the sample supported
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a stencil format.
* [[features-limits-storageImageSampleCounts]]
pname:storageImageSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits bits indicating the sample counts supported
for all images used for storage operations.
for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, and
pname:usage containing ename:VK_IMAGE_USAGE_STORAGE_BIT.
* [[features-limits-maxSampleMaskWords]] pname:maxSampleMaskWords is the
maximum number of array elements of a variable decorated with the
code:SampleMask built-in decoration.
@ -659,10 +666,8 @@ include::../enums/VkSampleCountFlagBits.txt[]
The sample count limits defined above represent the minimum
supported sample counts for each image type. Individual images may: support
additional sample counts, which are queried using
flink:vkGetPhysicalDeviceImageFormatProperties. The sample
count limits for images only apply to images created with the pname:tiling
set to ename:VK_IMAGE_TILING_OPTIMAL. For ename:VK_IMAGE_TILING_LINEAR
images the only supported sample count is ename:VK_SAMPLE_COUNT_1_BIT.
flink:vkGetPhysicalDeviceImageFormatProperties as described
in <<features-supported-sample-counts, Supported Sample Counts>>.
include::../validity/structs/VkPhysicalDeviceLimits.txt[]
@ -670,7 +675,7 @@ include::../validity/structs/VkPhysicalDeviceLimits.txt[]
See Also
--------
basetypes:VkBool32, basetypes:VkDeviceSize, slink:VkPhysicalDeviceProperties, elink:VkSampleCountFlags
basetype:VkBool32, basetype:VkDeviceSize, slink:VkPhysicalDeviceProperties, elink:VkSampleCountFlags
Document Notes

5
doc/specs/vulkan/man/VkPhysicalDeviceProperties.txt
View File

@ -73,8 +73,9 @@ constraints and guidelines:
pname:vendorID as described above for PCI-based
implementations. Implementations that do not return a PCI vendor ID in
pname:vendorID must: return a valid Khronos vendor ID, obtained as
defined in the <<extensions-vendor-id,Registering a Vendor ID with
Khronos>> section. Khronos vendor IDs are allocated starting at 0x10000,
described in the <<vulkan-styleguide,Vulkan Documentation and Extensions>>
document in the section ``Registering a Vendor ID
with Khronos''. Khronos vendor IDs are allocated starting at 0x10000,
to distinguish them from the PCI vendor ID namespace.
* The vendor of the physical device is responsible for selecting
pname:deviceID. The value selected should: uniquely

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

@ -76,7 +76,7 @@ include::../validity/structs/VkPhysicalDeviceSparseProperties.txt[]
See Also
--------
basetypes:VkBool32, slink:VkPhysicalDeviceProperties
basetype:VkBool32, slink:VkPhysicalDeviceProperties
Document Notes

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

@ -51,7 +51,7 @@ include::../validity/structs/VkPipelineColorBlendAttachmentState.txt[]
See Also
--------
elink:VkBlendFactor, elink:VkBlendOp, basetypes:VkBool32, elink:VkColorComponentFlags, slink:VkPipelineColorBlendStateCreateInfo
elink:VkBlendFactor, elink:VkBlendOp, basetype:VkBool32, elink:VkColorComponentFlags, slink:VkPipelineColorBlendStateCreateInfo
Document Notes

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

@ -55,7 +55,7 @@ include::../validity/structs/VkPipelineColorBlendStateCreateInfo.txt[]
See Also
--------
basetypes:VkBool32, slink:VkGraphicsPipelineCreateInfo, elink:VkLogicOp, slink:VkPipelineColorBlendAttachmentState, elink:VkPipelineColorBlendStateCreateFlags, elink:VkStructureType
basetype:VkBool32, slink:VkGraphicsPipelineCreateInfo, elink:VkLogicOp, slink:VkPipelineColorBlendAttachmentState, elink:VkPipelineColorBlendStateCreateFlags, elink:VkStructureType
Document Notes

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

@ -50,7 +50,7 @@ include::../validity/structs/VkPipelineDepthStencilStateCreateInfo.txt[]
See Also
--------
basetypes:VkBool32, elink:VkCompareOp, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineDepthStencilStateCreateFlags, slink:VkStencilOpState, elink:VkStructureType
basetype:VkBool32, elink:VkCompareOp, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineDepthStencilStateCreateFlags, slink:VkStencilOpState, elink:VkStructureType
Document Notes

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

@ -57,7 +57,7 @@ include::../validity/structs/VkPipelineInputAssemblyStateCreateInfo.txt[]
See Also
--------
basetypes:VkBool32, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineInputAssemblyStateCreateFlags, elink:VkPrimitiveTopology, elink:VkStructureType
basetype:VkBool32, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineInputAssemblyStateCreateFlags, elink:VkPrimitiveTopology, elink:VkStructureType
Document Notes

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

@ -53,7 +53,7 @@ include::../validity/structs/VkPipelineMultisampleStateCreateInfo.txt[]
See Also
--------
basetypes:VkBool32, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineMultisampleStateCreateFlags, elink:VkSampleCountFlagBits, basetypes:VkSampleMask, elink:VkStructureType
basetype:VkBool32, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineMultisampleStateCreateFlags, elink:VkSampleCountFlagBits, basetype:VkSampleMask, elink:VkStructureType
Document Notes

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

@ -55,7 +55,7 @@ include::../validity/structs/VkPipelineRasterizationStateCreateInfo.txt[]
See Also
--------
basetypes:VkBool32, elink:VkCullModeFlags, elink:VkFrontFace, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineRasterizationStateCreateFlags, elink:VkPolygonMode, elink:VkStructureType
basetype:VkBool32, elink:VkCullModeFlags, elink:VkFrontFace, slink:VkGraphicsPipelineCreateInfo, elink:VkPipelineRasterizationStateCreateFlags, elink:VkPolygonMode, elink:VkStructureType
Document Notes

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

@ -177,7 +177,7 @@ include::../validity/structs/VkSamplerCreateInfo.txt[]
See Also
--------
basetypes:VkBool32, elink:VkBorderColor, elink:VkCompareOp, elink:VkFilter, elink:VkSamplerAddressMode, elink:VkSamplerCreateFlags, elink:VkSamplerMipmapMode, elink:VkStructureType, flink:vkCreateSampler
basetype:VkBool32, elink:VkBorderColor, elink:VkCompareOp, elink:VkFilter, elink:VkSamplerAddressMode, elink:VkSamplerCreateFlags, elink:VkSamplerMipmapMode, elink:VkStructureType, flink:vkCreateSampler
Document Notes

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

@ -48,7 +48,7 @@ include::../validity/structs/VkSparseImageMemoryBind.txt[]
See Also
--------
slink:VkDeviceMemory, basetypes:VkDeviceSize, slink:VkExtent3D, slink:VkImageSubresource, slink:VkOffset3D, slink:VkSparseImageMemoryBindInfo, elink:VkSparseMemoryBindFlags
slink:VkDeviceMemory, basetype:VkDeviceSize, slink:VkExtent3D, slink:VkImageSubresource, slink:VkOffset3D, slink:VkSparseImageMemoryBindInfo, elink:VkSparseMemoryBindFlags
Document Notes

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

@ -70,7 +70,7 @@ include::../validity/structs/VkSparseImageMemoryRequirements.txt[]
See Also
--------
basetypes:VkDeviceSize, slink:VkSparseImageFormatProperties, flink:vkGetImageSparseMemoryRequirements
basetype:VkDeviceSize, slink:VkSparseImageFormatProperties, flink:vkGetImageSparseMemoryRequirements
Document Notes

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

@ -82,7 +82,7 @@ include::../validity/structs/VkSparseMemoryBind.txt[]
See Also
--------
slink:VkDeviceMemory, basetypes:VkDeviceSize, slink:VkSparseBufferMemoryBindInfo, slink:VkSparseImageOpaqueMemoryBindInfo, elink:VkSparseMemoryBindFlags
slink:VkDeviceMemory, basetype:VkDeviceSize, slink:VkSparseBufferMemoryBindInfo, slink:VkSparseImageOpaqueMemoryBindInfo, elink:VkSparseMemoryBindFlags
Document Notes

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

@ -86,7 +86,7 @@ include::../validity/structs/VkSubresourceLayout.txt[]
See Also
--------
basetypes:VkDeviceSize, flink:vkGetImageSubresourceLayout
basetype:VkDeviceSize, flink:vkGetImageSubresourceLayout
Document Notes

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

@ -41,7 +41,7 @@ include::../validity/protos/vkBindBufferMemory.txt[]
See Also
--------
slink:VkBuffer, slink:VkDevice, slink:VkDeviceMemory, basetypes:VkDeviceSize
slink:VkBuffer, slink:VkDevice, slink:VkDeviceMemory, basetype:VkDeviceSize
Document Notes

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

@ -41,7 +41,7 @@ include::../validity/protos/vkBindImageMemory.txt[]
See Also
--------
slink:VkDevice, slink:VkDeviceMemory, basetypes:VkDeviceSize, slink:VkImage
slink:VkDevice, slink:VkDeviceMemory, basetype:VkDeviceSize, slink:VkImage
Document Notes

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

@ -45,7 +45,7 @@ include::../validity/protos/vkCmdBindIndexBuffer.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize, elink:VkIndexType
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize, elink:VkIndexType
Document Notes

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

@ -51,7 +51,7 @@ include::../validity/protos/vkCmdBindVertexBuffers.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize
Document Notes

92
doc/specs/vulkan/man/vkCmdBlitImage.txt
View File

@ -42,28 +42,86 @@ Description
-----------
fname:vkCmdBlitImage mustnot: be used for multisampled source or destination
images. Use flink:vkCmdResolveImage for this purpose.
images.
Use flink:vkCmdResolveImage for this purpose.
If sizes of source and destination extents do not match, scaling is
performed by applying the filtering mode specified by pname:filter
parameter. ename:VK_FILTER_LINEAR uses bilinear interpolation, and
ename:VK_FILTER_NEAREST uses point sampling. When using
ename:VK_FILTER_LINEAR, magnifying blits may: generate texel coordinates
outside of the source region. If those coordinates are outside the bounds of
the image level, the coordinates are clamped as in
ename:VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_EDGE address mode. However, if the
coordinates are outside the source region but inside the image level, the
implementation may: clamp coordinates to the source region.
As the sizes of the source and destination extents can: differ in any
dimension, texels in the source extent are scaled and filtered to the
destination extent.
Scaling occurs via the following operations:
If source and destination extents are identical, no filtering is performed.
Pixels in the axis-aligned region bounded by srcOffsets[0] and srcOffsets[1]
will be copied to the destination region bound by dstOffsets[0] and
dstOffsets[1]. In the case where dstOffsets[0].x > dstOffsets[1].x the
copied pixels are reversed in that direction. Likewise for y and z.
* For each destination texel, the integer coordinate of that texel is
converted to an unnormalized texture coordinate, using the effective
inverse of the equations described in
<<textures-unnormalized-to-integer, unnormalized to integer
conversion>>:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
u_{base} & = i + \frac{1}{2}\\
v_{base} & = j + \frac{1}{2}\\
w_{base} & = k + \frac{1}{2}\\
\end{align*}
++++++++++++++++++++++++
* These base coordinates are then offset by the first destination offset:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
u_{offset} & = u_{base} - x_{dst_0}\\
v_{offset} & = v_{base} - y_{dst_0}\\
w_{offset} & = w_{base} - z_{dst_0}\\
a_{offset} & = a - baseArrayCount_{dst}
\end{align*}
++++++++++++++++++++++++
* The scale is determined from the source and destination regions, and
applied to the offset coordinates:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
scale_u & = \frac{x_{src_1} - x_{src_0}}{x_{dst_1} - x_{dst_0}}\\
scale_v & = \frac{y_{src_1} - y_{src_0}}{y_{dst_1} - y_{dst_0}}\\
scale_w & = \frac{z_{src_1} - z_{src_0}}{z_{dst_1} - z_{dst_0}}\\
\\
u_{scaled} & = u_{offset} * scale_u\\
v_{scaled} & = v_{offset} * scale_v\\
w_{scaled} & = w_{offset} * scale_w
\end{align*}
++++++++++++++++++++++++
* Finally the source offset is added to the scaled coordinates, to
determine the final unnormalized coordinates used to sample from
pname:srcImage:
[latexmath]
++++++++++++++++++++++++
\begin{align*}
u & = u_{scaled} + x_{src_0}\\
v & = v_{scaled} + y_{src_0}\\
w & = w_{scaled} + z_{src_0}\\
q & = mipLevel\\
a & = a_{offset} + baseArrayCount_{src}
\end{align*}
++++++++++++++++++++++++
These coordinates are used to sample from the source image, as described in
<<textures, Image Operations chapter>>, with the filter mode equal to that
of pname:filter, a mipmap mode of ename:VK_SAMPLER_MIPMAP_MODE_NEAREST and
an address mode of ename:VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_EDGE.
Implementations must: clamp at the edge of the source image, and may:
additionally clamp to the edge of the source region.
[NOTE]
.Note
====
Due to allowable rounding errors in the generation of the source texture
coordinates, it is not always possible to guarantee exactly which source
texels will be sampled for a given blit.
As rounding errors are implementation dependent, the exact results of a
blitting operation are also implementation dependent.
====
Blits are done layer by layer starting with the pname:baseArrayLayer member
of pname:srcSubresource for the source and pname:dstSubresource for the
destination. pname:layerCount layers are blitted to the destination image.
destination.
pname:layerCount layers are blitted to the destination image.
3D textures are blitted slice by slice. Slices in the source region bounded
by pname:srcOffsets[0].z and pname:srcOffsets[1].z are copied to slices in

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

@ -98,7 +98,7 @@ include::../validity/protos/vkCmdCopyQueryPoolResults.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize, slink:VkQueryPool, elink:VkQueryResultFlags
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize, slink:VkQueryPool, elink:VkQueryResultFlags
Document Notes

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

@ -44,7 +44,7 @@ include::../validity/protos/vkCmdDispatchIndirect.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize
Document Notes

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

@ -49,7 +49,7 @@ include::../validity/protos/vkCmdDrawIndexedIndirect.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize
Document Notes

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

@ -49,7 +49,7 @@ include::../validity/protos/vkCmdDrawIndirect.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize
Document Notes

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

@ -51,7 +51,7 @@ include::../validity/protos/vkCmdFillBuffer.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize
Document Notes

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

@ -54,7 +54,7 @@ include::../validity/protos/vkCmdUpdateBuffer.txt[]
See Also
--------
slink:VkBuffer, slink:VkCommandBuffer, basetypes:VkDeviceSize
slink:VkBuffer, slink:VkCommandBuffer, basetype:VkDeviceSize
Document Notes

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

@ -46,7 +46,7 @@ include::../validity/protos/vkGetDeviceMemoryCommitment.txt[]
See Also
--------
slink:VkDevice, slink:VkDeviceMemory, basetypes:VkDeviceSize
slink:VkDevice, slink:VkDeviceMemory, basetype:VkDeviceSize
Document Notes

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

@ -141,7 +141,7 @@ include::../validity/protos/vkGetQueryPoolResults.txt[]
See Also
--------
slink:VkDevice, basetypes:VkDeviceSize, slink:VkQueryPool, elink:VkQueryResultFlags
slink:VkDevice, basetype:VkDeviceSize, slink:VkQueryPool, elink:VkQueryResultFlags
Document Notes

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

@ -78,7 +78,7 @@ include::../validity/protos/vkMapMemory.txt[]
See Also
--------
slink:VkDevice, slink:VkDeviceMemory, basetypes:VkDeviceSize, elink:VkMemoryMapFlags
slink:VkDevice, slink:VkDeviceMemory, basetype:VkDeviceSize, elink:VkMemoryMapFlags
Document Notes

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

@ -80,7 +80,7 @@ include::../validity/protos/vkWaitForFences.txt[]
See Also
--------
basetypes:VkBool32, slink:VkDevice, slink:VkFence
basetype:VkBool32, slink:VkDevice, slink:VkFence
Document Notes

613
doc/specs/vulkan/style/extensions.txt Normal file
View File

@ -0,0 +1,613 @@
// Copyright (c) 2015-2016 The Khronos Group Inc.
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
[[extensions]]
= Layers & Extensions
This chapter describes required and recommended processes for writing formal
extensions and layers for the Vulkan API. It is concerned with processes and
registration, while fine-grained naming conventions are included in the
<<naming,API Naming Conventions chapter>>. Prior to revision 1.0.19 of the
<<Vulkan API Specification>>, most of the content in this chapter existed as
part of Appendix C of that document.
[NOTE]
.Note
====
The mechanism and process of specifying extensions is subject to change, as
we receive feedback from authors and further requirements of documentation
tooling. This document will be updated as changes are made.
====
== Introduction
The Khronos extension registries and extension naming conventions serve
several purposes:
* Avoiding naming collisions between extensions developed by mutually
unaware parties, both in the extension names themselves, as well as
their token, command, and type names.
* Allocating enumerant values for tokens added by extensions
* Creating a defined order between extensions. Extensions with higher
numbers may have dependencies upon extensions with lower numbers, and
must define any relevant interactions with lower-numbered extensions.
* Provides a central repository for documentation and header changes
associated with extensions
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
members are expected to extend a Khronos API using the Layer mechanism.
* Namespaced constants (enumerations) that do not necessarily draw from a
single global set of token values.
== General Rules/Guidelines
Some general rules to simplify the specific rules below:
* Extensions and layers must each have a globally unique name.
* All commands and tokens must have a globally unique name.
* Extensions can expose new commands, types, and/or tokens, but layers
must not.
** However, layers can expose their own extensions, which in turn are
allowed to expose new commands and tokens.
* All extensions must be registered with Khronos.
* Extensions must be strictly additive and backwards-compatible. That is,
extensions must not remove existing functionality, or change existing
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.
[[extensions-naming-conventions]]
== Extension and Layer Naming Conventions
Extensions and layers have formal _names_. These names are used in a variety
of places:
* When specifying extensions and layers to enable in the API.
* As a preprocessor symbol in the +vulkan.h+ header file indicating that
an extension interface is defined at compile time.
* As part of the name of Github repository branches containing
specifications for an extension.
There is a rigid syntax for these names:
* Extensions are named with the syntax: +VK_AUTHOR_<name>+.
* Layers are named with the syntax: +VK_LAYER_{AUTHOR|FQDN}_<name>+.
Both extensions and layer names include a +VK_+ prefix, as described in the
<<naming-preprocessor,Preprocessor Defines>> section above. In addition,
layers add a +LAYER_+ prefix.
Extension and layer names must both be valid C language identifiers.
[[extensions-naming-conventions-name-strings]]
=== Extension and Layer Name Strings
The +<name>+ portion of extension and layer names is a concise name
describing the purpose or functionality of the extension or layer. The
underscore (`_`) character is used as a delimiter between words. Every
character of the name must be in lower case.
=== Author IDs
Extension and layer names also contain an _author ID_, indicated by +AUTHOR+
above, identifying the author of the extension/layer. This ID is a short,
capitalized string identifying an author, such as a Khronos member
developing Vulkan implementations for their devices, or a non-Khronos
developer creating Vulkan layers. Author IDs must be registered with
Khronos.
Some authors have platform communities they wish to distinguish between, and
can register additional author IDs for that purpose. For example, Google
has separate Android and Chrome communities.
Details on how to register an author ID are provided below. Layer authors
not wishing to register an author ID with Khronos can instead use a
fully-qualified domain name (FQDN) as the ID. The FQDN should be a domain
name owned by the author. FQDNs cannot be used for extensions, only for
layers.
* The following are examples of extension and layer names, demonstrating
the above syntax:
** Extension names all use the base prefix +VK_+.
** Khronos-ratified extensions add the reserved author ID +KHR+, and
will use the prefix +VK_KHR_+.
** The following author IDs are reserved and must not be used:
*** +VK+ - To avoid confusion with the top-level +VK_+ prefix.
*** +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
developed via cooperation between, and intended to be supported by two
or more registered authors) add the special author ID +EXT+ to the base
prefix, and will use the prefix +VK_EXT_+.
** Traditional author-specific extensions developed by one author (or one
author in cooperation with non-authors) add the author ID to the
base prefix. For example, NVIDIA will use the prefix +VK_NV_+, and
Valve will use the prefix +VK_VALVE_+. Some authors can have
additional registered author IDs for special purposes. For
example, an Android extension developed by Google - but part of an
Android open-source community project, and so not a proprietary Google
extension - will use the author ID +ANDROID+.
** Layer names follow the same conventions as extensions, but use the base
prefix +VK_LAYER_+.
** Because layers need not be registered with Khronos, an alternative
mechanism is needed to allow creating unique layer names without
registering an author ID. Layer authors that prefer not to register an
author ID can instead use a fully-qualified domain name (FQDN) in
reverse-order as an author ID, replacing +.+ (period) with `_`
(underscore) characters. The restriction that layer names must be valid
C identifiers means that some FQDNs cannot be used as part of layer
names.
[source, c]
.Example
----
// Khronos extension name
VK_KHR_mirror_clamp_to_edge
// Multivendor extension name
VK_EXT_debug_marker
// Vendor extension name using author ID NV
VK_NV_glsl_shader
// Vendor layer name using author ID LUNARG
VK_LAYER_LUNARG_vktrace
// Layer name using the FQDN www.3dxcl.invalid instead of an author ID
VK_LAYER_invalid_3dxcl_www
----
[NOTE]
.Note
====
To avoid linking to a nonexistent domain, the reserved TLD +.invalid+ is
used in the example above.
====
[[extensions-naming]]
== Extension Command, Type, and Token Naming Conventions
Extensions may add new commands, types, and tokens, or collectively
``objects'', to the Vulkan API. These objects are given globally unique
names by appending the author ID defined above for the extension name
as described in the <<naming-extension-identifiers, Extension Identifier
Naming Conventions>> section above.
[[extensions-api-registry]]
== The Vulkan Registry
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 IDs, core and
extension interface definitions, definitions of individual commands and
structures, and other information which must be agreed on by all
implementations. The registry is used to maintain a single, consistent
global namespace for the registered entities, to generate the
Khronos-supplied +vulkan.h+, and to create a variety of related
documentation used in generating the API specification and reference pages.
[[extensions-author-ID]]
== Registering an Author ID with Khronos
Previous Khronos APIs could only officially be modified by Khronos members.
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
extensions is provided.
Extension authors will be able to create an account on Github and register
an author ID with Khronos through the +<<KhronosGroup/Vulkan-Docs>>+ project.
The author ID must be used for any extensions that author registers. The
same mechanism will be used to request registration of extensions or layers
with Khronos, as described below.
To reserve an author ID, propose a merge request against
<<extensions-api-registry,+vk.xml+>> in the +1.0+ branch. The merge must
add a +<tag>+ XML tag and fill in the +name+, +author+ and +contact+
attributes with the requested author ID, the author's formal name (e.g.
company or project name), and contact email address, respectively. The
author ID will only be reserved once this merge request is accepted.
Please do not try to reserve author IDs which clearly belong to another
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 IDs that are not requested in good
faith.
[[extensions-vendor-id]]
== Registering a Vendor ID with Khronos
Vulkan implementers must report a valid vendor ID for their implementation
when queried by fname:vkGetPhysicalDeviceProperties, as described in the
``Devices and Queues'' section of the <<Vulkan API Specification>>. If
there is no valid PCI vendor ID defined for the physical device,
implementations must obtain a Khronos vendor ID.
Khronos vendor IDs are reserved in a similar fashion to
<<extensions-author-ID,author IDs>>. While vendor IDs are not
directly related to API extensions, the reservation process is very similar
and so is described in this section.
To reserve an Khronos vendor ID, you must first have a Khronos author ID.
Propose a merge request against <<extensions-api-registry,+vk.xml+>> in the
+1.0+ branch. The merge must add a +<vendorid>+ tag and fill in the +name+
and +id+ attributes. The +name+ attribute must be set to the author ID. The
+id+ attribute must be the first sequentially 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 Vulkan implementation and require one for that
purpose.
== Registering Extensions and Layers
Extensions must be registered with Khronos. Layers may be registered, and
registration is strongly recommended. Registration means:
* Receiving an extension number.
* 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 Vulkan API, including definitions of
those additions to +vk.xml+.
Registration for Khronos members is handled by filing a merge request in the
internal gitlab repository against the branch containing the core
specification against which the extension or layer will be written. The
merge must modify +vk.xml+ to define extension names, API interfaces, and
related information. Registration is not complete until the registry
maintainer has validated and accepted the merge.
Since this process could in principle be completely automated, this
suggests a scalable mechanism for accepting registration of non-Khronos
extensions. Non-Khronos members who want to create extensions must register
with Khronos by creating a github account, and registering their author
ID and/or FQDNs to that account. They can then submit new extension
registration requests by proposing merges to +vk.xml+. On acceptance of the
merge, the extension will be registered, though its specification need not
be checked into the Khronos github repository at that point.
The registration process can be split into several steps to accommodate
extension number assignment prior to extension publication:
* Acquire an extension number. This is done by proposing a merge request
against +vk.xml+ similarly to how <<extensions-author-ID,author
IDs are reserved>>. The merge should add a new +<extension>+ tag
at the end of the file with attributes specifying the proposed extension
+name+, the next unused sequential extension +number+, the +author+ and
+contact+ information (if different than that already specified for the
author ID used in the extension name), and finally, specifying
+supported="disabled"+. The extension number will be reserved only once
this merge request is accepted into the +1.0+ branch.
* 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 Vulkan API branch.
** Publishing on the <<KhronosGroup/Vulkan-Docs,Khronos public github
repository>> is preferred whenever possible. Khronos members may
instead create branches on Khronos' internal gitlab server, but those
branches will eventually be mirrored to github.
* Mark the extension as enabled, by proposing a merge to the +1.0+ branch
changing the +supported+ attribute value of the +<extension>+ to
+supported="vulkan"+. This should be completely automated and under the
control of the publishers, to allow them to align publication on Khronos
with product releases. However, complete automation might be difficult,
since steps such as regenerating and validating +vulkan.h+ are involved.
Once the merge is accepted and the corresponding updated header with the
new extension interface is committed to the +1.0+ branch, publication
is complete.
The automated process does not exist yet, and would require significant
investment in infrastructure to support the process on the Khronos servers.
ifdef::editing-notes[]
[NOTE]
.editing-note
====
TODO: This section is subject to change and not complete yet, but in broad
is how we expect extension registration and specifications to work. The
process will be refined as members and outside authors define further
extensions.
====
endif::editing-notes[]
== Documenting Extensions
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 <<Vulkan API Specification>>. As such, the branch name
will be: +1.0-VK_KHR_surface+ in the Github +<<KhronosGroup/Vulkan-Docs>>+
project.
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 branch contents.
Extensions should be merged according to their registered extension number.
If two extensions both modify the same portion of the specification, the
higher-numbered extension should take care to deal with any conflicts.
The WSI extensions were used to help prototype what should be done for
extensions. This includes the following:
* All extensions should add an appendix to the Vulkan specification. This
should be modeled after what was done for the +VK_KHR_surface+
extension (in the +1.0-VK_KHR_surface+ Github branch), which contains
some high-level information about the extension (as well as code
examples, and revision history) in the +appendices/vk_khr_surface.txt+
file.
* Each extension's appendix file is included by adding an +include+
statement to the +doc/specs/vulkan/vkspec.txt+ file. Since most
extensions will all put their +include+ line at the same place in this
file, they should add this statement on the +1.0+ branch, even though
the file will not actually exist on the +1.0+ branch. This helps avoid
merge conflicts when 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
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 +1.0+ branch in order to
avoid merge conflicts.
* If an extension is more of an addition to the Vulkan specification,
the extension should add a chapter to the Vulkan specification.
[NOTE]
.Note
====
As of June 2016, we have found that the ``extension branch'' model poses
some challenges. It works fine for individual extensions, but trying to
merge extensions into combined branches, such as the +1.0-wsi_extensions+
branch containing all Khronos WSI family extensions, invariably produces a
number of merge conflicts which must be manually resolved. We are likely to
continue using the extension branch model, and hope to simplify the merge
process over time, but authors should be aware that it is not as completely
transparent as we had hoped initially.
====
== Assigning Extension Token Values
Extensions can define their own enumeration types and assign any values to
their enumerants that they like. Each enumeration has a private namespace,
so collisions are not a problem. However, when extending existing
enumeration objects with new values, care must be taken to preserve global
uniqueness of values. Enumerations which define new bits in a bitmask are
treated specially as described in
<<extensions-reserving-bitmask-values,Reserving Bitmask Values>> below.
Each extension is assigned a range of values that can be used to create
globally-unique enum values. Most values will be negative numbers, but
positive numbers are also reserved. The ability to create both positive and
negative extension values is necessary to enable extending enumerations such
as etext:VkResult that assign special meaning to negative and positive
values. Therefore, 1000 positive and 1000 negative values are reserved for
each extension. Extensions must not define enum values outside their
reserved range without explicit permission from the owner of those values
(e.g. from the author of another extension whose range is infringed on, or
from the Khronos Registrar if the values do not belong to any extension's
range).
[NOTE]
.Note
====
Typically, extensions use a unique offset for each enumeration constant they
add, yielding 1000 distinct token values per extension. Since each
enumeration object has its own namespace, if an extension needs to add many
enumeration constant values, it can reuse offsets on a per-type basis.
====
The information needed to add new values to the XML are as follows:
* The **extension name** (e.g. +VK_KHR_swapchain+) that is adding the new
enumeration constant.
* The existing enumeration **type** being extended (e.g.
stext:VkStructureType).
* The name of the new enumeration **token** being added (e.g.
etext:VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR).
* The **offset**, which is an integer between 0 and 999 relative to the
base being used for the extension.
* The **direction** may be specified to indicate a negative value
(+dir="-"+) when needed for negative etext:VkResult values indicating
errors, like etext:VK_ERROR_SURFACE_LOST_KHR. The default direction is
positive, if not specified.
Implicit is the registered number of an extension, which is used to create a
range of unused values offset against a global extension base value.
Individual enumerant values are calculated as offsets in that range. Values
are calculated as follows:
* base_value = 1000000000
* range_size = 1000
* enum_offset(extension_number,offset) = base_value +
(extension_number - 1) × range_size + offset
* Positive values: enum_offset(extension_number,offset)
* Negative values: -enum_offset(extension_number,offset)
The exact syntax for specifying extension enumerant values is defined in the
+readme.pdf+ specifying the format of +vk.xml+, and extension authors can
also refer to existing extensions for examples.
[[extensions-reserving-bitmask-values]]
=== Reserving Bitmask Values
Enumerants which define bitmask values are a special case, since there are
only a small number of unused bits available for extensions. For core Vulkan
API and KHR extension bitmask types, reservations must be approved by a
vote of the Vulkan Working Group. For EXT and vendor extension bitmask
types, reservations must be approved by the listed contact of the
extension. Bits are not reserved, and must not be used in a published
implementation or specification until the reservation is merged into
<<extensions-api-registry,+vk.xml+>> by the registry maintainer.
[NOTE]
.Note
====
In reality the approving authority for EXT and vendor extension bitmask
additions will probably be the owner of the github branch containing the
specification of that extension; however, until the github process is fully
defined and locked down, it is safest to refer to the listed contact.
====
== Required Extension Tokens
In addition to any tokens specific to the functionality of an extension,
all extensions must define two additional tokens.
* VK_EXTNAME_SPEC_VERSION is an integer constant which is the revision of
the extension named +VK_extname+ (EXTNAME is all upper-case, while
extname is the capitalization of the actual extension name) in
+vulkan.h+. This value begins at 1 with the initial version of an
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
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
behavior of the lowest-numbered revision can be used.
* VK_EXTNAME_EXTENSION_NAME is a string constant which is the name of the
extension.
For example, for the WSI extension +VK_KHR_surface+, at the time of writing
the following definitions were in effect:
[source,c]
---------------------------------------------------
#define VK_KHR_SURFACE_SPEC_VERSION 24
#define VK_KHR_SURFACE_EXTENSION_NAME "VK_KHR_surface"
---------------------------------------------------
== Extension Objects, Enums, and Typedefs
Expanding on previous discussion, extensions can add values to existing
enums; and can add their own commands, enums, typedefs, etc. This is done
by adding to <<extensions-api-registry,+vk.xml+>>. All such additions will
be included in the +vulkan.h+ header supplied by Khronos.
[NOTE]
.Note
====
Application developers are encouraged to be careful when using +switch+
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.
====
[[extension-function_prototypes]]
== Extension Function Prototypes
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 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 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
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 Vulkan ABI.
The initial set of WSI extension commands (i.e. for VK_KHR_surface,
VK_KHR_swapchain, and VK_KHR_*_surface) are considered to be part of the
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.
[NOTE]
.Note
====
Based on feedback from implementers, Khronos expects that the Android,
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
these implementations.
====
== Accessing Extension Functions from Programs
flink:vkGetInstanceProcAddr and flink:vkGetDeviceProcAddr can be used in
order to obtain function pointer addresses for core and extension commands
(per the description in the ``Command Function Pointers'' section of the
<<Vulkan API Specification>>). 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.
[NOTE]
.Note
====
The Vulkan API loader for Android, Linux, and Windows exports functions for all
core Vulkan API commands, and for a set of WSI extension commands that
are applicable to those operating systems (see Vulkan loader documentation for
the relevant platform/OS for details). The
WSI functions are considered special, because they are required for many
applications.
====
[[extensions-interactions]]
== Extension Interactions
Extensions modifying the behavior of existing commands should provide
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 ``Valid Usage'' section of the
<<Vulkan API Specification>>. Extension
structures defined by multiple extensions affecting the same structure can
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
with a pname:sType defined by the extension, but this approach is
discouraged and should not be used.
When chaining multiple extensions to a structure, the implementation will
process the chain starting with the base parameter and proceeding through
each successive chained structure in turn. Extensions should be defined to
accept any order of chaining, and must define their interactions with other
extensions such that the results are deterministic. If an extension needs a
specific ordering of its extension structure with respect to other
extensions in a chain to provide deterministic results, it must define the
required ordering and expected behavior as part of its specification.

548
doc/specs/vulkan/style/styleguide.txt → doc/specs/vulkan/style/markup.txt
View File

@ -1,92 +1,3 @@
// Copyright (c) 2015-2016 The Khronos Group Inc.
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
Vulkan Style Guide
==================
Jon Leech
include::../specversion.txt[]
:toc2:
:toclevels: 3
:max-width: 100
:numbered:
:doctype: book
:imagewidth: 800
:fullimagewidth: {svgpdf@pdf:scaledwidth="75%":width="800"}
:cl: &#x3a;
:leveloffset: 1
// :icons:
// :toc-placement: manual
<<<<
include::../copyright.txt[]
<<<<
[[introduction]]
= Introduction
This is the Vulkan Documentation Style Guide, containing the collected
rules, guidelines, tricks, and tips for authors contributing to the Vulkan
API Specification (the _Specification_), reference pages, and other
documentation such as white papers and tutorials (if and when we have them).
These are collectively referred to as _Vulkan Documentation_ or just
_documentation_ below. The primary focus and inspiration is the
Specification, although all of the markup and most of the writing style is
equally applicable to the reference pages.
The primary purpose of the style guide is to achieve consistency of both
source and output documents. Consistency makes it easier for editors,
reviewers, and users of our documentation to understand and modify it. When
the style guide makes prescriptive statements, please follow them unless
there are compelling reasons not to. If you have a strong desire to change
these guidelines, you can try to make a case starting with the Specification
editors, and proceeding to the Vulkan Working Group if need be.
[NOTE]
.Note
====
But be prepared to make the numerous merge requests applying those changes
to all parts of our documentation, if your change request is accepted!
====
The style guide is broken into two major sections:
* <<markup,Markup Style>> - how to write asciidoc and XML source that
follows consistent formatting and layout guidelines, tags special terms
and phrases for proper processing by the spec generation tools, etc.
* <<writing,Writing Style>> - overall and fine-grained structure and
conventions, normative language use, API naming conventions, common
words and phrases to use (and those not to use), linking and
cross-referencing, etc.
[[introduction-asciidoc]]
== Asciidoc Markup
Vulkan Documentation is primarily written in Asciidoc, a form of text markup
language. Asciidoc is documented on its website at http://www.asciidoc.org/.
[[userguide]]
References to the Asciidoc User Guide are to sections in the document at
http://asciidoc.org/userguide.html .
Asciidoc packages are available for Linux, MacOS, and Microsoft Windows,
together with the other toolchain components required to generate output
documents corresponding to the markup. Note that we are currently using the
original _asciidoc_ tool. Other tools to process Asciidoc markup, such as
_asciidoctor_, are also available, but are not currently usable for our
documents. While asciidoctor supports the basic Asciidoc markup syntax, it
does not support asciidoc macros, which are used extensively in the
documentation. It is possible to move from asciidoc to asciidoctor, but this
will be a significant effort, taking place after Vulkan 1.0 is published.
This guide does not address the toolchain and build process, just source
documents.
[[markup]]
= Markup Style
@ -121,9 +32,10 @@ file), and follow the title by a blank line, to set off sections visibly.
[[markup-sample-section]]
== Sample Section
This is a sample section of the Vulkan Specification, nested one level
inside a chapter. Sections can be nested up to level 5, although not all
levels are included in the Table of Contents.
This is a sample section structurally similar to the <<Vulkan API
Specification>>, nested one
level inside a chapter. Sections can be nested up to level 5, although not
all levels are included in the Table of Contents.
[[markup-layout]]
@ -211,7 +123,7 @@ naming convention <<markup,discussed above>>. Anchors to other sections of
the document may be inserted as needed. In addition, the autogenerated
include files defining commands, structures, enumerations and flags all
define anchors whose name is the name of the command or type being defined,
so it's easy to link to a (for example) a command name such as
so it is easy to link to a (for example) a command name such as
<<vkCreateCommandPool>>.
If you want a cross-reference to an anchor to appear as something other than
@ -233,13 +145,13 @@ Link to a command name such as <<vkCreateCommandPool>>.
This section discusses Asciidoc macros used in the document. In addition to
the macros defined by asciidoc itself, additional macros are defined by the
Specification and Reference Page configuration files.
<<Vulkan API Specification>> and Reference Page configuration files.
[[markup-samplesection-images]]
=== Figures
All figures (images) must be marked up as follows, to ensure there's an
All figures (images) must be marked up as follows, to ensure there is an
anchor and that the figure is given a caption which shows the figure number
and is added to the list of figures:
@ -257,7 +169,7 @@ rule in +images/Makefile+ to generate PDF.
=== API Markup Macros
These macros must: be used to tag command, structure, enumeration,
These macros must be used to tag command, structure, enumeration,
enumerant, and other Vulkan-specific names so they can be rendered in a
distinctive fashion, link to definitions of those names, and be easily
searched for in the source documents. The validation scripts (`make
@ -367,9 +279,9 @@ code:NULL
_Glossary terms_ are currently marked up using underscore markup where they
are defined in the documents, as well as being added to the formal Glossary
appendix in the Specification. However, we will probably change to using
custom macros soon, to enable linkage between the glossary appendix and
definitions in the spec body.
appendix in the <<Vulkan API Specification>>. However, we will probably change to using
custom macros soon, to enable linkage between the glossary and definitions
in the spec body.
.Example Markup
----
@ -379,12 +291,13 @@ _Glossary terms_
=== Normative Terminology
Normative terminology is precisely defined in section 1.3 of the Vulkan API
Specification, and is used to visually tag terms which express mandatory and
Normative terminology is precisely defined in section 1.3 of the
<<Vulkan API Specification>>, and is used to visually tag terms which express mandatory and
optional behavior of Vulkan implementations, and of applications using
Vulkan.
Whenever one of these terms appears in the Specification, it must: be tagged
Whenever one of these terms appears in the <<Vulkan API Specification>>, it
must be tagged
using the macros, to indicate that its use has been carefully considered and
is consistent with the definitions in section 1.3. This is extremely
important for determining IP that is in and out of Scope during Ratification
@ -394,7 +307,7 @@ table:
.Normative Terminology Macros
[width="100%",options="header"]
|=====
| Macro Name | Meaning
| Macro Name | Output
| can{cl} | can:
| cannot{cl} | cannot:
| may{cl} | may:
@ -418,13 +331,13 @@ necessary, additional capitalized macros could be added).
==== Optional Behavior
If a described behavior of the implementation is not necessary for
conformance, use the terms _may:_ or _optional:_ to describe it.
conformance, use the terms _may{cl}_ or _optional{cl}_ to describe it.
If a described usage pattern by the application is allowed but
not necessary, use the term _can:_ to describe it.
not necessary, use the term _can{cl}_ to describe it.
If language flows more logically using the term "may not", use the term
_may: not_ to describe it.
_may{cl} not_ to describe it.
==== Optional Functionality
@ -438,8 +351,8 @@ not required:
----
Implementations are not mandated to support functionality which is not
required:, but if they do, they must: behave as described by the
Specification. The term _functionality_ includes API features, extensions,
required, but if they do, they must behave as described by the
<<Vulkan API Specification>>. The term _functionality_ includes API features, extensions,
and layers.
@ -546,7 +459,7 @@ Contents of an implementor's note go here.
There are a variety of common terms that have several equivalent word
choices. Always use the words in the first column instead of the alternate
terms. This list may not be comprehensive; when in doubt, be guided by the
existing API Specification.
existing <<Vulkan API Specification>>.
.Word Choices
[width="100%",options="header"]
@ -577,7 +490,6 @@ existing API Specification.
| Except when referring to *host-accessible subresources*
| implementation| system |
| indices | indexes | More common
| it is | it's | In general, avoid contractions.
| member | field |
| pname:parameter are/is
| pname:parameter specifies (denotes, indicates)
@ -605,6 +517,30 @@ See Gitlab issue #61.
====
=== Avoid Contractions
Contractions make the specification sound less formal and using them would
be inconsistent with the many non-contraction forms already in use in the
spec.
.Word Choices
[width="100%",options="header"]
|=====
| Use This | Instead Of
| are not | aren't
| cannot{cl} | can't
| does not | doesn't
| do not | don't
| has not | hasn't
| is not | isn't
| it is | it's
| that is | that's
| there is | there's
| we are | we're
| will not | won't
|=====
=== Terms to Use With Caution
The term _subset_ is sometimes used to refer to a _strict subset_, and
@ -614,12 +550,12 @@ to use either _subset_ or _strict subset_ as appropriate.
=== Terms to Avoid
Don't describe anything in the documentation using vague or wishy-washy
Do not describe anything in the documentation using vague or wishy-washy
terms. Our goal is to precisely describe behavior of implementations.
The normative terms may:, optional:, and should: are available when
The normative terms may{cl}, optional{cl}, and should{cl} are available when
implementations may make choices of behavior, but when such choices are
allowed, each choice still must: have well-defined behavior.
allowed, each choice still must have well-defined behavior.
.Terms to Avoid
[width="100%",options="header"]
@ -628,389 +564,7 @@ allowed, each choice still must: have well-defined behavior.
| expect | And variants such as _expected_
| likely | And variants such as _will likely_
| allowed, could, generally, might, probably, perhaps
| And all other such terms of choice. Use _may:_ or _can:_
| And all other such terms of choice. Use _may{cl}_ or _can{cl}_
depending on the context.
| may: or may: not | Just use _may:_.
| may{cl} or may{cl} not | Just use _may{cl}_.
|=====
[[writingstyle]]
= Writing Style
[[writingstyle-misc]]
== Miscellaneous Grammar, Spelling, and Punctuation Issues
=== Use the Oxford Comma (Serial Comma)
When writing a sentence listing a series of items, include a comma before
the ``and'' separating the last item.
*Correct:* The red, green, blue, and alpha components.
*Incorrect:* The red, green, blue and alpha components.
Also see http://blog.oxforddictionaries.com/2011/06/oxford-comma/
=== Numbers in Text
When describing the need for a small number of objects, smaller than ten, spell
the number out (e.g. ``one''). If you are describing a literal value that is a
small number, you may use a numeric value (e.g. ``1'').
For example, instead of writing that a bitmask ``contains 1 or more bits'',
write that it ``contains one or more bits''. A counter example is that it is okay
to write ``For non-stereoscopic-3D applications, this value is 1.''
=== Use American Spelling Conventions
In case of conflict, use American rather than British spelling
conventions. For example:
*Correct:* color, signaled.
*Incorrect:* colour, signalled.
[[writingstyle-describing]]
== Describing Commands and Parameters
The Specification describes API commands followed by descriptions of their
parameters, which are usually simple scalar types, handles or pointers to
Vulkan objects or arrays of objects, or structures containing combinations
of scalar types and objects. The templates and examples shown and annotated
here are based on the Specification. Do not vary from them without
compelling need.
Normative parts of the Specification should describe _what_ something does,
rather than _how_ or _why_ an application would want to use it.
[NOTE]
.Guideline
====
As a simple example, say
``To create a command pool, call fname:vkCreateCommandPool''
rather than
``You/The application/The user can create a command pool by calling
fname:vkCreateCommandPool''.
====
Explanations of _why_ and _how_ should largely be confined to reference
documentation, sample code, tutorials, and other such documents. Occasional
non-normative explanations can be included in the Specification using
<<markup-informative-notes,informative notes>>.
[[writingstyle-latexmath]]
== LaTeX Math Markup
There is a considerable amount of math in the documentation, ranging from
simple arithmetic expressions to complicated conditionals. For the most
part, math is marked up using LaTeX math notation, which is either passed
through to the Mathjax browser renderer for HTML outputs, or passed through
to LaTeX for PDF outputs. For some very simple math expressions, asciidoc
markup can be used.
[NOTE]
.Note
====
We still haven't got the latexmath vs. asciidoc font situation sorted out
for all target output forms, so there can be some visual inconsistencies.
====
While LaTeX math macros, including the amsmath package, are supported,
general LaTeX constructs are not.
_Inline math_ is encoded using the latexmath{cl} macro. For example:
* latexmath:[$[0,1\]$]
* latexmath:[$x \cdot 0 = 0 \cdot x = 0$]
* latexmath:[${\textbf c} = t {\textbf c}_1 + (1-t){\textbf c}_2. $]
.Example Markup
----
latexmath:[$[0,1\]$]
latexmath:[$x \cdot 0 = 0 \cdot x = 0$]
latexmath:[${\textbf c} = t {\textbf c}_1 + (1-t){\textbf c}_2. $]
----
Note the escaped bracket in markup for the first expression, which is
necessary to work around asciidoc macro parsing:
_Block math_ is used for more complex equations. This example uses the
amsmath `align*` macros to delimit the expression:
[latexmath]
+++++++++++++++++++
\begin{align*}
c_{RGB} & =
\begin{cases}
\frac{c_{sRGB}}{12.92} & \textrm{for } c_{sRGB} \leq 0.04045 \\
\left ( \frac{c_{sRGB}+0.055}{1.055} \right )^{2.4} & \textrm{for } c_{sRGB} > 0.04045
\end{cases}
\end{align*}
+++++++++++++++++++
.Example Markup
----
[latexmath]
+++++++++++++++++++
\begin{align*}
c_{RGB} & =
\begin{cases}
\frac{c_{sRGB}}{12.92} & \textrm{for } c_{sRGB} \leq 0.04045 \\
\left ( \frac{c_{sRGB}+0.055}{1.055} \right )^{2.4} & \textrm{for } c_{sRGB} > 0.04045
\end{cases}
\end{align*}
+++++++++++++++++++
----
This example uses normal LaTeX math brackets to delimit the expression:
[latexmath]
+++++++++++++++++++
\[
V =
\begin{cases}
(-1)^S \times 0.0, & E = 0, M = 0 \\
(-1)^S \times 2^{-14} \times { M \over 2^{10} },
& E = 0, M \neq 0 \\
(-1)^S \times 2^{E-15} \times { \left( 1 + { M \over 2^{10} } \right) },
& 0 < E < 31 \\
(-1)^S \times Inf, & E = 31, M = 0 \\
NaN, & E = 31, M \neq 0
\end{cases}
\]
+++++++++++++++++++
.Example Markup
----
[latexmath]
+++++++++++++++++++
\[
V =
\begin{cases}
(-1)^S \times 0.0, & E = 0, M = 0 \\
(-1)^S \times 2^{-14} \times { M \over 2^{10} },
& E = 0, M \neq 0 \\
(-1)^S \times 2^{E-15} \times { \left( 1 + { M \over 2^{10} } \right) },
& 0 < E < 31 \\
(-1)^S \times Inf, & E = 31, M = 0 \\
NaN, & E = 31, M \neq 0
\end{cases}
\]
+++++++++++++++++++
----
[[writingstyle-example]]
== An Example Command Description
The <<sample-command,next section>> is a sample based on the Specification,
and describes a command in enough detail to see the different usage patterns
and layout / markup used. Informative notes discussing markup and guidelines
are interspersed with the example description to explain how and why it
looks as it does.
[[sample-command]]
== Sample Command Description: Creating Command Pools
To create a command pool, call:
[NOTE]
.Guideline
====
Use a short, active sentence when describing what commands do, instead of
more passive phrasing like ``A command pool is created by calling:'' or ``The
application may create a command pool by calling:''.
====
include::../protos/vkCreateCommandPool.txt[]
[NOTE]
.Guideline
====
After the description, include the autogenerated prototype for the command
from the `../protos/` directory:
include::../protos/vkCreateCommandPool.txt[]
Note that each autogenerated command, enumeration, flag, or structure
definition include file also defines a corresponding asciidoc anchor which
is the base name of the file. In this case, the anchor is named
`vkCreateCommandPool`.
====
* pname:device is the logical device that the command pool is created on.
* pname:pCreateInfo points to an instance of the
slink:VkCommandPoolCreateInfo structure containing information used to
create the command pool.
* pname:pAllocator controls host memory allocation as described in the
<<memory-allocation, Memory Allocation>> chapter.
* pname:pCommandPool points to a handle in which the created command pool
object is returned.
[NOTE]
.Guideline
====
Each command parameter is described in a separate bullet list entry,
followed by validity rules, then detailed descriptions of any new
structures, flags, or enumerations introduced by this command.
Each parameter should appear as a separate bullet list item beginning with
the parameter name, in the same order as parameters appear in the command.
This aids in extracting short descriptions of parameters for inclusion in
annotated headers and similar documentation. Make sure to tag each parameter
with the pname{cl} macro.
Strive for compact notation, and in particular always try to use the
phrasing ``pname{cl}param _is_'' rather than wordier forms such as
``pname{cl}param _specifies_'' or ``The pname{cl}param parameter specifies''. In
general there is no need to describe a parameter which is a Vulkan object
handle *as* a handle; for example, say ``pname{cl}device is the logical
device'' rather than ``pname{cl}device is a handle to the logical device''. An
exception is object creation functions, where a pointer to a handle of the
proper type is used to return the newly created object.
====
include::../validity/protos/vkCreateCommandPool.txt[]
[NOTE]
.Guideline
====
Parameter and member validation language for commands and structures is also
autogenerated from vk.xml, and included from the `../validity/` directories:
include::../validity/protos/vkCreateCommandPool.txt[]
====
The sname:VkCommandPoolCreateInfo structure is defined as:
include::../structs/VkCommandPoolCreateInfo.txt[]
[NOTE]
.Guideline
====
Structures and enumerations first used as parameters of a command are
described next, by including the autogenerated interface file for that
structure or enumeration:
include::../structs/VkCommandPoolCreateInfo.txt[]
====
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags is a combination of bitmask flags indicating usage behavior
for the pool and command buffers allocated from it. Possible values
include:
+
--
include::../enums/VkCommandPoolCreateFlagBits.txt[]
** ename:VK_COMMAND_POOL_CREATE_TRANSIENT_BIT indicates that command buffers
allocated from the pool will be short-lived.
** ename:VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT controls whether
command buffers allocated from the pool can: be individually reset.
--
* pname:queueFamilyIndex designates a queue family. Command buffers in
this command pool must: be submitted on queues from the same family.
[NOTE]
.Guideline
====
Each structure member is described in a separate bullet list entry. For the
stext:Vk*CreateInfo structures in particular, there is standard boilerplate
for the pname:sType and pname:pNext members, followed by the members
specific to the structure.
----
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an
extension-specific structure.
----
In some cases, such as when the type of a member is itself a new type, the
entry will cover multiple paragraphs. In these cases the normal list nesting
and indentation guidelines cannot be applied due to limitations of the
asciidoc parser. It is usually best to append a block following the first
paragraph of such a list item:
----
* pname:flags is a combination of bitmask flags
indicating usage behavior for the pool and
command buffers allocated from it. Possible
values include:
+
--
\include::../enums/VkCommandPoolCreateFlagBits.txt[]
** ename:VK_COMMAND_POOL_CREATE_TRANSIENT_BIT
indicates that command buffers allocated
from the pool will be short-lived.
** ename:VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT
controls whether command buffers allocated from
the pool can: be individually reset.
--
----
====
include::../validity/structs/VkCommandPoolCreateInfo.txt[]
[NOTE]
.Guideline
====
Following the definition of structure members, include the validity language
for this structure:
include::../validity/structs/VkCommandPoolCreateInfo.txt[]
====
// = API Naming Conventions
//
// It's not clear these belong in this document. They are currently
// captured in the member Wiki under API_Design/Cleanup
//
// If they do go here, we would discuss naming conventions starting with
// prefixes, camelCase, suffixes for size and arrayness, choice of names for
// similar parameters, templates for CreateInfo structs, parameter naming &
// ordering (especially length/array pointer pairs), etc.
= To Be Done
* Something about Image formats
* Something about validation scripts
* Something about pictures
* Glossary lists
* New param/enum macros
= Revision History
* May 22, 2016 - Add markup and image creation rules, after fixing missing
figure captions for public Github issue 219.
* May 1, 2016 - Include feedback from public Github issues 120 and 190. Use
consistent conventions for defining structures. Use American rather than
British spelling conventions.
* March 12, 2016 - Recommend against "the value of".
* February 26, 2016 - Replace use of the "maynot{cl}" macro with "may{cl} not".
* February 16, 2016 - Place asciidoc conversion post-release.
* February 9, 2016 - Added quotation mark convention.
* February 1, 2016 - add the Oxford Comma section and issue resolution.
* January 26, 2016 - add bullet-list style description of command parameters.
* January 11, 2016 - add ``Numbers in Text'' section from WSI work.
* December 16, 2015 - Make ``begin / end'' preferred terms to ``start /
finish''.
* December 15, 2015 - Make ``implementation'' preferred term instead of
``system''.
* December 13, 2015 - Add tlink{cl}/tname{cl} macros for function pointer
types.
* December 10, 2015 - Initial release for feedback.

424
doc/specs/vulkan/style/naming.txt Normal file
View File

@ -0,0 +1,424 @@
// Copyright (c) 2016 The Khronos Group Inc.
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
[[naming]]
= API Naming Conventions
Identifiers in the Vulkan API (e.g. types, parameters, constants, etc.) all
follow a set of naming rules, providing a consistent scheme for developers.
The Vulkan C API uses prefixes as an implicit namespace control mechanism.
Bindings to other languages can choose not to use these prefixes if the
language provides an explicit namespace mechanism.
== General Naming Rules
Names of identifiers should generally be written with full words, avoiding
abbreviations, as a concise description of what that identifier is. For
example, the type of a structure containing information about how to create
an instance is stext:VkInstanceCreateInfo.
Abbreviations and prefixes are sometimes used in the API when they are in
common use. All abbreviations and prefixes used in the API must be approved
by the Vulkan working group, and be added to the
<<naming-abbreviations,Common Abbreviations>> and <<naming-prefixes,Standard
Prefixes>> sections, respectively.
Whenever an abbreviation exists for a particular word, it should be used in
place of the full word unless there is good reason not to.
[[naming-preprocessor]]
== Preprocessor Defines
Preprocessor definitions include an underscore `_` as a delimiter between
words, with every character in upper case.
Each definition is prefixed with `VK_`, followed by the name.
This rule applies to most declarations with the C Preprocessor's `#define`
token, including macros and constants. There are however a few exceptions:
* The header guard for each header includes an additional underscore `_` at
the end of the identifier.
** Example: `VULKAN_H_`
* Definitions that denote the presence of an extension follow the
<<extensions-naming-conventions-name-strings,extension name string
convention>>.
** Example: `VK_KHR_sampler_mirror_clamp_to_edge`
* Three `VKAPI_*` definitions are defined by the platform header to alias
certain platform-specific identifiers related to calling conventions.
** Examples: `VKAPI_ATTR`, `VKAPI_CALL` and `VKAPI_PTR`
* Preprocessor defines are occasionally used to create aliases between
other Vulkan identifiers, which usually happens when something was
originally misnamed. In these cases, the fixed name is added to the API,
and the old name is made into an alias of that. In these cases, the name
will be whatever the original misnamed identifier was.
[source, c]
.Example
----
// VK_VERSION_MAJOR (Macro)
#define VK_VERSION_MAJOR(version) ((uint32_t)(version) >> 22)
// VK_HEADER_VERSION (Base type)
#define VK_HEADER_VERSION 10
----
== Type Names
Type names are declared with no separator between words. Each word starts
with a capital letter, and every other character in each word is lower case.
Each type name is prefixed with `Vk`.
This rule applies to all type definitions except <<naming-funcpointers,
function pointer types>>, including struct and union types, handles,
base typedefs, and enumerant types.
[source, c]
.Example
----
// VkImage (Handle)
VK_NONDISP_HANDLE(VkImage)
// VkFlags (Base type)
typedef uint32_t VkFlags;
// VkResult (Enum type)
typedef enum VkResult {
...
};
// VkApplicationInfo (Struct)
typedef struct VkApplicationInfo {
...
} VkApplicationInfo;
// VkClearColorValue (Union)
typedef union VkClearColorValue {
...
} VkClearColorValue;
----
== Enumerant Names
Enumerants include an underscore `_` as a delimiter between words, with
every character in upper case.
Each enumerant name is prefixed with `VK_`.
Enumerants are prefixed with the exact name of the type it belongs to,
converted to the correct case (e.g. `VkStructureType` ->
`VK_STRUCTURE_TYPE_APPLICATION_INFO`).
This rule applies to all enumerants, with one exception.
* The "VkResult" enumerants are split into two sub types: error and success
codes.
** Success codes are not prefixed with anything other than `VK_`.
** Error codes are prefixed with `VK_ERROR_`.
[source, c]
.Example
----
// VK_FORMAT_UNDEFINED, VK_FORMAT_R4G4_UNORM_PACK8 (Enumerants)
typedef enum VkFormat {
VK_FORMAT_UNDEFINED = 0,
VK_FORMAT_R4G4_UNORM_PACK8 = 1,
...
};
// VkResult codes (Exception)
typedef enum VkResult {
VK_SUCCESS = 0,
...
VK_ERROR_OUT_OF_HOST_MEMORY = -1,
...
} VkResult;
----
== Function Names
Function names are declared with no separator between words. Each word
starts with a capital letter, and every other character in each word is
lower case.
Function names are prefixed with `vk`, with the exception of functions that
record commands into a command buffer and are instead prefixed with
`vkCmd`.
This rule applies to all function declarations.
[source, c]
.Example
----
// Function call
VKAPI_ATTR VkResult VKAPI_CALL vkCreateInstance( ... );
// Command buffer function
VKAPI_ATTR VkResult VKAPI_CALL vkCmdBindPipeline( ... );
----
[[naming-funcpointers]]
=== Function Pointer Type Names
Function pointer names are declared exactly as the equivalent statically
declared function would be declared, but prefixed with `PFN_`, standing for
"Pointer to FunctioN".
[source, c]
.Example
----
// PFN_vkCreateInstance (Function Pointer)
typedef VkResult (VKAPI_PTR *PFN_vkCreateInstance)( ... );
----
== Function Parameter and Struct/Union Member Names
Function parameter names are declared with no separator between words. Each
new word, *except* for the first, starts with a capital letter. All other
characters in the parameter name are in lower case.
Members/parameters of a type that is not a base type should generally be
named in a similar way to the type itself, with additional context added for
clarity when necessary.
Pointer members/parameters are prefixed with a number of `p` characters,
with one `p` for each level of indirection.
Function pointer members/parameters are prefixed with `pfn`.
Any member that describes the size of a memory allocation should be suffixed
with `Size`. If the context is self-evident from the structure name, then it
may simply be named `size`.
Any member that describes the number of something, such as an array length
or number of internal allocations, should be suffixed with `Count`. If the
context is self-evident from the structure name, then it may simply be named
`count`. The `size` rule overrides this rule, though it is possible to have
multiple sizes (e.g. `sizeCount`).
These rules apply to all function parameters and struct/union members, with a
single exception:
* The 'sType' member of structures is abbreviated as it is used in almost
every structure.
** The slightly odd naming prevents it clashing with any future variables.
** The s stands for "structure", referring to its enumerant type.
[source, c]
.Example
----
// Function parameters, including a twice indirected pointer.
VKAPI_ATTR VkResult VKAPI_CALL vkMapMemory(
VkDevice device,
VkDeviceMemory memory,
VkDeviceSize offset,
VkDeviceSize size,
VkMemoryMapFlags flags,
void** ppData);
// Structure members, including the sType exception and a single indirected
// pointer.
typedef struct VkMemoryBarrier {
VkStructureType sType;
const void* pNext;
VkAccessFlags srcAccessMask;
VkAccessFlags dstAccessMask;
} VkMemoryBarrier;
// Function pointer members
typedef struct VkAllocationCallbacks {
void* pUserData;
PFN_vkAllocationFunction pfnAllocation;
PFN_vkReallocationFunction pfnReallocation;
PFN_vkFreeFunction pfnFree;
PFN_vkInternalAllocationNotification pfnInternalAllocation;
PFN_vkInternalFreeNotification pfnInternalFree;
} VkAllocationCallbacks;
// Size member (pCode is not a specific array of anything, it is just a
// pointer to memory)
typedef struct VkShaderModuleCreateInfo {
VkStructureType sType;
const void* pNext;
VkShaderModuleCreateFlags flags;
size_t codeSize;
const uint32_t* pCode;
} VkShaderModuleCreateInfo;
// Count member
typedef struct VkSparseImageMemoryBindInfo {
VkImage image;
uint32_t bindCount;
const VkSparseImageMemoryBind* pBinds;
} VkSparseImageMemoryBindInfo;
----
[[naming-extension-identifiers]]
== Extension Identifier Naming Conventions
Identifiers defined by an extension are modified by appending the
extension's author ID to the end of the identifier, as described below.
Author IDs are obtained as described in the
<<extensions-naming-conventions,Extension and Layer Naming Conventions>>
section.
=== Extension Type Names
Types defined by extensions have the author ID appended to the end of
the type name.
[source, c]
.Example
----
// VkSurfaceFormatKHR (structure type with KHR appended)
typedef struct VkSurfaceFormatKHR {
VkFormat format;
VkColorSpaceKHR colorSpace;
} VkSurfaceFormatKHR;
----
=== Extension Enumerant Names
Enumerants defined by extensions have the author ID appended to the end
of the enumerant name, separated by an underscore. This includes the begin,
end, range and max values added to enumeranted type definitions by the
generator scripts.
[NOTE]
====
There is one exception to this rule in the
VK_KHR_sampler_mirror_clamp_to_edge extension. This functionality was
included in the original spec, but quickly separated out at release. Due to
this late change, the single enum exposed has retained its original
identifier to avoid compatibility issues:
ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
====
[source, c]
.Example
----
// VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR (enumerant with _KHR appended)
typedef enum VkCompositeAlphaFlagBitsKHR {
VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR = 0x00000001,
...
} VkCompositeAlphaFlagBitsKHR;
----
=== Extension Function Names
Function and function pointer type names defined by extensions have the
author ID appended to the end of the name.
[source, c]
.Example
----
// vkDestroySurfaceKHR (function with KHR appended)
VKAPI_ATTR void VKAPI_CALL vkDestroySurfaceKHR(
VkInstance instance,
VkSurfaceKHR surface,
const VkAllocationCallbacks* pAllocator);
typedef void (VKAPI_PTR *PFN_vkDestroySurfaceKHR)(
VkInstance instance,
VkSurfaceKHR surface,
const VkAllocationCallbacks* pAllocator);
----
[[naming-abbreviations]]
== Common Abbreviations
Abbreviations and acronyms are sometimes used in the
<<Vulkan API Specification>> and the Vulkan
API where they are considered clear and commonplace. All such abbrevations
used in the core API are defined here. Extensions should also use these
abbreviations where appropriate.
Src::
Source
Dst::
Destination
Min::
Minimum
Max::
Maximum
Rect::
Rectangle
Info::
Information
Lod::
Level of Detail
ID::
Identifier
UUID::
Universally Unique Identifier
Op::
Operation
R::
Red color component
G::
Green color component
B::
Blue color component
A::
Alpha color component
[[naming-prefixes]]
== Standard 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
here:
VK/Vk/vk::
Vulkan namespace +
All types, commands, enumerants and C macro definitions in the Vulkan
specification are prefixed with these two characters, according to the
rules defined above.
PFN/pfn::
Function Pointer +
Denotes that a type is a function pointer, or that a variable is of a
pointer type.
p::
Pointer +
Variable is a pointer.
vkCmd::
Commands that record commands in command buffers +
These API commands do not result in immediate processing on the device.
Instead, they record the requested action in a command buffer for
execution when the command buffer is submitted to a queue.
s::
Structure +
Used to denote the etext:VK_STRUCTURE_TYPE* member of each structure in
pname:sType.

338
doc/specs/vulkan/style/writing.txt Normal file
View File

@ -0,0 +1,338 @@
[[writing]]
= Writing Style
[[writing-misc]]
== Miscellaneous Grammar, Spelling, and Punctuation Issues
=== Use the Oxford Comma (Serial Comma)
When writing a sentence listing a series of items, include a comma before
the ``and'' separating the last item.
*Correct:* The red, green, blue, and alpha components.
*Incorrect:* The red, green, blue and alpha components.
Also see http://blog.oxforddictionaries.com/2011/06/oxford-comma/
=== Numbers in Text
When describing the need for a small number of objects, smaller than ten, spell
the number out (e.g. ``one''). If you are describing a literal value that is a
small number, you may use a numeric value (e.g. ``1'').
For example, instead of writing that a bitmask ``contains 1 or more bits'',
write that it ``contains one or more bits''. A counter example is that it is okay
to write ``For non-stereoscopic-3D applications, this value is 1.''
=== Use American Spelling Conventions
In case of conflict, use American rather than British spelling
conventions. For example:
*Correct:* color, signaled.
*Incorrect:* colour, signalled.
[[writing-describing]]
== Describing Commands and Parameters
The <<Vulkan API Specification>>
describes API commands followed by descriptions of their
parameters, which are usually simple scalar types, handles or pointers to
Vulkan objects or arrays of objects, or structures containing combinations
of scalar types and objects. The templates and examples shown and annotated
here are based on the <<Vulkan API Specification>>. Do not vary from them without
compelling need.
Normative parts of the <<Vulkan API Specification>> should describe _what_ something does,
rather than _how_ or _why_ an application would want to use it.
[NOTE]
.Guideline
====
As a simple example, say
``To create a command pool, call fname:vkCreateCommandPool''
rather than
``You/The application/The user can create a command pool by calling
fname:vkCreateCommandPool''.
====
Explanations of _why_ and _how_ should largely be confined to reference
documentation, sample code, tutorials, and other such documents. Occasional
non-normative explanations can be included in the <<Vulkan API Specification>>
using <<markup-informative-notes,informative notes>>.
[[writing-latexmath]]
== LaTeX Math Markup
There is a considerable amount of math in the documentation, ranging from
simple arithmetic expressions to complicated conditionals. For the most
part, math is marked up using LaTeX math notation, which is either passed
through to the Mathjax browser renderer for HTML outputs, or passed through
to LaTeX for PDF outputs. For some very simple math expressions, asciidoc
markup can be used.
[NOTE]
.Note
====
We still do not have the latexmath vs. asciidoc font situation sorted out
for all target output forms, so there can be some visual inconsistencies.
====
While LaTeX math macros, including the amsmath package, are supported,
general LaTeX constructs are not.
_Inline math_ is encoded using the latexmath{cl} macro. For example:
* latexmath:[$[0,1\]$]
* latexmath:[$x \cdot 0 = 0 \cdot x = 0$]
* latexmath:[${\textbf c} = t {\textbf c}_1 + (1-t){\textbf c}_2. $]
.Example Markup
----
latexmath:[$[0,1\]$]
latexmath:[$x \cdot 0 = 0 \cdot x = 0$]
latexmath:[${\textbf c} = t {\textbf c}_1 + (1-t){\textbf c}_2. $]
----
Note the escaped bracket in markup for the first expression, which is
necessary to work around asciidoc macro parsing:
_Block math_ is used for more complex equations. This example uses the
amsmath `align*` macros to delimit the expression:
[latexmath]
+++++++++++++++++++
\begin{align*}
c_{RGB} & =
\begin{cases}
\frac{c_{sRGB}}{12.92} & \textrm{for } c_{sRGB} \leq 0.04045 \\
\left ( \frac{c_{sRGB}+0.055}{1.055} \right )^{2.4} & \textrm{for } c_{sRGB} > 0.04045
\end{cases}
\end{align*}
+++++++++++++++++++
.Example Markup
----
[latexmath]
+++++++++++++++++++
\begin{align*}
c_{RGB} & =
\begin{cases}
\frac{c_{sRGB}}{12.92} & \textrm{for } c_{sRGB} \leq 0.04045 \\
\left ( \frac{c_{sRGB}+0.055}{1.055} \right )^{2.4} & \textrm{for } c_{sRGB} > 0.04045
\end{cases}
\end{align*}
+++++++++++++++++++
----
This example uses normal LaTeX math brackets to delimit the expression:
[latexmath]
+++++++++++++++++++
\[
V =
\begin{cases}
(-1)^S \times 0.0, & E = 0, M = 0 \\
(-1)^S \times 2^{-14} \times { M \over 2^{10} },
& E = 0, M \neq 0 \\
(-1)^S \times 2^{E-15} \times { \left( 1 + { M \over 2^{10} } \right) },
& 0 < E < 31 \\
(-1)^S \times Inf, & E = 31, M = 0 \\
NaN, & E = 31, M \neq 0
\end{cases}
\]
+++++++++++++++++++
.Example Markup
----
[latexmath]
+++++++++++++++++++
\[
V =
\begin{cases}
(-1)^S \times 0.0, & E = 0, M = 0 \\
(-1)^S \times 2^{-14} \times { M \over 2^{10} },
& E = 0, M \neq 0 \\
(-1)^S \times 2^{E-15} \times { \left( 1 + { M \over 2^{10} } \right) },
& 0 < E < 31 \\
(-1)^S \times Inf, & E = 31, M = 0 \\
NaN, & E = 31, M \neq 0
\end{cases}
\]
+++++++++++++++++++
----
[[writing-example]]
== An Example Command Description
The <<sample-command,next section>> is a sample based on the <<Vulkan API Specification>>,
and describes a command in enough detail to see the different usage patterns
and layout / markup used. Informative notes discussing markup and guidelines
are interspersed with the example description to explain how and why it
looks as it does.
[[sample-command]]
== Sample Command Description: Creating Command Pools
To create a command pool, call:
[NOTE]
.Guideline
====
Use a short, active sentence when describing what commands do, instead of
more passive phrasing like ``A command pool is created by calling:'' or ``The
application may create a command pool by calling:''.
====
include::../protos/vkCreateCommandPool.txt[]
[NOTE]
.Guideline
====
After the description, include the autogenerated prototype for the command
from the `../protos/` directory:
include::../protos/vkCreateCommandPool.txt[]
Note that each autogenerated command, enumeration, flag, or structure
definition include file also defines a corresponding asciidoc anchor which
is the base name of the file. In this case, the anchor is named
`vkCreateCommandPool`.
====
* pname:device is the logical device that the command pool is created on.
* pname:pCreateInfo points to an instance of the
slink:VkCommandPoolCreateInfo structure containing information used to
create the command pool.
* pname:pAllocator controls host memory allocation as described in the
<<memory-allocation, Memory Allocation>> chapter.
* pname:pCommandPool points to a handle in which the created command pool
object is returned.
[NOTE]
.Guideline
====
Each command parameter is described in a separate bullet list entry,
followed by validity rules, then detailed descriptions of any new
structures, flags, or enumerations introduced by this command.
Each parameter should appear as a separate bullet list item beginning with
the parameter name, in the same order as parameters appear in the command.
This aids in extracting short descriptions of parameters for inclusion in
annotated headers and similar documentation. Make sure to tag each parameter
with the pname{cl} macro.
Strive for compact notation, and in particular always try to use the
phrasing ``pname{cl}param _is_'' rather than wordier forms such as
``pname{cl}param _specifies_'' or ``The pname{cl}param parameter specifies''. In
general there is no need to describe a parameter which is a Vulkan object
handle *as* a handle; for example, say ``pname{cl}device is the logical
device'' rather than ``pname{cl}device is a handle to the logical device''. An
exception is object creation functions, where a pointer to a handle of the
proper type is used to return the newly created object.
====
include::../validity/protos/vkCreateCommandPool.txt[]
[NOTE]
.Guideline
====
Parameter and member validation language for commands and structures is also
autogenerated from vk.xml, and included from the `../validity/` directories:
include::../validity/protos/vkCreateCommandPool.txt[]
====
The sname:VkCommandPoolCreateInfo structure is defined as:
include::../structs/VkCommandPoolCreateInfo.txt[]
[NOTE]
.Guideline
====
Structures and enumerations first used as parameters of a command are
described next, by including the autogenerated interface file for that
structure or enumeration:
include::../structs/VkCommandPoolCreateInfo.txt[]
====
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags is a combination of bitmask flags indicating usage behavior
for the pool and command buffers allocated from it. Possible values
include:
+
--
include::../enums/VkCommandPoolCreateFlagBits.txt[]
** ename:VK_COMMAND_POOL_CREATE_TRANSIENT_BIT indicates that command buffers
allocated from the pool will be short-lived.
** ename:VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT controls whether
command buffers allocated from the pool can: be individually reset.
--
* pname:queueFamilyIndex designates a queue family. Command buffers in
this command pool must: be submitted on queues from the same family.
[NOTE]
.Guideline
====
Each structure member is described in a separate bullet list entry. For the
stext:Vk*CreateInfo structures in particular, there is standard boilerplate
for the pname:sType and pname:pNext members, followed by the members
specific to the structure.
----
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an
extension-specific structure.
----
In some cases, such as when the type of a member is itself a new type, the
entry will cover multiple paragraphs. In these cases the normal list nesting
and indentation guidelines cannot be applied due to limitations of the
asciidoc parser. It is usually best to append a block following the first
paragraph of such a list item:
----
* pname:flags is a combination of bitmask flags
indicating usage behavior for the pool and
command buffers allocated from it. Possible
values include:
+
--
\include::../enums/VkCommandPoolCreateFlagBits.txt[]
** ename:VK_COMMAND_POOL_CREATE_TRANSIENT_BIT
indicates that command buffers allocated
from the pool will be short-lived.
** ename:VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT
controls whether command buffers allocated from
the pool can: be individually reset.
--
----
====
include::../validity/structs/VkCommandPoolCreateInfo.txt[]
[NOTE]
.Guideline
====
Following the definition of structure members, include the validity language
for this structure:
include::../validity/structs/VkCommandPoolCreateInfo.txt[]
====

182
doc/specs/vulkan/styleguide.txt Normal file
View File

@ -0,0 +1,182 @@
// Copyright (c) 2014-2016 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
Vulkan Documentation and Extensions: Procedures and Conventions
===============================================================
Jon Leech, Tobias Hector
include::specversion.txt[]
:toc2:
:toclevels: 3
:max-width: 100
:numbered:
:doctype: book
:imagewidth: 800
:fullimagewidth: {svgpdf@pdf:scaledwidth="75%":width="800"}
:cl: &#x3a;
:leveloffset: 1
// :icons:
// :toc-placement: manual
<<<<
include::copyright-ccby.txt[]
<<<<
[[introduction]]
= Introduction
This document contains required procedures and conventions when writing specifications for
new Vulkan APIs, extensions and layers, or related Khronos documentation
such as white papers and tutorials; or contributing to existing Vulkan
specifications. These are collectively referred to as _Vulkan Documentation_
or just _documentation_ below. The primary focus is the API Specification
and API extensions, although all of the markup and most of the writing style
is equally applicable to other documentation.
The primary purpose is to achieve consistency across the
API, as well as across all of our source and output documents. Consistency
makes it easier for developers, editors, reviewers, and users
of our documentation to understand and modify it.
This document is now formally voted on and approved
by the Vulkan Working Group. This means that unless explicitly stated
otherwise, the procedures and conventions must be followed
If you have a strong desire to modify the procedures and conventions,
such changes must be made through the normal
Vulkan Working Group processes.
[[introduction-terminology]]
== Terminology
The key words *must*, *must not*, *required*, *shall*, *shall not*,
*should*, *should not*, *recommend*, *may*, and *optional* in this document
are to be interpreted as described in RFC 2119 and by the
Vulkan 1.0 Specification in the ``Terminology'' section.
[[introduction-structure]]
== Document Structure
The style guide is broken into four sections:
* <<naming,API Naming Conventions>> - the required rules for choosing names
of Vulkan identifiers of all types.
* <<extensions,Extensions and Layers>> - the required procedures
for creating formal Vulkan extensions and layers.
* <<markup,Markup Style>> - the required and recommended markup style for
writing asciidoc and XML source that
follows consistent formatting and layout guidelines, tags special terms
and phrases for proper processing by the spec generation tools, etc.
* <<writing,Writing Style>> - the required and recommended writing style
for overall and fine-grained structure and
conventions, normative language use, API naming conventions, common
words and phrases to use and to avoid, linking and
cross-referencing, etc.
[[introduction-asciidoc]]
== Asciidoc Markup
Vulkan Documentation is primarily written in Asciidoc, a form of text markup
language. Asciidoc is documented on its website at http://www.asciidoc.org/.
[[userguide]]
References to the Asciidoc User Guide are to sections in the document at
http://asciidoc.org/userguide.html .
Asciidoc packages are available for Linux, MacOS, and Microsoft Windows,
together with the other toolchain components required to generate output
documents corresponding to the markup.
[NOTE]
.Note
====
We are currently using the
original _asciidoc_ tool. Other tools to process Asciidoc markup, such as
_asciidoctor_, are also available, but are not currently usable for our
documents. While asciidoctor supports the basic Asciidoc markup syntax, it
does not support asciidoc macros, which are used extensively in the
documentation. We expect to transition from asciidoc to asciidoctor
eventually. There may be minor effects on markup and if so, we will
document them at the time of the transition.
====
The asciidoc toolchain and build process are not addressed by this
document, which concentrates solely on source documents.
[[introduction-normative]]
== Normative References
Normative references are references to external documents or resources to
which documentation authors must comply.
[[KhronosGroup/Vulkan-Docs]]:: Khronos Vulkan Working Group,
+KhronosGroup/Vulkan-Docs+ project on Github,
https://github.com/KhronosGroup/Vulkan-Docs,
July 5, 2016.
[[Vulkan API Specification]]:: Vulkan Working Group,
_Vulkan 1.0.19 - A Specification_,
https://www.khronos.org/registry/vulkan/,
July 1, 2016.
Version 1.0.19 is the latest patch release of the Vulkan API Specification as of the
time this reference was created, but that Specification is frequently
updated with minor bugfixes and clarifications. When a more recent patch
release is made, it becomes the normative reference for the API.
// Chapters of the text are included below
include::style/naming.txt[]
include::style/extensions.txt[]
include::style/markup.txt[]
include::style/writing.txt[]
= Still To Be Done
* Something about Image formats
* Something about validation scripts
* Something about pictures
* Glossary lists
* New param/enum macros
= Revision History
* July 11, 2016 - Change the document title.
* July 7, 2016 - Rename document, change license to CC BY, clarify required
and recommended actions, and reserve use of ``normative'' for the
Specifications.
* June 26, 2016 - Move Layers and Extensions chapter from Appendix C of the
Vulkan API Specification and merge content with the naming guide. Put
extension and naming chapters into their own source files.
* June 20, 2016 - Add API naming guide.
* May 22, 2016 - Add markup and image creation rules, after fixing missing
figure captions for public Github issue 219.
* May 1, 2016 - Include feedback from public Github issues 120 and 190. Use
consistent conventions for defining structures. Use American rather than
British spelling conventions.
* March 12, 2016 - Recommend against "the value of".
* February 26, 2016 - Replace use of the "maynot{cl}" macro with "may{cl} not".
* February 16, 2016 - Place asciidoc conversion post-release.
* February 9, 2016 - Added quotation mark convention.
* February 1, 2016 - add the Oxford Comma section and issue resolution.
* January 26, 2016 - add bullet-list style description of command parameters.
* January 11, 2016 - add ``Numbers in Text'' section from WSI work.
* December 16, 2015 - Make ``begin / end'' preferred terms to ``start /
finish''.
* December 15, 2015 - Make ``implementation'' preferred term instead of
``system''.
* December 13, 2015 - Add tlink{cl}/tname{cl} macros for function pointer
types.
* December 10, 2015 - Initial release for feedback.

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

@ -21,7 +21,7 @@ endif::doctype-manpage[]
* Each of pname:commandBuffer, pname:srcImage and pname:dstImage must: have been created, allocated or retrieved from the same sname:VkDevice
* The source region specified by a given element of pname:pRegions must: be a region that is contained within pname:srcImage
* The destination region specified by a given element of pname:pRegions must: be a region that is contained within pname:dstImage
* The union of all source regions, and the union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory
* The union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory with any texel that may: be sampled during the blit operation
* pname:srcImage must: use a format that supports ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT, which is indicated by sname:VkFormatProperties::pname:linearTilingFeatures (for linear tiled images) or sname:VkFormatProperties::pname:optimalTilingFeatures (for optimally tiled images) - as returned by fname:vkGetPhysicalDeviceFormatProperties
* pname:srcImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag
* pname:srcImageLayout must: specify the layout of the image subresources of pname:srcImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice
@ -35,6 +35,8 @@ 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
* pname:srcImage must: have been created with a pname:samples value of ename:VK_SAMPLE_COUNT_1_BIT
* pname:dstImage must: have been created with a pname:samples value of ename:VK_SAMPLE_COUNT_1_BIT
* 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[]
********************************************************************************

6
doc/specs/vulkan/validity/protos/vkGetPhysicalDeviceSparseImageFormatProperties.txt
View File

@ -16,11 +16,7 @@ endif::doctype-manpage[]
* pname:tiling must: be a valid elink:VkImageTiling value
* pname:pPropertyCount must: be a pointer to a basetype:uint32_t value
* If the value referenced by pname:pPropertyCount is not `0`, and pname:pProperties is not `NULL`, pname:pProperties must: be a pointer to an array of pname:pPropertyCount sname:VkSparseImageFormatProperties structures
* If pname:format is an integer format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageIntegerSampleCounts
* If pname:format is a non-integer color format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageColorSampleCounts
* If pname:format is a depth format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageDepthSampleCounts
* If pname:format is a stencil format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageStencilSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_STORAGE_BIT, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:storageImageSampleCounts
* pname:samples must: be a bit value that is set in sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, and pname:usage equal to those in this command and pname:flags equal to the value that is set in sname::VkImageCreateInfo::pname::flags when the image is created
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

9
doc/specs/vulkan/validity/structs/VkGraphicsPipelineCreateInfo.txt
View File

@ -30,11 +30,12 @@ endif::doctype-manpage[]
* If pname:pStages includes a tessellation control shader stage, it must: include a tessellation evaluation shader stage
* If pname:pStages includes a tessellation evaluation shader stage, it must: include a tessellation control shader stage
* If pname:pStages includes a tessellation control shader stage and a tessellation evaluation shader stage, pname:pTessellationState mustnot: be `NULL`
* If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, the shader code of at least one must: contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline
* If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, and the shader code of both contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline, they must: both specify the same subdivision mode
* If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, the shader code of at least one must: contain an code:OpExecutionMode instruction that specifies the output patch size in the pipeline
* If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, and the shader code of both contain an code:OpExecutionMode instruction that specifies the out patch size in the pipeline, they must: both specify the same patch size
* If pname:pStages includes tessellation shader stages, the shader code of at least one stage must: contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline
* If pname:pStages includes tessellation shader stages, and the shader code of both stages contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline, they must: both specify the same subdivision mode
* If pname:pStages includes tessellation shader stages, the shader code of at least one stage must: contain an code:OpExecutionMode instruction that specifies the output patch size in the pipeline
* If pname:pStages includes tessellation shader stages, and the shader code of both contain an code:OpExecutionMode instruction that specifies the out patch size in the pipeline, they must: both specify the same patch size
* If pname:pStages includes tessellation shader stages, the pname:topology member of pname:pInputAssembly must: be ename:VK_PRIMITIVE_TOPOLOGY_PATCH_LIST
* If the pname:topology member of pname:pInputAssembly is ename:VK_PRIMITIVE_TOPOLOGY_PATCH_LIST, pname:pStages must: include tessellation shader stages
* If pname:pStages includes a geometry shader stage, and does not include any tessellation shader stages, its shader code must: contain an code:OpExecutionMode instruction that specifies an input primitive type that is <<shaders-geometry-execution, compatible>> with the primitive topology specified in pname:pInputAssembly
* If pname:pStages includes a geometry shader stage, and also includes tessellation shader stages, its shader code must: contain an code:OpExecutionMode instruction that specifies an input primitive type that is <<shaders-geometry-execution, compatible>> with the primitive topology that is output by the tessellation stages
* If pname:pStages includes a fragment shader stage and a geometry shader stage, and the fragment shader code reads from an input variable that is decorated with code:PrimitiveID, then the geometry shader code must: write to a matching output variable, decorated with code:PrimitiveID, in all execution paths

1
doc/specs/vulkan/validity/structs/VkImageBlit.txt
View File

@ -14,6 +14,7 @@ endif::doctype-manpage[]
* If either of the calling command's pname:srcImage or pname:dstImage parameters are of elink:VkImageType ename:VK_IMAGE_TYPE_3D, the pname:baseArrayLayer and pname:layerCount members of both pname:srcSubresource and pname:dstSubresource must: be `0` and `1`, respectively
* The pname:aspectMask member of pname:srcSubresource must: specify aspects present in the calling command's pname:srcImage
* The pname:aspectMask member of pname:dstSubresource must: specify aspects present in the calling command's pname:dstImage
* The pname:layerCount member of pname:dstSubresource must: be equal to the pname:layerCount member of pname:srcSubresource
* pname:srcOffset[0].x and pname:srcOffset[1].x must: both be greater than or equal to `0` and less than or equal to the source image subresource width
* pname:srcOffset[0].y and pname:srcOffset[1].y must: both be greater than or equal to `0` and less than or equal to the source image subresource height
* pname:srcOffset[0].z and pname:srcOffset[1].z must: both be greater than or equal to `0` and less than or equal to the source image subresource depth

9
doc/specs/vulkan/validity/structs/VkImageCreateInfo.txt
View File

@ -34,16 +34,9 @@ endif::doctype-manpage[]
* pname:mipLevels must: be less than or equal to latexmath:[$\lfloor\log_2(\max(\mathit{extent.width}, \mathit{extent.height}, \mathit{extent.depth}))\rfloor + 1$]
* If any of pname:extent.width, pname:extent.height or pname:extent.depth are greater than the equivalently named members of sname:VkPhysicalDeviceLimits::pname:maxImageDimension3D, pname:mipLevels must: be less than or equal to sname:VkImageFormatProperties::pname:maxMipLevels (as returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure)
* pname:arrayLayers must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxImageArrayLayers, or sname:VkImageFormatProperties::pname:maxArrayLayers (as returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure) - whichever is higher
* pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampleCounts returned by flink:vkGetPhysicalDeviceProperties, or sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure
* If pname:usage includes ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT or ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT, pname:extent.width must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxFramebufferWidth
* If pname:usage includes ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT or ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT, pname:extent.height must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxFramebufferHeight
* If pname:usage includes ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:framebufferColorSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, and pname:format includes a depth aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:framebufferDepthSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, and pname:format includes a stencil aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:framebufferStencilSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format includes a color aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampledImageColorSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format includes a depth aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampledImageDepthSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format is an integer format, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampledImageIntegerSampleCounts
* If pname:usage includes ename:VK_IMAGE_USAGE_STORAGE_BIT, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:storageImageSampleCounts
* pname:samples must: be a bit value that is set in sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure
* If the <<features-features-textureCompressionETC2,ETC2 texture compression>> feature is not enabled, pname:format mustnot: be ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK, ename:VK_FORMAT_EAC_R11_UNORM_BLOCK, ename:VK_FORMAT_EAC_R11_SNORM_BLOCK, ename:VK_FORMAT_EAC_R11G11_UNORM_BLOCK, or ename:VK_FORMAT_EAC_R11G11_SNORM_BLOCK
* If the <<features-features-textureCompressionASTC_LDR,ASTC LDR texture compression>> feature is not enabled, pname:format mustnot: be ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK, ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK, ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK, ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK, ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK, ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK, ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK, ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK, ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK, ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK, ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK, ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK, ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK, or ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK
* If the <<features-features-textureCompressionBC,BC texture compression>> feature is not enabled, pname:format mustnot: be ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK, ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK, ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK, ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK, ename:VK_FORMAT_BC2_UNORM_BLOCK, ename:VK_FORMAT_BC2_SRGB_BLOCK, ename:VK_FORMAT_BC3_UNORM_BLOCK, ename:VK_FORMAT_BC3_SRGB_BLOCK, ename:VK_FORMAT_BC4_UNORM_BLOCK, ename:VK_FORMAT_BC4_SNORM_BLOCK, ename:VK_FORMAT_BC5_UNORM_BLOCK, ename:VK_FORMAT_BC5_SNORM_BLOCK, ename:VK_FORMAT_BC6H_UFLOAT_BLOCK, ename:VK_FORMAT_BC6H_SFLOAT_BLOCK, ename:VK_FORMAT_BC7_UNORM_BLOCK, or ename:VK_FORMAT_BC7_SRGB_BLOCK

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

@ -1411,390 +1411,390 @@ mapDict['PFN_vkInternalAllocationNotification'] = {'VkAllocationCallbacks': Non
mapDict['PFN_vkInternalFreeNotification'] = {'VkAllocationCallbacks': None}
mapDict['PFN_vkReallocationFunction'] = {'VkAllocationCallbacks': None}
mapDict['VkAccessFlagBits'] = {'VkAccessFlags': None}
mapDict['VkAccessFlags'] = {'VkBufferMemoryBarrier': None, 'VkImageMemoryBarrier': None, 'VkSubpassDependency': None, 'VkMemoryBarrier': None, 'VkAccessFlagBits': None}
mapDict['VkAllocationCallbacks'] = {'vkDestroyCommandPool': None, 'vkCreateFence': None, 'vkCreatePipelineCache': None, 'vkCreatePipelineLayout': None, 'vkDestroyShaderModule': None, 'vkDestroyFence': None, 'vkCreateEvent': None, 'vkDestroyBuffer': None, 'vkDestroyPipelineLayout': None, 'PFN_vkInternalFreeNotification': None, 'vkDestroyDevice': None, 'vkCreateImageView': None, 'vkCreateCommandPool': None, 'vkDestroySampler': None, 'vkCreateShaderModule': None, 'vkDestroyRenderPass': None, 'vkDestroyImageView': None, 'vkCreateSampler': None, 'vkCreateBufferView': None, 'vkDestroySemaphore': None, 'PFN_vkReallocationFunction': None, 'vkAllocateMemory': None, 'vkCreateDescriptorSetLayout': None, 'vkDestroyEvent': None, 'vkCreateDevice': None, 'vkDestroyQueryPool': None, 'vkDestroyDescriptorPool': None, 'vkCreateComputePipelines': None, 'vkCreateImage': None, 'vkDestroyDescriptorSetLayout': None, 'PFN_vkFreeFunction': None, 'vkCreateDescriptorPool': None, 'vkCreateSemaphore': None, 'vkDestroyInstance': None, 'PFN_vkInternalAllocationNotification': None, 'vkCreateGraphicsPipelines': None, 'vkDestroyFramebuffer': None, 'vkDestroyPipelineCache': None, 'vkCreateQueryPool': None, 'vkFreeMemory': None, 'vkDestroyPipeline': None, 'vkCreateFramebuffer': None, 'vkDestroyImage': None, 'vkCreateInstance': None, 'PFN_vkAllocationFunction': None, 'vkDestroyBufferView': None, 'vkCreateRenderPass': None, 'vkCreateBuffer': None}
mapDict['VkApplicationInfo'] = {'VkStructureType': None, 'VkInstanceCreateInfo': None}
mapDict['VkAttachmentDescription'] = {'VkFormat': None, 'VkSampleCountFlagBits': None, 'VkAttachmentStoreOp': None, 'VkRenderPassCreateInfo': None, 'VkAttachmentDescriptionFlags': None, 'VkImageLayout': None, 'VkAttachmentLoadOp': None}
mapDict['VkAccessFlags'] = {'VkBufferMemoryBarrier': None, 'VkSubpassDependency': None, 'VkImageMemoryBarrier': None, 'VkMemoryBarrier': None, 'VkAccessFlagBits': None}
mapDict['VkAllocationCallbacks'] = {'vkCreateFramebuffer': None, 'PFN_vkAllocationFunction': None, 'vkFreeMemory': None, 'PFN_vkFreeFunction': None, 'vkDestroyShaderModule': None, 'vkDestroyQueryPool': None, 'vkDestroyEvent': None, 'PFN_vkInternalFreeNotification': None, 'PFN_vkInternalAllocationNotification': None, 'vkDestroyPipelineCache': None, 'vkCreateBuffer': None, 'vkCreateSampler': None, 'PFN_vkReallocationFunction': None, 'vkDestroyCommandPool': None, 'vkCreateDevice': None, 'vkDestroyDescriptorPool': None, 'vkDestroyFramebuffer': None, 'vkCreateFence': None, 'vkCreateImage': None, 'vkDestroyInstance': None, 'vkCreatePipelineCache': None, 'vkDestroySampler': None, 'vkAllocateMemory': None, 'vkCreateGraphicsPipelines': None, 'vkCreateCommandPool': None, 'vkCreateSemaphore': None, 'vkDestroyDescriptorSetLayout': None, 'vkCreateBufferView': None, 'vkCreateImageView': None, 'vkDestroyImageView': None, 'vkDestroyBufferView': None, 'vkDestroyRenderPass': None, 'vkDestroyFence': None, 'vkCreateEvent': None, 'vkDestroyImage': None, 'vkDestroyPipelineLayout': None, 'vkCreateRenderPass': None, 'vkDestroySemaphore': None, 'vkDestroyBuffer': None, 'vkCreateDescriptorPool': None, 'vkCreateComputePipelines': None, 'vkCreateShaderModule': None, 'vkDestroyPipeline': None, 'vkDestroyDevice': None, 'vkCreatePipelineLayout': None, 'vkCreateDescriptorSetLayout': None, 'vkCreateInstance': None, 'vkCreateQueryPool': None}
mapDict['VkApplicationInfo'] = {'VkInstanceCreateInfo': None, 'VkStructureType': None}
mapDict['VkAttachmentDescription'] = {'VkImageLayout': None, 'VkAttachmentLoadOp': None, 'VkFormat': None, 'VkAttachmentDescriptionFlags': None, 'VkRenderPassCreateInfo': None, 'VkSampleCountFlagBits': None, 'VkAttachmentStoreOp': None}
mapDict['VkAttachmentDescriptionFlagBits'] = {'VkAttachmentDescriptionFlags': None}
mapDict['VkAttachmentDescriptionFlags'] = {'VkAttachmentDescription': None, 'VkAttachmentDescriptionFlagBits': None}
mapDict['VkAttachmentLoadOp'] = {'VkAttachmentDescription': None}
mapDict['VkAttachmentReference'] = {'VkImageLayout': None, 'VkSubpassDescription': None}
mapDict['VkAttachmentStoreOp'] = {'VkAttachmentDescription': None}
mapDict['VkBindSparseInfo'] = {'VkSparseImageMemoryBindInfo': None, 'VkSemaphore': None, 'VkSparseBufferMemoryBindInfo': None, 'VkStructureType': None, 'VkSparseImageOpaqueMemoryBindInfo': None, 'vkQueueBindSparse': None}
mapDict['VkBindSparseInfo'] = {'VkSparseImageMemoryBindInfo': None, 'VkSparseImageOpaqueMemoryBindInfo': None, 'VkStructureType': None, 'vkQueueBindSparse': None, 'VkSemaphore': None, 'VkSparseBufferMemoryBindInfo': None}
mapDict['VkBlendFactor'] = {'VkPipelineColorBlendAttachmentState': None}
mapDict['VkBlendOp'] = {'VkPipelineColorBlendAttachmentState': None}
mapDict['VkBool32'] = {'VkPhysicalDeviceLimits': None, 'VkPipelineColorBlendStateCreateInfo': None, 'VkPipelineMultisampleStateCreateInfo': None, 'VkPhysicalDeviceFeatures': None, 'VkPipelineColorBlendAttachmentState': None, 'VkPipelineInputAssemblyStateCreateInfo': None, 'VkPipelineRasterizationStateCreateInfo': None, 'vkWaitForFences': None, 'VkPhysicalDeviceSparseProperties': None, 'VkSamplerCreateInfo': None, 'VkCommandBufferInheritanceInfo': None, 'VkPipelineDepthStencilStateCreateInfo': None}
mapDict['VkBool32'] = {'VkPipelineRasterizationStateCreateInfo': None, 'VkPipelineInputAssemblyStateCreateInfo': None, 'VkPhysicalDeviceFeatures': None, 'VkPipelineMultisampleStateCreateInfo': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkPipelineColorBlendStateCreateInfo': None, 'VkPhysicalDeviceLimits': None, 'VkPipelineColorBlendAttachmentState': None, 'VkSamplerCreateInfo': None, 'VkCommandBufferInheritanceInfo': None, 'VkPhysicalDeviceSparseProperties': None, 'vkWaitForFences': None}
mapDict['VkBorderColor'] = {'VkSamplerCreateInfo': None}
mapDict['VkBuffer'] = {'vkCmdBindVertexBuffers': None, 'VkBufferMemoryBarrier': None, 'vkDestroyBuffer': None, 'VkSparseBufferMemoryBindInfo': None, 'vkCmdCopyImageToBuffer': None, 'vkBindBufferMemory': None, 'vkCmdDrawIndexedIndirect': None, 'vkCmdCopyQueryPoolResults': None, 'VkBufferViewCreateInfo': None, 'vkCmdFillBuffer': None, 'vkGetBufferMemoryRequirements': None, 'vkCmdBindIndexBuffer': None, 'VkDescriptorBufferInfo': None, 'vkCmdCopyBufferToImage': None, 'vkCmdUpdateBuffer': None, 'vkCmdDispatchIndirect': None, 'vkCmdDrawIndirect': None, 'vkCmdCopyBuffer': None, 'vkCreateBuffer': None}
mapDict['VkBuffer'] = {'vkCmdFillBuffer': None, 'vkCmdDrawIndexedIndirect': None, 'vkBindBufferMemory': None, 'vkGetBufferMemoryRequirements': None, 'VkBufferMemoryBarrier': None, 'vkCmdCopyBuffer': None, 'vkCmdDrawIndirect': None, 'vkCmdCopyImageToBuffer': None, 'vkDestroyBuffer': None, 'vkCmdBindIndexBuffer': None, 'VkDescriptorBufferInfo': None, 'vkCmdDispatchIndirect': None, 'vkCmdCopyBufferToImage': None, 'vkCmdBindVertexBuffers': None, 'vkCmdUpdateBuffer': None, 'VkBufferViewCreateInfo': None, 'vkCreateBuffer': None, 'vkCmdCopyQueryPoolResults': None, 'VkSparseBufferMemoryBindInfo': None}
mapDict['VkBufferCopy'] = {'vkCmdCopyBuffer': None, 'VkDeviceSize': None}
mapDict['VkBufferCreateFlagBits'] = {'VkBufferCreateFlags': None}
mapDict['VkBufferCreateFlags'] = {'VkBufferCreateFlagBits': None, 'VkBufferCreateInfo': None}
mapDict['VkBufferCreateInfo'] = {'VkBufferCreateFlags': None, 'vkCreateBuffer': None, 'VkStructureType': None, 'VkSharingMode': None, 'VkDeviceSize': None, 'VkBufferUsageFlags': None}
mapDict['VkBufferImageCopy'] = {'vkCmdCopyImageToBuffer': None, 'vkCmdCopyBufferToImage': None, 'VkImageSubresourceLayers': None, 'VkOffset3D': None, 'VkDeviceSize': None, 'VkExtent3D': None}
mapDict['VkBufferMemoryBarrier'] = {'VkBuffer': None, 'VkAccessFlags': None, 'vkCmdWaitEvents': None, 'vkCmdPipelineBarrier': None, 'VkStructureType': None, 'VkDeviceSize': None}
mapDict['VkBufferCreateFlags'] = {'VkBufferCreateInfo': None, 'VkBufferCreateFlagBits': None}
mapDict['VkBufferCreateInfo'] = {'VkBufferCreateFlags': None, 'VkDeviceSize': None, 'vkCreateBuffer': None, 'VkSharingMode': None, 'VkStructureType': None, 'VkBufferUsageFlags': None}
mapDict['VkBufferImageCopy'] = {'VkDeviceSize': None, 'VkOffset3D': None, 'vkCmdCopyBufferToImage': None, 'VkExtent3D': None, 'VkImageSubresourceLayers': None, 'vkCmdCopyImageToBuffer': None}
mapDict['VkBufferMemoryBarrier'] = {'vkCmdWaitEvents': None, 'VkAccessFlags': None, 'VkDeviceSize': None, 'VkStructureType': None, 'vkCmdPipelineBarrier': None, 'VkBuffer': None}
mapDict['VkBufferUsageFlagBits'] = {'VkBufferUsageFlags': None}
mapDict['VkBufferUsageFlags'] = {'VkBufferUsageFlagBits': None, 'VkBufferCreateInfo': None}
mapDict['VkBufferView'] = {'vkCreateBufferView': None, 'vkDestroyBufferView': None, 'VkWriteDescriptorSet': None}
mapDict['VkBufferView'] = {'vkDestroyBufferView': None, 'vkCreateBufferView': None, 'VkWriteDescriptorSet': None}
mapDict['VkBufferViewCreateFlags'] = {'VkBufferViewCreateInfo': None}
mapDict['VkBufferViewCreateInfo'] = {'VkBuffer': None, 'vkCreateBufferView': None, 'VkFormat': None, 'VkStructureType': None, 'VkBufferViewCreateFlags': None, 'VkDeviceSize': None}
mapDict['VkClearAttachment'] = {'VkImageAspectFlags': None, 'VkClearValue': None, 'vkCmdClearAttachments': None}
mapDict['VkClearColorValue'] = {'vkCmdClearColorImage': None, 'VkClearValue': None}
mapDict['VkClearDepthStencilValue'] = {'vkCmdClearDepthStencilImage': None, 'VkClearValue': None}
mapDict['VkBufferViewCreateInfo'] = {'vkCreateBufferView': None, 'VkDeviceSize': None, 'VkFormat': None, 'VkStructureType': None, 'VkBufferViewCreateFlags': None, 'VkBuffer': None}
mapDict['VkClearAttachment'] = {'VkClearValue': None, 'VkImageAspectFlags': None, 'vkCmdClearAttachments': None}
mapDict['VkClearColorValue'] = {'VkClearValue': None, 'vkCmdClearColorImage': None}
mapDict['VkClearDepthStencilValue'] = {'VkClearValue': None, 'vkCmdClearDepthStencilImage': None}
mapDict['VkClearRect'] = {'VkRect2D': None, 'vkCmdClearAttachments': None}
mapDict['VkClearValue'] = {'VkClearColorValue': None, 'VkClearAttachment': None, 'VkClearDepthStencilValue': None, 'VkRenderPassBeginInfo': None}
mapDict['VkClearValue'] = {'VkClearDepthStencilValue': None, 'VkClearAttachment': None, 'VkClearColorValue': None, 'VkRenderPassBeginInfo': None}
mapDict['VkColorComponentFlagBits'] = {'VkColorComponentFlags': None}
mapDict['VkColorComponentFlags'] = {'VkPipelineColorBlendAttachmentState': None, 'VkColorComponentFlagBits': None}
mapDict['VkCommandBuffer'] = {'vkCmdClearColorImage': None, 'vkCmdCopyBuffer': None, 'vkCmdDrawIndexed': None, 'vkCmdNextSubpass': None, 'vkCmdSetScissor': None, 'vkCmdCopyQueryPoolResults': None, 'vkCmdClearAttachments': None, 'vkCmdBindPipeline': None, 'vkCmdSetLineWidth': None, 'vkCmdDrawIndexedIndirect': None, 'vkCmdDispatchIndirect': None, 'vkCmdResetQueryPool': None, 'vkCmdWaitEvents': None, 'vkFreeCommandBuffers': None, 'vkCmdResolveImage': None, 'vkCmdDraw': None, 'vkCmdClearDepthStencilImage': None, 'vkCmdDrawIndirect': None, 'vkCmdSetBlendConstants': None, 'vkBeginCommandBuffer': None, 'vkCmdCopyBufferToImage': None, 'vkCmdPushConstants': None, 'VkSubmitInfo': None, 'vkCmdDispatch': None, 'vkCmdSetDepthBias': None, 'vkCmdSetViewport': None, 'vkCmdBindVertexBuffers': None, 'vkCmdExecuteCommands': None, 'vkCmdPipelineBarrier': None, 'vkCmdBindDescriptorSets': None, 'vkCmdCopyImageToBuffer': None, 'vkCmdSetStencilReference': None, 'vkCmdUpdateBuffer': None, 'vkCmdFillBuffer': None, 'vkEndCommandBuffer': None, 'vkResetCommandBuffer': None, 'vkCmdResetEvent': None, 'vkCmdWriteTimestamp': None, 'vkCmdSetEvent': None, 'vkCmdBeginQuery': None, 'vkCmdEndQuery': None, 'vkCmdSetStencilCompareMask': None, 'vkCmdBeginRenderPass': None, 'vkCmdSetStencilWriteMask': None, 'vkCmdEndRenderPass': None, 'vkAllocateCommandBuffers': None, 'vkCmdBindIndexBuffer': None, 'vkCmdCopyImage': None, 'vkCmdBlitImage': None, 'vkCmdSetDepthBounds': None}
mapDict['VkCommandBufferAllocateInfo'] = {'VkStructureType': None, 'vkAllocateCommandBuffers': None, 'VkCommandBufferLevel': None, 'VkCommandPool': None}
mapDict['VkCommandBufferBeginInfo'] = {'vkBeginCommandBuffer': None, 'VkStructureType': None, 'VkCommandBufferInheritanceInfo': None, 'VkCommandBufferUsageFlags': None}
mapDict['VkCommandBufferInheritanceInfo'] = {'VkCommandBufferBeginInfo': None, 'VkQueryControlFlags': None, 'VkFramebuffer': None, 'VkStructureType': None, 'VkRenderPass': None, 'VkBool32': None, 'VkQueryPipelineStatisticFlags': None}
mapDict['VkColorComponentFlags'] = {'VkColorComponentFlagBits': None, 'VkPipelineColorBlendAttachmentState': None}
mapDict['VkCommandBuffer'] = {'vkAllocateCommandBuffers': None, 'vkCmdBeginRenderPass': None, 'vkCmdBindPipeline': None, 'vkCmdCopyBuffer': None, 'vkEndCommandBuffer': None, 'vkCmdWaitEvents': None, 'vkFreeCommandBuffers': None, 'vkCmdEndQuery': None, 'vkCmdUpdateBuffer': None, 'vkCmdSetViewport': None, 'vkCmdResetEvent': None, 'VkSubmitInfo': None, 'vkCmdBlitImage': None, 'vkCmdSetBlendConstants': None, 'vkCmdCopyImageToBuffer': None, 'vkCmdSetDepthBias': None, 'vkCmdDispatch': None, 'vkCmdWriteTimestamp': None, 'vkCmdBindIndexBuffer': None, 'vkCmdSetDepthBounds': None, 'vkResetCommandBuffer': None, 'vkCmdSetLineWidth': None, 'vkCmdNextSubpass': None, 'vkCmdSetStencilWriteMask': None, 'vkCmdDrawIndirect': None, 'vkCmdCopyBufferToImage': None, 'vkCmdClearAttachments': None, 'vkCmdDrawIndexed': None, 'vkCmdClearColorImage': None, 'vkCmdBindVertexBuffers': None, 'vkCmdSetStencilCompareMask': None, 'vkCmdResetQueryPool': None, 'vkCmdDraw': None, 'vkCmdPushConstants': None, 'vkCmdDrawIndexedIndirect': None, 'vkCmdBindDescriptorSets': None, 'vkCmdFillBuffer': None, 'vkCmdPipelineBarrier': None, 'vkBeginCommandBuffer': None, 'vkCmdSetScissor': None, 'vkCmdExecuteCommands': None, 'vkCmdCopyImage': None, 'vkCmdSetStencilReference': None, 'vkCmdDispatchIndirect': None, 'vkCmdResolveImage': None, 'vkCmdBeginQuery': None, 'vkCmdEndRenderPass': None, 'vkCmdClearDepthStencilImage': None, 'vkCmdCopyQueryPoolResults': None, 'vkCmdSetEvent': None}
mapDict['VkCommandBufferAllocateInfo'] = {'vkAllocateCommandBuffers': None, 'VkCommandPool': None, 'VkStructureType': None, 'VkCommandBufferLevel': None}
mapDict['VkCommandBufferBeginInfo'] = {'VkStructureType': None, 'vkBeginCommandBuffer': None, 'VkCommandBufferUsageFlags': None, 'VkCommandBufferInheritanceInfo': None}
mapDict['VkCommandBufferInheritanceInfo'] = {'VkFramebuffer': None, 'VkQueryPipelineStatisticFlags': None, 'VkBool32': None, 'VkCommandBufferBeginInfo': None, 'VkQueryControlFlags': None, 'VkStructureType': None, 'VkRenderPass': None}
mapDict['VkCommandBufferLevel'] = {'VkCommandBufferAllocateInfo': None}
mapDict['VkCommandBufferResetFlagBits'] = {'VkCommandBufferResetFlags': None}
mapDict['VkCommandBufferResetFlags'] = {'vkResetCommandBuffer': None, 'VkCommandBufferResetFlagBits': None}
mapDict['VkCommandBufferUsageFlagBits'] = {'VkCommandBufferUsageFlags': None}
mapDict['VkCommandBufferUsageFlags'] = {'VkCommandBufferUsageFlagBits': None, 'VkCommandBufferBeginInfo': None}
mapDict['VkCommandPool'] = {'vkCreateCommandPool': None, 'vkDestroyCommandPool': None, 'vkResetCommandPool': None, 'VkCommandBufferAllocateInfo': None, 'vkFreeCommandBuffers': None}
mapDict['VkCommandPool'] = {'vkDestroyCommandPool': None, 'vkCreateCommandPool': None, 'VkCommandBufferAllocateInfo': None, 'vkFreeCommandBuffers': None, 'vkResetCommandPool': None}
mapDict['VkCommandPoolCreateFlagBits'] = {'VkCommandPoolCreateFlags': None}
mapDict['VkCommandPoolCreateFlags'] = {'VkCommandPoolCreateFlagBits': None, 'VkCommandPoolCreateInfo': None}
mapDict['VkCommandPoolCreateInfo'] = {'vkCreateCommandPool': None, 'VkStructureType': None, 'VkCommandPoolCreateFlags': None}
mapDict['VkCommandPoolCreateInfo'] = {'VkStructureType': None, 'vkCreateCommandPool': None, 'VkCommandPoolCreateFlags': None}
mapDict['VkCommandPoolResetFlagBits'] = {'VkCommandPoolResetFlags': None}
mapDict['VkCommandPoolResetFlags'] = {'vkResetCommandPool': None, 'VkCommandPoolResetFlagBits': None}
mapDict['VkCompareOp'] = {'VkSamplerCreateInfo': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkStencilOpState': None}
mapDict['VkComponentMapping'] = {'VkComponentSwizzle': None, 'VkImageViewCreateInfo': None}
mapDict['VkCommandPoolResetFlags'] = {'VkCommandPoolResetFlagBits': None, 'vkResetCommandPool': None}
mapDict['VkCompareOp'] = {'VkStencilOpState': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkSamplerCreateInfo': None}
mapDict['VkComponentMapping'] = {'VkImageViewCreateInfo': None, 'VkComponentSwizzle': None}
mapDict['VkComponentSwizzle'] = {'VkComponentMapping': None}
mapDict['VkComputePipelineCreateInfo'] = {'VkPipelineShaderStageCreateInfo': None, 'vkCreateComputePipelines': None, 'VkPipeline': None, 'VkPipelineCreateFlags': None, 'VkStructureType': None, 'VkPipelineLayout': None}
mapDict['VkCopyDescriptorSet'] = {'vkUpdateDescriptorSets': None, 'VkStructureType': None, 'VkDescriptorSet': None}
mapDict['VkComputePipelineCreateInfo'] = {'VkPipelineCreateFlags': None, 'vkCreateComputePipelines': None, 'VkPipeline': None, 'VkPipelineShaderStageCreateInfo': None, 'VkStructureType': None, 'VkPipelineLayout': None}
mapDict['VkCopyDescriptorSet'] = {'VkStructureType': None, 'VkDescriptorSet': None, 'vkUpdateDescriptorSets': None}
mapDict['VkCullModeFlagBits'] = {'VkCullModeFlags': None}
mapDict['VkCullModeFlags'] = {'VkPipelineRasterizationStateCreateInfo': None, 'VkCullModeFlagBits': None}
mapDict['VkDependencyFlagBits'] = {'VkDependencyFlags': None}
mapDict['VkDependencyFlags'] = {'vkCmdPipelineBarrier': None, 'VkSubpassDependency': None, 'VkDependencyFlagBits': None}
mapDict['VkDescriptorBufferInfo'] = {'VkBuffer': None, 'VkWriteDescriptorSet': None, 'VkDeviceSize': None}
mapDict['VkDescriptorImageInfo'] = {'VkWriteDescriptorSet': None, 'VkImageLayout': None, 'VkImageView': None, 'VkSampler': None}
mapDict['VkDescriptorPool'] = {'vkCreateDescriptorPool': None, 'vkDestroyDescriptorPool': None, 'VkDescriptorSetAllocateInfo': None, 'vkResetDescriptorPool': None, 'vkFreeDescriptorSets': None}
mapDict['VkDependencyFlags'] = {'vkCmdPipelineBarrier': None, 'VkDependencyFlagBits': None, 'VkSubpassDependency': None}
mapDict['VkDescriptorBufferInfo'] = {'VkWriteDescriptorSet': None, 'VkDeviceSize': None, 'VkBuffer': None}
mapDict['VkDescriptorImageInfo'] = {'VkSampler': None, 'VkImageLayout': None, 'VkWriteDescriptorSet': None, 'VkImageView': None}
mapDict['VkDescriptorPool'] = {'vkCreateDescriptorPool': None, 'vkDestroyDescriptorPool': None, 'vkResetDescriptorPool': None, 'VkDescriptorSetAllocateInfo': None, 'vkFreeDescriptorSets': None}
mapDict['VkDescriptorPoolCreateFlagBits'] = {'VkDescriptorPoolCreateFlags': None}
mapDict['VkDescriptorPoolCreateFlags'] = {'VkDescriptorPoolCreateInfo': None, 'VkDescriptorPoolCreateFlagBits': None}
mapDict['VkDescriptorPoolCreateInfo'] = {'vkCreateDescriptorPool': None, 'VkStructureType': None, 'VkDescriptorPoolSize': None, 'VkDescriptorPoolCreateFlags': None}
mapDict['VkDescriptorPoolCreateInfo'] = {'vkCreateDescriptorPool': None, 'VkStructureType': None, 'VkDescriptorPoolCreateFlags': None, 'VkDescriptorPoolSize': None}
mapDict['VkDescriptorPoolResetFlags'] = {'vkResetDescriptorPool': None}
mapDict['VkDescriptorPoolSize'] = {'VkDescriptorType': None, 'VkDescriptorPoolCreateInfo': None}
mapDict['VkDescriptorSet'] = {'vkCmdBindDescriptorSets': None, 'VkWriteDescriptorSet': None, 'VkCopyDescriptorSet': None, 'vkAllocateDescriptorSets': None, 'vkFreeDescriptorSets': None}
mapDict['VkDescriptorSetAllocateInfo'] = {'VkDescriptorSetLayout': None, 'VkDescriptorPool': None, 'VkStructureType': None, 'vkAllocateDescriptorSets': None}
mapDict['VkDescriptorSetLayout'] = {'vkDestroyDescriptorSetLayout': None, 'vkCreateDescriptorSetLayout': None, 'VkPipelineLayoutCreateInfo': None, 'VkDescriptorSetAllocateInfo': None}
mapDict['VkDescriptorSetLayoutBinding'] = {'VkDescriptorType': None, 'VkShaderStageFlags': None, 'VkDescriptorSetLayoutCreateInfo': None, 'VkSampler': None}
mapDict['VkDescriptorPoolSize'] = {'VkDescriptorPoolCreateInfo': None, 'VkDescriptorType': None}
mapDict['VkDescriptorSet'] = {'VkCopyDescriptorSet': None, 'vkFreeDescriptorSets': None, 'vkAllocateDescriptorSets': None, 'VkWriteDescriptorSet': None, 'vkCmdBindDescriptorSets': None}
mapDict['VkDescriptorSetAllocateInfo'] = {'VkStructureType': None, 'VkDescriptorPool': None, 'VkDescriptorSetLayout': None, 'vkAllocateDescriptorSets': None}
mapDict['VkDescriptorSetLayout'] = {'VkPipelineLayoutCreateInfo': None, 'vkCreateDescriptorSetLayout': None, 'vkDestroyDescriptorSetLayout': None, 'VkDescriptorSetAllocateInfo': None}
mapDict['VkDescriptorSetLayoutBinding'] = {'VkSampler': None, 'VkShaderStageFlags': None, 'VkDescriptorType': None, 'VkDescriptorSetLayoutCreateInfo': None}
mapDict['VkDescriptorSetLayoutCreateFlags'] = {'VkDescriptorSetLayoutCreateInfo': None}
mapDict['VkDescriptorSetLayoutCreateInfo'] = {'VkStructureType': None, 'vkCreateDescriptorSetLayout': None, 'VkDescriptorSetLayoutCreateFlags': None, 'VkDescriptorSetLayoutBinding': None}
mapDict['VkDescriptorType'] = {'VkWriteDescriptorSet': None, 'VkDescriptorPoolSize': None, 'VkDescriptorSetLayoutBinding': None}
mapDict['VkDevice'] = {'vkDestroyCommandPool': None, 'vkCreateFence': None, 'vkCreatePipelineCache': None, 'vkCreatePipelineLayout': None, 'vkAllocateDescriptorSets': None, 'vkDestroyShaderModule': None, 'vkDestroyFence': None, 'vkDeviceWaitIdle': None, 'vkWaitForFences': None, 'vkGetFenceStatus': None, 'vkGetDeviceProcAddr': None, 'vkDestroyPipeline': None, 'vkInvalidateMappedMemoryRanges': None, 'vkFlushMappedMemoryRanges': None, 'vkGetDeviceQueue': None, 'vkDestroyPipelineLayout': None, 'vkDestroyDevice': None, 'vkUnmapMemory': None, 'vkCreateImageView': None, 'vkCreateSampler': None, 'vkBindImageMemory': None, 'vkDestroySampler': None, 'vkCreateShaderModule': None, 'vkDestroyRenderPass': None, 'vkBindBufferMemory': None, 'vkDestroyImageView': None, 'vkGetImageSubresourceLayout': None, 'vkCreateBufferView': None, 'vkDestroySemaphore': None, 'vkCreateDevice': None, 'vkCreateEvent': None, 'vkAllocateMemory': None, 'vkResetCommandPool': None, 'vkCreateDescriptorSetLayout': None, 'vkDestroyEvent': None, 'vkDestroyQueryPool': None, 'vkUpdateDescriptorSets': None, 'vkDestroyDescriptorPool': None, 'vkCreateComputePipelines': None, 'vkCreateImage': None, 'vkGetPipelineCacheData': None, 'vkGetImageMemoryRequirements': None, 'vkGetRenderAreaGranularity': None, 'vkResetEvent': None, 'vkSetEvent': None, 'vkCreateDescriptorPool': None, 'vkMapMemory': None, 'vkFreeDescriptorSets': None, 'vkCreateGraphicsPipelines': None, 'vkGetQueryPoolResults': None, 'vkDestroyDescriptorSetLayout': None, 'vkResetFences': None, 'vkDestroyFramebuffer': None, 'vkGetImageSparseMemoryRequirements': None, 'vkCreateCommandPool': None, 'vkGetDeviceMemoryCommitment': None, 'vkResetDescriptorPool': None, 'vkGetEventStatus': None, 'vkDestroyPipelineCache': None, 'vkFreeCommandBuffers': None, 'vkCreateQueryPool': None, 'vkFreeMemory': None, 'vkDestroyBuffer': None, 'vkCreateFramebuffer': None, 'vkGetBufferMemoryRequirements': None, 'vkDestroyImage': None, 'vkAllocateCommandBuffers': None, 'vkCreateSemaphore': None, 'vkDestroyBufferView': None, 'vkMergePipelineCaches': None, 'vkCreateRenderPass': None, 'vkCreateBuffer': None}
mapDict['VkDescriptorSetLayoutCreateInfo'] = {'VkDescriptorSetLayoutBinding': None, 'VkStructureType': None, 'VkDescriptorSetLayoutCreateFlags': None, 'vkCreateDescriptorSetLayout': None}
mapDict['VkDescriptorType'] = {'VkDescriptorSetLayoutBinding': None, 'VkWriteDescriptorSet': None, 'VkDescriptorPoolSize': None}
mapDict['VkDevice'] = {'vkAllocateCommandBuffers': None, 'vkCreateFramebuffer': None, 'vkCreateGraphicsPipelines': None, 'vkDestroySemaphore': None, 'vkFreeCommandBuffers': None, 'vkBindBufferMemory': None, 'vkFreeMemory': None, 'vkGetBufferMemoryRequirements': None, 'vkGetImageMemoryRequirements': None, 'vkWaitForFences': None, 'vkDestroyShaderModule': None, 'vkDestroyQueryPool': None, 'vkDestroyEvent': None, 'vkInvalidateMappedMemoryRanges': None, 'vkDestroyPipelineLayout': None, 'vkFlushMappedMemoryRanges': None, 'vkDestroyPipelineCache': None, 'vkFreeDescriptorSets': None, 'vkDeviceWaitIdle': None, 'vkCreateBuffer': None, 'vkCreateSampler': None, 'vkDestroyCommandPool': None, 'vkCreateDevice': None, 'vkUpdateDescriptorSets': None, 'vkDestroyDescriptorPool': None, 'vkSetEvent': None, 'vkCreateFence': None, 'vkCreateImage': None, 'vkGetImageSubresourceLayout': None, 'vkGetDeviceQueue': None, 'vkResetFences': None, 'vkGetFenceStatus': None, 'vkCreatePipelineCache': None, 'vkGetDeviceMemoryCommitment': None, 'vkResetCommandPool': None, 'vkDestroySampler': None, 'vkGetImageSparseMemoryRequirements': None, 'vkAllocateMemory': None, 'vkMapMemory': None, 'vkDestroyFramebuffer': None, 'vkCreateCommandPool': None, 'vkCreateSemaphore': None, 'vkAllocateDescriptorSets': None, 'vkMergePipelineCaches': None, 'vkDestroyDescriptorSetLayout': None, 'vkCreateBufferView': None, 'vkResetEvent': None, 'vkDestroyImageView': None, 'vkUnmapMemory': None, 'vkResetDescriptorPool': None, 'vkDestroyBufferView': None, 'vkDestroyRenderPass': None, 'vkDestroyFence': None, 'vkBindImageMemory': None, 'vkCreateEvent': None, 'vkDestroyImage': None, 'vkCreateRenderPass': None, 'vkGetDeviceProcAddr': None, 'vkDestroyBuffer': None, 'vkGetPipelineCacheData': None, 'vkCreateDescriptorPool': None, 'vkCreateComputePipelines': None, 'vkCreateShaderModule': None, 'vkDestroyPipeline': None, 'vkDestroyDevice': None, 'vkCreatePipelineLayout': None, 'vkGetEventStatus': None, 'vkCreateImageView': None, 'vkCreateDescriptorSetLayout': None, 'vkGetRenderAreaGranularity': None, 'vkGetQueryPoolResults': None, 'vkCreateQueryPool': None}
mapDict['VkDeviceCreateFlags'] = {'VkDeviceCreateInfo': None}
mapDict['VkDeviceCreateInfo'] = {'VkDeviceCreateFlags': None, 'VkStructureType': None, 'VkPhysicalDeviceFeatures': None, 'VkDeviceQueueCreateInfo': None, 'vkCreateDevice': None}
mapDict['VkDeviceMemory'] = {'VkMappedMemoryRange': None, 'vkMapMemory': None, 'vkUnmapMemory': None, 'vkGetDeviceMemoryCommitment': None, 'vkAllocateMemory': None, 'vkBindImageMemory': None, 'vkBindBufferMemory': None, 'VkSparseImageMemoryBind': None, 'vkFreeMemory': None, 'VkSparseMemoryBind': None}
mapDict['VkDeviceCreateInfo'] = {'VkStructureType': None, 'VkPhysicalDeviceFeatures': None, 'vkCreateDevice': None, 'VkDeviceQueueCreateInfo': None, 'VkDeviceCreateFlags': None}
mapDict['VkDeviceMemory'] = {'vkBindImageMemory': None, 'VkSparseMemoryBind': None, 'vkAllocateMemory': None, 'vkBindBufferMemory': None, 'vkFreeMemory': None, 'vkMapMemory': None, 'vkUnmapMemory': None, 'VkMappedMemoryRange': None, 'VkSparseImageMemoryBind': None, 'vkGetDeviceMemoryCommitment': None}
mapDict['VkDeviceQueueCreateFlags'] = {'VkDeviceQueueCreateInfo': None}
mapDict['VkDeviceQueueCreateInfo'] = {'VkDeviceCreateInfo': None, 'VkStructureType': None, 'VkDeviceQueueCreateFlags': None}
mapDict['VkDeviceSize'] = {'vkCmdBindVertexBuffers': None, 'VkMemoryRequirements': None, 'VkBufferCopy': None, 'VkBufferImageCopy': None, 'vkCmdUpdateBuffer': None, 'vkCmdCopyQueryPoolResults': None, 'VkBufferViewCreateInfo': None, 'vkCmdFillBuffer': None, 'VkMappedMemoryRange': None, 'VkDescriptorBufferInfo': None, 'VkMemoryAllocateInfo': None, 'VkSparseImageMemoryBind': None, 'vkCmdDispatchIndirect': None, 'vkGetQueryPoolResults': None, 'VkSubresourceLayout': None, 'VkSparseMemoryBind': None, 'VkPhysicalDeviceLimits': None, 'vkMapMemory': None, 'VkBufferMemoryBarrier': None, 'vkGetDeviceMemoryCommitment': None, 'VkImageFormatProperties': None, 'VkMemoryHeap': None, 'vkBindImageMemory': None, 'vkBindBufferMemory': None, 'vkCmdDrawIndexedIndirect': None, 'vkCmdDrawIndirect': None, 'vkCmdBindIndexBuffer': None, 'VkBufferCreateInfo': None, 'VkSparseImageMemoryRequirements': None}
mapDict['VkDeviceQueueCreateInfo'] = {'VkStructureType': None, 'VkDeviceCreateInfo': None, 'VkDeviceQueueCreateFlags': None}
mapDict['VkDeviceSize'] = {'vkBindBufferMemory': None, 'vkMapMemory': None, 'VkBufferMemoryBarrier': None, 'VkMemoryAllocateInfo': None, 'vkCmdDrawIndirect': None, 'VkBufferCreateInfo': None, 'VkMemoryRequirements': None, 'vkCmdCopyQueryPoolResults': None, 'VkPhysicalDeviceLimits': None, 'vkCmdUpdateBuffer': None, 'vkCmdBindVertexBuffers': None, 'VkSparseMemoryBind': None, 'VkBufferViewCreateInfo': None, 'VkSubresourceLayout': None, 'VkImageFormatProperties': None, 'vkBindImageMemory': None, 'VkMemoryHeap': None, 'vkCmdDrawIndexedIndirect': None, 'vkCmdFillBuffer': None, 'VkBufferCopy': None, 'VkSparseImageMemoryBind': None, 'vkCmdBindIndexBuffer': None, 'VkDescriptorBufferInfo': None, 'VkSparseImageMemoryRequirements': None, 'VkBufferImageCopy': None, 'VkMappedMemoryRange': None, 'vkGetDeviceMemoryCommitment': None, 'vkGetQueryPoolResults': None, 'vkCmdDispatchIndirect': None}
mapDict['VkDynamicState'] = {'VkPipelineDynamicStateCreateInfo': None}
mapDict['VkEvent'] = {'vkGetEventStatus': None, 'vkCmdResetEvent': None, 'vkCmdWaitEvents': None, 'vkCmdSetEvent': None, 'vkCreateEvent': None, 'vkResetEvent': None, 'vkDestroyEvent': None, 'vkSetEvent': None}
mapDict['VkEvent'] = {'vkCreateEvent': None, 'vkResetEvent': None, 'vkCmdSetEvent': None, 'vkGetEventStatus': None, 'vkSetEvent': None, 'vkCmdResetEvent': None, 'vkCmdWaitEvents': None, 'vkDestroyEvent': None}
mapDict['VkEventCreateFlags'] = {'VkEventCreateInfo': None}
mapDict['VkEventCreateInfo'] = {'VkStructureType': None, 'VkEventCreateFlags': None, 'vkCreateEvent': None}
mapDict['VkExtensionProperties'] = {'vkEnumerateDeviceExtensionProperties': None, 'vkEnumerateInstanceExtensionProperties': None}
mapDict['VkExtent2D'] = {'vkGetRenderAreaGranularity': None, 'VkRect2D': None}
mapDict['VkExtent3D'] = {'VkBufferImageCopy': None, 'VkImageResolve': None, 'VkImageFormatProperties': None, 'VkSparseImageMemoryBind': None, 'VkSparseImageFormatProperties': None, 'VkQueueFamilyProperties': None, 'VkImageCreateInfo': None, 'VkImageCopy': None}
mapDict['VkFence'] = {'vkResetFences': None, 'vkDestroyFence': None, 'vkCreateFence': None, 'vkWaitForFences': None, 'vkQueueSubmit': None, 'vkGetFenceStatus': None, 'vkQueueBindSparse': None}
mapDict['VkExtensionProperties'] = {'vkEnumerateInstanceExtensionProperties': None, 'vkEnumerateDeviceExtensionProperties': None}
mapDict['VkExtent2D'] = {'VkRect2D': None, 'vkGetRenderAreaGranularity': None}
mapDict['VkExtent3D'] = {'VkImageCopy': None, 'VkQueueFamilyProperties': None, 'VkBufferImageCopy': None, 'VkSparseImageFormatProperties': None, 'VkSparseImageMemoryBind': None, 'VkImageResolve': None, 'VkImageCreateInfo': None, 'VkImageFormatProperties': None}
mapDict['VkFence'] = {'vkGetFenceStatus': None, 'vkCreateFence': None, 'vkWaitForFences': None, 'vkResetFences': None, 'vkQueueSubmit': None, 'vkDestroyFence': None, 'vkQueueBindSparse': None}
mapDict['VkFenceCreateFlagBits'] = {'VkFenceCreateFlags': None}
mapDict['VkFenceCreateFlags'] = {'VkFenceCreateFlagBits': None, 'VkFenceCreateInfo': None}
mapDict['VkFenceCreateInfo'] = {'VkStructureType': None, 'vkCreateFence': None, 'VkFenceCreateFlags': None}
mapDict['VkFenceCreateFlags'] = {'VkFenceCreateInfo': None, 'VkFenceCreateFlagBits': None}
mapDict['VkFenceCreateInfo'] = {'VkStructureType': None, 'VkFenceCreateFlags': None, 'vkCreateFence': None}
mapDict['VkFilter'] = {'VkSamplerCreateInfo': None, 'vkCmdBlitImage': None}
mapDict['VkFormat'] = {'vkGetPhysicalDeviceFormatProperties': None, 'VkVertexInputAttributeDescription': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'VkAttachmentDescription': None, 'VkImageViewCreateInfo': None, 'VkImageCreateInfo': None, 'VkBufferViewCreateInfo': None}
mapDict['VkFormat'] = {'VkImageViewCreateInfo': None, 'vkGetPhysicalDeviceFormatProperties': None, 'VkBufferViewCreateInfo': None, 'VkVertexInputAttributeDescription': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None, 'VkAttachmentDescription': None}
mapDict['VkFormatFeatureFlagBits'] = {'VkFormatFeatureFlags': None}
mapDict['VkFormatFeatureFlags'] = {'VkFormatProperties': None, 'VkFormatFeatureFlagBits': None}
mapDict['VkFormatProperties'] = {'vkGetPhysicalDeviceFormatProperties': None, 'VkFormatFeatureFlags': None}
mapDict['VkFramebuffer'] = {'vkCreateFramebuffer': None, 'vkDestroyFramebuffer': None, 'VkCommandBufferInheritanceInfo': None, 'VkRenderPassBeginInfo': None}
mapDict['VkFramebuffer'] = {'vkCreateFramebuffer': None, 'VkRenderPassBeginInfo': None, 'VkCommandBufferInheritanceInfo': None, 'vkDestroyFramebuffer': None}
mapDict['VkFramebufferCreateFlags'] = {'VkFramebufferCreateInfo': None}
mapDict['VkFramebufferCreateInfo'] = {'vkCreateFramebuffer': None, 'VkStructureType': None, 'VkRenderPass': None, 'VkImageView': None, 'VkFramebufferCreateFlags': None}
mapDict['VkFramebufferCreateInfo'] = {'vkCreateFramebuffer': None, 'VkStructureType': None, 'VkRenderPass': None, 'VkFramebufferCreateFlags': None, 'VkImageView': None}
mapDict['VkFrontFace'] = {'VkPipelineRasterizationStateCreateInfo': None}
mapDict['VkGraphicsPipelineCreateInfo'] = {'VkPipelineShaderStageCreateInfo': None, 'VkPipelineTessellationStateCreateInfo': None, 'VkRenderPass': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkPipelineMultisampleStateCreateInfo': None, 'VkPipelineCreateFlags': None, 'VkPipelineDynamicStateCreateInfo': None, 'VkStructureType': None, 'VkPipelineLayout': None, 'VkPipelineInputAssemblyStateCreateInfo': None, 'VkPipelineRasterizationStateCreateInfo': None, 'VkPipelineVertexInputStateCreateInfo': None, 'vkCreateGraphicsPipelines': None, 'VkPipeline': None, 'VkPipelineViewportStateCreateInfo': None, 'VkPipelineColorBlendStateCreateInfo': None}
mapDict['VkImage'] = {'vkCmdClearColorImage': None, 'VkImageMemoryBarrier': None, 'vkGetImageSparseMemoryRequirements': None, 'vkCreateImage': None, 'vkBindImageMemory': None, 'vkGetImageMemoryRequirements': None, 'vkCmdCopyImageToBuffer': None, 'VkImageViewCreateInfo': None, 'vkCmdResolveImage': None, 'vkGetImageSubresourceLayout': None, 'vkCmdClearDepthStencilImage': None, 'VkSparseImageMemoryBindInfo': None, 'vkDestroyImage': None, 'vkCmdCopyImage': None, 'vkCmdCopyBufferToImage': None, 'VkSparseImageOpaqueMemoryBindInfo': None, 'vkCmdBlitImage': None}
mapDict['VkGraphicsPipelineCreateInfo'] = {'VkPipelineMultisampleStateCreateInfo': None, 'VkPipelineInputAssemblyStateCreateInfo': None, 'VkPipelineVertexInputStateCreateInfo': None, 'VkPipelineTessellationStateCreateInfo': None, 'VkPipelineDynamicStateCreateInfo': None, 'vkCreateGraphicsPipelines': None, 'VkPipelineRasterizationStateCreateInfo': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkPipelineColorBlendStateCreateInfo': None, 'VkPipelineViewportStateCreateInfo': None, 'VkRenderPass': None, 'VkPipelineCreateFlags': None, 'VkPipeline': None, 'VkPipelineShaderStageCreateInfo': None, 'VkStructureType': None, 'VkPipelineLayout': None}
mapDict['VkImage'] = {'vkBindImageMemory': None, 'VkImageViewCreateInfo': None, 'vkGetImageSparseMemoryRequirements': None, 'VkSparseImageMemoryBindInfo': None, 'vkDestroyImage': None, 'vkCmdClearColorImage': None, 'vkGetImageMemoryRequirements': None, 'vkCmdCopyBufferToImage': None, 'VkImageMemoryBarrier': None, 'vkCreateImage': None, 'vkGetImageSubresourceLayout': None, 'vkCmdCopyImage': None, 'vkCmdResolveImage': None, 'VkSparseImageOpaqueMemoryBindInfo': None, 'vkCmdBlitImage': None, 'vkCmdCopyImageToBuffer': None, 'vkCmdClearDepthStencilImage': None}
mapDict['VkImageAspectFlagBits'] = {'VkImageAspectFlags': None}
mapDict['VkImageAspectFlags'] = {'VkImageSubresourceLayers': None, 'VkClearAttachment': None, 'VkImageSubresource': None, 'VkImageAspectFlagBits': None, 'VkImageSubresourceRange': None, 'VkSparseImageFormatProperties': None}
mapDict['VkImageAspectFlags'] = {'VkClearAttachment': None, 'VkImageSubresourceRange': None, 'VkImageSubresourceLayers': None, 'VkSparseImageFormatProperties': None, 'VkImageSubresource': None, 'VkImageAspectFlagBits': None}
mapDict['VkImageBlit'] = {'VkImageSubresourceLayers': None, 'VkOffset3D': None, 'vkCmdBlitImage': None}
mapDict['VkImageCopy'] = {'VkImageSubresourceLayers': None, 'VkOffset3D': None, 'vkCmdCopyImage': None, 'VkExtent3D': None}
mapDict['VkImageCopy'] = {'VkExtent3D': None, 'VkImageSubresourceLayers': None, 'vkCmdCopyImage': None, 'VkOffset3D': None}
mapDict['VkImageCreateFlagBits'] = {'VkImageCreateFlags': None}
mapDict['VkImageCreateFlags'] = {'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None, 'VkImageCreateFlagBits': None}
mapDict['VkImageCreateInfo'] = {'VkSharingMode': None, 'VkFormat': None, 'VkImageTiling': None, 'VkImageUsageFlags': None, 'VkSampleCountFlagBits': None, 'VkImageLayout': None, 'vkCreateImage': None, 'VkStructureType': None, 'VkImageCreateFlags': None, 'VkImageType': None, 'VkExtent3D': None}
mapDict['VkImageFormatProperties'] = {'VkSampleCountFlags': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'VkDeviceSize': None, 'VkExtent3D': None}
mapDict['VkImageLayout'] = {'vkCmdClearColorImage': None, 'vkCmdClearDepthStencilImage': None, 'vkCmdCopyImageToBuffer': None, 'vkCmdResolveImage': None, 'VkAttachmentDescription': None, 'VkImageMemoryBarrier': None, 'vkCmdCopyImage': None, 'VkAttachmentReference': None, 'VkDescriptorImageInfo': None, 'VkImageCreateInfo': None, 'vkCmdBlitImage': None, 'vkCmdCopyBufferToImage': None}
mapDict['VkImageMemoryBarrier'] = {'VkAccessFlags': None, 'vkCmdWaitEvents': None, 'VkImageSubresourceRange': None, 'VkImage': None, 'vkCmdPipelineBarrier': None, 'VkStructureType': None, 'VkImageLayout': None}
mapDict['VkImageResolve'] = {'VkImageSubresourceLayers': None, 'VkOffset3D': None, 'vkCmdResolveImage': None, 'VkExtent3D': None}
mapDict['VkImageSubresource'] = {'vkGetImageSubresourceLayout': None, 'VkImageAspectFlags': None, 'VkSparseImageMemoryBind': None}
mapDict['VkImageSubresourceLayers'] = {'VkBufferImageCopy': None, 'VkImageBlit': None, 'VkImageAspectFlags': None, 'VkImageResolve': None, 'VkImageCopy': None}
mapDict['VkImageSubresourceRange'] = {'vkCmdClearColorImage': None, 'vkCmdClearDepthStencilImage': None, 'VkImageMemoryBarrier': None, 'VkImageAspectFlags': None, 'VkImageViewCreateInfo': None}
mapDict['VkImageTiling'] = {'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None}
mapDict['VkImageType'] = {'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None}
mapDict['VkImageCreateInfo'] = {'VkImageLayout': None, 'vkCreateImage': None, 'VkImageUsageFlags': None, 'VkImageTiling': None, 'VkFormat': None, 'VkExtent3D': None, 'VkSharingMode': None, 'VkStructureType': None, 'VkSampleCountFlagBits': None, 'VkImageType': None, 'VkImageCreateFlags': None}
mapDict['VkImageFormatProperties'] = {'VkExtent3D': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'VkSampleCountFlags': None, 'VkDeviceSize': None}
mapDict['VkImageLayout'] = {'VkAttachmentReference': None, 'VkDescriptorImageInfo': None, 'VkImageMemoryBarrier': None, 'vkCmdCopyImageToBuffer': None, 'VkImageCreateInfo': None, 'VkAttachmentDescription': None, 'vkCmdCopyImage': None, 'vkCmdResolveImage': None, 'vkCmdCopyBufferToImage': None, 'vkCmdClearColorImage': None, 'vkCmdBlitImage': None, 'vkCmdClearDepthStencilImage': None}
mapDict['VkImageMemoryBarrier'] = {'VkImageLayout': None, 'vkCmdWaitEvents': None, 'VkAccessFlags': None, 'VkImage': None, 'VkStructureType': None, 'VkImageSubresourceRange': None, 'vkCmdPipelineBarrier': None}
mapDict['VkImageResolve'] = {'VkExtent3D': None, 'VkImageSubresourceLayers': None, 'VkOffset3D': None, 'vkCmdResolveImage': None}
mapDict['VkImageSubresource'] = {'VkSparseImageMemoryBind': None, 'VkImageAspectFlags': None, 'vkGetImageSubresourceLayout': None}
mapDict['VkImageSubresourceLayers'] = {'VkBufferImageCopy': None, 'VkImageCopy': None, 'VkImageAspectFlags': None, 'VkImageResolve': None, 'VkImageBlit': None}
mapDict['VkImageSubresourceRange'] = {'VkImageViewCreateInfo': None, 'vkCmdClearDepthStencilImage': None, 'VkImageAspectFlags': None, 'VkImageMemoryBarrier': None, 'vkCmdClearColorImage': None}
mapDict['VkImageTiling'] = {'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None}
mapDict['VkImageType'] = {'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None}
mapDict['VkImageUsageFlagBits'] = {'VkImageUsageFlags': None}
mapDict['VkImageUsageFlags'] = {'VkImageUsageFlagBits': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None}
mapDict['VkImageView'] = {'VkFramebufferCreateInfo': None, 'VkDescriptorImageInfo': None, 'vkCreateImageView': None, 'vkDestroyImageView': None}
mapDict['VkImageUsageFlags'] = {'VkImageUsageFlagBits': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'VkImageCreateInfo': None}
mapDict['VkImageView'] = {'VkDescriptorImageInfo': None, 'vkCreateImageView': None, 'vkDestroyImageView': None, 'VkFramebufferCreateInfo': None}
mapDict['VkImageViewCreateFlags'] = {'VkImageViewCreateInfo': None}
mapDict['VkImageViewCreateInfo'] = {'VkFormat': None, 'vkCreateImageView': None, 'VkImageSubresourceRange': None, 'VkImage': None, 'VkImageViewCreateFlags': None, 'VkStructureType': None, 'VkImageViewType': None, 'VkComponentMapping': None}
mapDict['VkImageViewCreateInfo'] = {'VkImageViewCreateFlags': None, 'VkImage': None, 'VkImageViewType': None, 'VkFormat': None, 'vkCreateImageView': None, 'VkComponentMapping': None, 'VkStructureType': None, 'VkImageSubresourceRange': None}
mapDict['VkImageViewType'] = {'VkImageViewCreateInfo': None}
mapDict['VkIndexType'] = {'vkCmdBindIndexBuffer': None}
mapDict['VkInstance'] = {'vkEnumeratePhysicalDevices': None, 'vkDestroyInstance': None, 'vkGetInstanceProcAddr': None, 'vkCreateInstance': None}
mapDict['VkInstance'] = {'vkDestroyInstance': None, 'vkEnumeratePhysicalDevices': None, 'vkCreateInstance': None, 'vkGetInstanceProcAddr': None}
mapDict['VkInstanceCreateFlags'] = {'VkInstanceCreateInfo': None}
mapDict['VkInstanceCreateInfo'] = {'VkStructureType': None, 'VkInstanceCreateFlags': None, 'vkCreateInstance': None, 'VkApplicationInfo': None}
mapDict['VkInstanceCreateInfo'] = {'VkStructureType': None, 'vkCreateInstance': None, 'VkInstanceCreateFlags': None, 'VkApplicationInfo': None}
mapDict['VkLayerProperties'] = {'vkEnumerateInstanceLayerProperties': None, 'vkEnumerateDeviceLayerProperties': None}
mapDict['VkLogicOp'] = {'VkPipelineColorBlendStateCreateInfo': None}
mapDict['VkMappedMemoryRange'] = {'VkStructureType': None, 'VkDeviceMemory': None, 'vkInvalidateMappedMemoryRanges': None, 'vkFlushMappedMemoryRanges': None, 'VkDeviceSize': None}
mapDict['VkMemoryAllocateInfo'] = {'VkStructureType': None, 'vkAllocateMemory': None, 'VkDeviceSize': None}
mapDict['VkMemoryBarrier'] = {'vkCmdPipelineBarrier': None, 'VkAccessFlags': None, 'VkStructureType': None, 'vkCmdWaitEvents': None}
mapDict['VkMemoryHeap'] = {'VkPhysicalDeviceMemoryProperties': None, 'VkDeviceSize': None, 'VkMemoryHeapFlags': None}
mapDict['VkMappedMemoryRange'] = {'vkInvalidateMappedMemoryRanges': None, 'VkDeviceMemory': None, 'VkStructureType': None, 'VkDeviceSize': None, 'vkFlushMappedMemoryRanges': None}
mapDict['VkMemoryAllocateInfo'] = {'vkAllocateMemory': None, 'VkStructureType': None, 'VkDeviceSize': None}
mapDict['VkMemoryBarrier'] = {'VkStructureType': None, 'VkAccessFlags': None, 'vkCmdPipelineBarrier': None, 'vkCmdWaitEvents': None}
mapDict['VkMemoryHeap'] = {'VkPhysicalDeviceMemoryProperties': None, 'VkMemoryHeapFlags': None, 'VkDeviceSize': None}
mapDict['VkMemoryHeapFlagBits'] = {'VkMemoryHeapFlags': None}
mapDict['VkMemoryHeapFlags'] = {'VkMemoryHeapFlagBits': None, 'VkMemoryHeap': None}
mapDict['VkMemoryMapFlags'] = {'vkMapMemory': None}
mapDict['VkMemoryPropertyFlagBits'] = {'VkMemoryPropertyFlags': None}
mapDict['VkMemoryPropertyFlags'] = {'VkMemoryPropertyFlagBits': None, 'VkMemoryType': None}
mapDict['VkMemoryRequirements'] = {'vkGetBufferMemoryRequirements': None, 'vkGetImageMemoryRequirements': None, 'VkDeviceSize': None}
mapDict['VkMemoryType'] = {'VkMemoryPropertyFlags': None, 'VkPhysicalDeviceMemoryProperties': None}
mapDict['VkMemoryRequirements'] = {'vkGetImageMemoryRequirements': None, 'VkDeviceSize': None, 'vkGetBufferMemoryRequirements': None}
mapDict['VkMemoryType'] = {'VkPhysicalDeviceMemoryProperties': None, 'VkMemoryPropertyFlags': None}
mapDict['VkOffset2D'] = {'VkRect2D': None}
mapDict['VkOffset3D'] = {'VkBufferImageCopy': None, 'VkImageBlit': None, 'VkImageResolve': None, 'VkSparseImageMemoryBind': None, 'VkImageCopy': None}
mapDict['VkPhysicalDevice'] = {'vkGetPhysicalDeviceFormatProperties': None, 'vkGetPhysicalDeviceQueueFamilyProperties': None, 'vkGetPhysicalDeviceFeatures': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'vkEnumerateDeviceLayerProperties': None, 'vkGetPhysicalDeviceMemoryProperties': None, 'vkEnumeratePhysicalDevices': None, 'vkEnumerateDeviceExtensionProperties': None, 'vkGetPhysicalDeviceProperties': None, 'vkCreateDevice': None}
mapDict['VkPhysicalDeviceFeatures'] = {'VkDeviceCreateInfo': None, 'vkGetPhysicalDeviceFeatures': None, 'VkBool32': None}
mapDict['VkPhysicalDeviceLimits'] = {'VkPhysicalDeviceProperties': None, 'VkBool32': None, 'VkDeviceSize': None, 'VkSampleCountFlags': None}
mapDict['VkPhysicalDeviceMemoryProperties'] = {'VkMemoryHeap': None, 'vkGetPhysicalDeviceMemoryProperties': None, 'VkMemoryType': None}
mapDict['VkPhysicalDeviceProperties'] = {'vkGetPhysicalDeviceProperties': None, 'VkPhysicalDeviceLimits': None, 'VkPhysicalDeviceSparseProperties': None, 'VkPhysicalDeviceType': None}
mapDict['VkPhysicalDeviceSparseProperties'] = {'VkPhysicalDeviceProperties': None, 'VkBool32': None}
mapDict['VkOffset3D'] = {'VkBufferImageCopy': None, 'VkImageCopy': None, 'VkSparseImageMemoryBind': None, 'VkImageResolve': None, 'VkImageBlit': None}
mapDict['VkPhysicalDevice'] = {'vkGetPhysicalDeviceMemoryProperties': None, 'vkGetPhysicalDeviceFeatures': None, 'vkGetPhysicalDeviceFormatProperties': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'vkEnumerateDeviceLayerProperties': None, 'vkEnumerateDeviceExtensionProperties': None, 'vkGetPhysicalDeviceProperties': None, 'vkGetPhysicalDeviceQueueFamilyProperties': None, 'vkEnumeratePhysicalDevices': None, 'vkGetPhysicalDeviceImageFormatProperties': None, 'vkCreateDevice': None}
mapDict['VkPhysicalDeviceFeatures'] = {'vkGetPhysicalDeviceFeatures': None, 'VkDeviceCreateInfo': None, 'VkBool32': None}
mapDict['VkPhysicalDeviceLimits'] = {'VkSampleCountFlags': None, 'VkDeviceSize': None, 'VkBool32': None, 'VkPhysicalDeviceProperties': None}
mapDict['VkPhysicalDeviceMemoryProperties'] = {'vkGetPhysicalDeviceMemoryProperties': None, 'VkMemoryHeap': None, 'VkMemoryType': None}
mapDict['VkPhysicalDeviceProperties'] = {'VkPhysicalDeviceSparseProperties': None, 'VkPhysicalDeviceType': None, 'VkPhysicalDeviceLimits': None, 'vkGetPhysicalDeviceProperties': None}
mapDict['VkPhysicalDeviceSparseProperties'] = {'VkBool32': None, 'VkPhysicalDeviceProperties': None}
mapDict['VkPhysicalDeviceType'] = {'VkPhysicalDeviceProperties': None}
mapDict['VkPipeline'] = {'vkCreateComputePipelines': None, 'vkCmdBindPipeline': None, 'VkGraphicsPipelineCreateInfo': None, 'VkComputePipelineCreateInfo': None, 'vkCreateGraphicsPipelines': None, 'vkDestroyPipeline': None}
mapDict['VkPipeline'] = {'vkCreateComputePipelines': None, 'vkCmdBindPipeline': None, 'vkDestroyPipeline': None, 'vkCreateGraphicsPipelines': None, 'VkGraphicsPipelineCreateInfo': None, 'VkComputePipelineCreateInfo': None}
mapDict['VkPipelineBindPoint'] = {'vkCmdBindPipeline': None, 'VkSubpassDescription': None, 'vkCmdBindDescriptorSets': None}
mapDict['VkPipelineCache'] = {'vkMergePipelineCaches': None, 'vkCreateComputePipelines': None, 'vkCreatePipelineCache': None, 'vkGetPipelineCacheData': None, 'vkCreateGraphicsPipelines': None, 'vkDestroyPipelineCache': None}
mapDict['VkPipelineCache'] = {'vkCreateComputePipelines': None, 'vkDestroyPipelineCache': None, 'vkCreateGraphicsPipelines': None, 'vkCreatePipelineCache': None, 'vkGetPipelineCacheData': None, 'vkMergePipelineCaches': None}
mapDict['VkPipelineCacheCreateFlags'] = {'VkPipelineCacheCreateInfo': None}
mapDict['VkPipelineCacheCreateInfo'] = {'VkStructureType': None, 'vkCreatePipelineCache': None, 'VkPipelineCacheCreateFlags': None}
mapDict['VkPipelineColorBlendAttachmentState'] = {'VkPipelineColorBlendStateCreateInfo': None, 'VkColorComponentFlags': None, 'VkBlendFactor': None, 'VkBool32': None, 'VkBlendOp': None}
mapDict['VkPipelineColorBlendAttachmentState'] = {'VkBlendOp': None, 'VkColorComponentFlags': None, 'VkPipelineColorBlendStateCreateInfo': None, 'VkBool32': None, 'VkBlendFactor': None}
mapDict['VkPipelineColorBlendStateCreateFlags'] = {'VkPipelineColorBlendStateCreateInfo': None}
mapDict['VkPipelineColorBlendStateCreateInfo'] = {'VkPipelineColorBlendAttachmentState': None, 'VkPipelineColorBlendStateCreateFlags': None, 'VkLogicOp': None, 'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkBool32': None}
mapDict['VkPipelineColorBlendStateCreateInfo'] = {'VkPipelineColorBlendStateCreateFlags': None, 'VkGraphicsPipelineCreateInfo': None, 'VkBool32': None, 'VkLogicOp': None, 'VkStructureType': None, 'VkPipelineColorBlendAttachmentState': None}
mapDict['VkPipelineCreateFlagBits'] = {'VkPipelineCreateFlags': None}
mapDict['VkPipelineCreateFlags'] = {'VkPipelineCreateFlagBits': None, 'VkComputePipelineCreateInfo': None, 'VkGraphicsPipelineCreateInfo': None}
mapDict['VkPipelineCreateFlags'] = {'VkPipelineCreateFlagBits': None, 'VkGraphicsPipelineCreateInfo': None, 'VkComputePipelineCreateInfo': None}
mapDict['VkPipelineDepthStencilStateCreateFlags'] = {'VkPipelineDepthStencilStateCreateInfo': None}
mapDict['VkPipelineDepthStencilStateCreateInfo'] = {'VkPipelineDepthStencilStateCreateFlags': None, 'VkGraphicsPipelineCreateInfo': None, 'VkStencilOpState': None, 'VkStructureType': None, 'VkBool32': None, 'VkCompareOp': None}
mapDict['VkPipelineDepthStencilStateCreateInfo'] = {'VkCompareOp': None, 'VkStencilOpState': None, 'VkPipelineDepthStencilStateCreateFlags': None, 'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkBool32': None}
mapDict['VkPipelineDynamicStateCreateFlags'] = {'VkPipelineDynamicStateCreateInfo': None}
mapDict['VkPipelineDynamicStateCreateInfo'] = {'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkDynamicState': None, 'VkPipelineDynamicStateCreateFlags': None}
mapDict['VkPipelineInputAssemblyStateCreateFlags'] = {'VkPipelineInputAssemblyStateCreateInfo': None}
mapDict['VkPipelineInputAssemblyStateCreateInfo'] = {'VkGraphicsPipelineCreateInfo': None, 'VkPipelineInputAssemblyStateCreateFlags': None, 'VkStructureType': None, 'VkBool32': None, 'VkPrimitiveTopology': None}
mapDict['VkPipelineLayout'] = {'vkDestroyPipelineLayout': None, 'VkGraphicsPipelineCreateInfo': None, 'VkComputePipelineCreateInfo': None, 'vkCreatePipelineLayout': None, 'vkCmdBindDescriptorSets': None, 'vkCmdPushConstants': None}
mapDict['VkPipelineInputAssemblyStateCreateInfo'] = {'VkGraphicsPipelineCreateInfo': None, 'VkBool32': None, 'VkStructureType': None, 'VkPipelineInputAssemblyStateCreateFlags': None, 'VkPrimitiveTopology': None}
mapDict['VkPipelineLayout'] = {'vkDestroyPipelineLayout': None, 'vkCmdPushConstants': None, 'vkCreatePipelineLayout': None, 'VkGraphicsPipelineCreateInfo': None, 'VkComputePipelineCreateInfo': None, 'vkCmdBindDescriptorSets': None}
mapDict['VkPipelineLayoutCreateFlags'] = {'VkPipelineLayoutCreateInfo': None}
mapDict['VkPipelineLayoutCreateInfo'] = {'VkDescriptorSetLayout': None, 'VkStructureType': None, 'VkPushConstantRange': None, 'vkCreatePipelineLayout': None, 'VkPipelineLayoutCreateFlags': None}
mapDict['VkPipelineLayoutCreateInfo'] = {'VkPipelineLayoutCreateFlags': None, 'VkStructureType': None, 'VkPushConstantRange': None, 'VkDescriptorSetLayout': None, 'vkCreatePipelineLayout': None}
mapDict['VkPipelineMultisampleStateCreateFlags'] = {'VkPipelineMultisampleStateCreateInfo': None}
mapDict['VkPipelineMultisampleStateCreateInfo'] = {'VkPipelineMultisampleStateCreateFlags': None, 'VkSampleCountFlagBits': None, 'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkSampleMask': None, 'VkBool32': None}
mapDict['VkPipelineMultisampleStateCreateInfo'] = {'VkSampleMask': None, 'VkBool32': None, 'VkPipelineMultisampleStateCreateFlags': None, 'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkSampleCountFlagBits': None}
mapDict['VkPipelineRasterizationStateCreateFlags'] = {'VkPipelineRasterizationStateCreateInfo': None}
mapDict['VkPipelineRasterizationStateCreateInfo'] = {'VkCullModeFlags': None, 'VkBool32': None, 'VkGraphicsPipelineCreateInfo': None, 'VkFrontFace': None, 'VkStructureType': None, 'VkPipelineRasterizationStateCreateFlags': None, 'VkPolygonMode': None}
mapDict['VkPipelineRasterizationStateCreateInfo'] = {'VkGraphicsPipelineCreateInfo': None, 'VkFrontFace': None, 'VkBool32': None, 'VkPipelineRasterizationStateCreateFlags': None, 'VkStructureType': None, 'VkPolygonMode': None, 'VkCullModeFlags': None}
mapDict['VkPipelineShaderStageCreateFlags'] = {'VkPipelineShaderStageCreateInfo': None}
mapDict['VkPipelineShaderStageCreateInfo'] = {'VkComputePipelineCreateInfo': None, 'VkGraphicsPipelineCreateInfo': None, 'VkPipelineShaderStageCreateFlags': None, 'VkShaderStageFlagBits': None, 'VkStructureType': None, 'VkSpecializationInfo': None, 'VkShaderModule': None}
mapDict['VkPipelineStageFlagBits'] = {'VkPipelineStageFlags': None, 'vkCmdWriteTimestamp': None}
mapDict['VkPipelineStageFlags'] = {'VkSubpassDependency': None, 'VkSubmitInfo': None, 'vkCmdWaitEvents': None, 'vkCmdResetEvent': None, 'vkCmdPipelineBarrier': None, 'VkPipelineStageFlagBits': None, 'vkCmdSetEvent': None}
mapDict['VkPipelineShaderStageCreateInfo'] = {'VkPipelineShaderStageCreateFlags': None, 'VkShaderStageFlagBits': None, 'VkShaderModule': None, 'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkComputePipelineCreateInfo': None, 'VkSpecializationInfo': None}
mapDict['VkPipelineStageFlagBits'] = {'vkCmdWriteTimestamp': None, 'VkPipelineStageFlags': None}
mapDict['VkPipelineStageFlags'] = {'VkSubmitInfo': None, 'vkCmdWaitEvents': None, 'VkSubpassDependency': None, 'vkCmdSetEvent': None, 'vkCmdPipelineBarrier': None, 'vkCmdResetEvent': None, 'VkPipelineStageFlagBits': None}
mapDict['VkPipelineTessellationStateCreateFlags'] = {'VkPipelineTessellationStateCreateInfo': None}
mapDict['VkPipelineTessellationStateCreateInfo'] = {'VkStructureType': None, 'VkPipelineTessellationStateCreateFlags': None, 'VkGraphicsPipelineCreateInfo': None}
mapDict['VkPipelineTessellationStateCreateInfo'] = {'VkGraphicsPipelineCreateInfo': None, 'VkPipelineTessellationStateCreateFlags': None, 'VkStructureType': None}
mapDict['VkPipelineVertexInputStateCreateFlags'] = {'VkPipelineVertexInputStateCreateInfo': None}
mapDict['VkPipelineVertexInputStateCreateInfo'] = {'VkVertexInputAttributeDescription': None, 'VkStructureType': None, 'VkVertexInputBindingDescription': None, 'VkGraphicsPipelineCreateInfo': None, 'VkPipelineVertexInputStateCreateFlags': None}
mapDict['VkPipelineVertexInputStateCreateInfo'] = {'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkVertexInputAttributeDescription': None, 'VkPipelineVertexInputStateCreateFlags': None, 'VkVertexInputBindingDescription': None}
mapDict['VkPipelineViewportStateCreateFlags'] = {'VkPipelineViewportStateCreateInfo': None}
mapDict['VkPipelineViewportStateCreateInfo'] = {'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkRect2D': None, 'VkPipelineViewportStateCreateFlags': None, 'VkViewport': None}
mapDict['VkPipelineViewportStateCreateInfo'] = {'VkViewport': None, 'VkGraphicsPipelineCreateInfo': None, 'VkStructureType': None, 'VkPipelineViewportStateCreateFlags': None, 'VkRect2D': None}
mapDict['VkPolygonMode'] = {'VkPipelineRasterizationStateCreateInfo': None}
mapDict['VkPrimitiveTopology'] = {'VkPipelineInputAssemblyStateCreateInfo': None}
mapDict['VkPushConstantRange'] = {'VkShaderStageFlags': None, 'VkPipelineLayoutCreateInfo': None}
mapDict['VkPushConstantRange'] = {'VkPipelineLayoutCreateInfo': None, 'VkShaderStageFlags': None}
mapDict['VkQueryControlFlagBits'] = {'VkQueryControlFlags': None}
mapDict['VkQueryControlFlags'] = {'VkQueryControlFlagBits': None, 'VkCommandBufferInheritanceInfo': None, 'vkCmdBeginQuery': None}
mapDict['VkQueryControlFlags'] = {'vkCmdBeginQuery': None, 'VkCommandBufferInheritanceInfo': None, 'VkQueryControlFlagBits': None}
mapDict['VkQueryPipelineStatisticFlagBits'] = {'VkQueryPipelineStatisticFlags': None}
mapDict['VkQueryPipelineStatisticFlags'] = {'VkQueryPoolCreateInfo': None, 'VkCommandBufferInheritanceInfo': None, 'VkQueryPipelineStatisticFlagBits': None}
mapDict['VkQueryPool'] = {'vkDestroyQueryPool': None, 'vkCmdResetQueryPool': None, 'vkCmdEndQuery': None, 'vkCmdBeginQuery': None, 'vkGetQueryPoolResults': None, 'vkCreateQueryPool': None, 'vkCmdCopyQueryPoolResults': None, 'vkCmdWriteTimestamp': None}
mapDict['VkQueryPipelineStatisticFlags'] = {'VkQueryPipelineStatisticFlagBits': None, 'VkCommandBufferInheritanceInfo': None, 'VkQueryPoolCreateInfo': None}
mapDict['VkQueryPool'] = {'vkCmdWriteTimestamp': None, 'vkCmdEndQuery': None, 'vkCmdBeginQuery': None, 'vkCmdCopyQueryPoolResults': None, 'vkCmdResetQueryPool': None, 'vkDestroyQueryPool': None, 'vkGetQueryPoolResults': None, 'vkCreateQueryPool': None}
mapDict['VkQueryPoolCreateFlags'] = {'VkQueryPoolCreateInfo': None}
mapDict['VkQueryPoolCreateInfo'] = {'VkQueryType': None, 'VkStructureType': None, 'VkQueryPoolCreateFlags': None, 'VkQueryPipelineStatisticFlags': None, 'vkCreateQueryPool': None}
mapDict['VkQueryPoolCreateInfo'] = {'VkQueryPoolCreateFlags': None, 'VkStructureType': None, 'vkCreateQueryPool': None, 'VkQueryPipelineStatisticFlags': None, 'VkQueryType': None}
mapDict['VkQueryResultFlagBits'] = {'VkQueryResultFlags': None}
mapDict['VkQueryResultFlags'] = {'VkQueryResultFlagBits': None, 'vkGetQueryPoolResults': None, 'vkCmdCopyQueryPoolResults': None}
mapDict['VkQueryResultFlags'] = {'vkCmdCopyQueryPoolResults': None, 'vkGetQueryPoolResults': None, 'VkQueryResultFlagBits': None}
mapDict['VkQueryType'] = {'VkQueryPoolCreateInfo': None}
mapDict['VkQueue'] = {'vkGetDeviceQueue': None, 'vkQueueWaitIdle': None, 'vkQueueBindSparse': None, 'vkQueueSubmit': None}
mapDict['VkQueueFamilyProperties'] = {'vkGetPhysicalDeviceQueueFamilyProperties': None, 'VkQueueFlags': None, 'VkExtent3D': None}
mapDict['VkQueue'] = {'vkQueueWaitIdle': None, 'vkQueueSubmit': None, 'vkGetDeviceQueue': None, 'vkQueueBindSparse': None}
mapDict['VkQueueFamilyProperties'] = {'VkExtent3D': None, 'VkQueueFlags': None, 'vkGetPhysicalDeviceQueueFamilyProperties': None}
mapDict['VkQueueFlagBits'] = {'VkQueueFlags': None}
mapDict['VkQueueFlags'] = {'VkQueueFamilyProperties': None, 'VkQueueFlagBits': None}
mapDict['VkRect2D'] = {'VkOffset2D': None, 'vkCmdSetScissor': None, 'VkExtent2D': None, 'VkClearRect': None, 'VkRenderPassBeginInfo': None, 'VkPipelineViewportStateCreateInfo': None}
mapDict['VkRenderPass'] = {'vkDestroyRenderPass': None, 'vkCreateRenderPass': None, 'VkGraphicsPipelineCreateInfo': None, 'VkFramebufferCreateInfo': None, 'vkGetRenderAreaGranularity': None, 'VkCommandBufferInheritanceInfo': None, 'VkRenderPassBeginInfo': None}
mapDict['VkRenderPassBeginInfo'] = {'VkRect2D': None, 'VkFramebuffer': None, 'vkCmdBeginRenderPass': None, 'VkStructureType': None, 'VkRenderPass': None, 'VkClearValue': None}
mapDict['VkQueueFlags'] = {'VkQueueFlagBits': None, 'VkQueueFamilyProperties': None}
mapDict['VkRect2D'] = {'VkOffset2D': None, 'VkExtent2D': None, 'VkRenderPassBeginInfo': None, 'VkClearRect': None, 'VkPipelineViewportStateCreateInfo': None, 'vkCmdSetScissor': None}
mapDict['VkRenderPass'] = {'vkGetRenderAreaGranularity': None, 'VkCommandBufferInheritanceInfo': None, 'VkFramebufferCreateInfo': None, 'VkGraphicsPipelineCreateInfo': None, 'vkDestroyRenderPass': None, 'vkCreateRenderPass': None, 'VkRenderPassBeginInfo': None}
mapDict['VkRenderPassBeginInfo'] = {'vkCmdBeginRenderPass': None, 'VkRect2D': None, 'VkFramebuffer': None, 'VkClearValue': None, 'VkStructureType': None, 'VkRenderPass': None}
mapDict['VkRenderPassCreateFlags'] = {'VkRenderPassCreateInfo': None}
mapDict['VkRenderPassCreateInfo'] = {'VkSubpassDependency': None, 'VkRenderPassCreateFlags': None, 'VkAttachmentDescription': None, 'VkStructureType': None, 'vkCreateRenderPass': None, 'VkSubpassDescription': None}
mapDict['VkSampleCountFlagBits'] = {'VkAttachmentDescription': None, 'VkPipelineMultisampleStateCreateInfo': None, 'VkImageCreateInfo': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'VkSampleCountFlags': None}
mapDict['VkSampleCountFlags'] = {'VkPhysicalDeviceLimits': None, 'VkImageFormatProperties': None, 'VkSampleCountFlagBits': None}
mapDict['VkRenderPassCreateInfo'] = {'VkSubpassDependency': None, 'VkRenderPassCreateFlags': None, 'VkSubpassDescription': None, 'VkStructureType': None, 'VkAttachmentDescription': None, 'vkCreateRenderPass': None}
mapDict['VkSampleCountFlagBits'] = {'VkPipelineMultisampleStateCreateInfo': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'VkSampleCountFlags': None, 'VkImageCreateInfo': None, 'VkAttachmentDescription': None}
mapDict['VkSampleCountFlags'] = {'VkSampleCountFlagBits': None, 'VkPhysicalDeviceLimits': None, 'VkImageFormatProperties': None}
mapDict['VkSampleMask'] = {'VkPipelineMultisampleStateCreateInfo': None}
mapDict['VkSampler'] = {'vkCreateSampler': None, 'vkDestroySampler': None, 'VkDescriptorImageInfo': None, 'VkDescriptorSetLayoutBinding': None}
mapDict['VkSampler'] = {'vkDestroySampler': None, 'VkDescriptorSetLayoutBinding': None, 'VkDescriptorImageInfo': None, 'vkCreateSampler': None}
mapDict['VkSamplerAddressMode'] = {'VkSamplerCreateInfo': None}
mapDict['VkSamplerCreateFlags'] = {'VkSamplerCreateInfo': None}
mapDict['VkSamplerCreateInfo'] = {'VkSamplerCreateFlags': None, 'vkCreateSampler': None, 'VkBorderColor': None, 'VkSamplerAddressMode': None, 'VkFilter': None, 'VkStructureType': None, 'VkSamplerMipmapMode': None, 'VkBool32': None, 'VkCompareOp': None}
mapDict['VkSamplerCreateInfo'] = {'VkCompareOp': None, 'VkSamplerCreateFlags': None, 'VkBool32': None, 'VkBorderColor': None, 'VkStructureType': None, 'VkSamplerAddressMode': None, 'VkFilter': None, 'vkCreateSampler': None, 'VkSamplerMipmapMode': None}
mapDict['VkSamplerMipmapMode'] = {'VkSamplerCreateInfo': None}
mapDict['VkSemaphore'] = {'vkCreateSemaphore': None, 'vkDestroySemaphore': None, 'VkSubmitInfo': None, 'VkBindSparseInfo': None}
mapDict['VkSemaphore'] = {'VkSubmitInfo': None, 'vkCreateSemaphore': None, 'VkBindSparseInfo': None, 'vkDestroySemaphore': None}
mapDict['VkSemaphoreCreateFlags'] = {'VkSemaphoreCreateInfo': None}
mapDict['VkSemaphoreCreateInfo'] = {'vkCreateSemaphore': None, 'VkStructureType': None, 'VkSemaphoreCreateFlags': None}
mapDict['VkShaderModule'] = {'vkDestroyShaderModule': None, 'VkPipelineShaderStageCreateInfo': None, 'vkCreateShaderModule': None}
mapDict['VkSemaphoreCreateInfo'] = {'VkStructureType': None, 'vkCreateSemaphore': None, 'VkSemaphoreCreateFlags': None}
mapDict['VkShaderModule'] = {'VkPipelineShaderStageCreateInfo': None, 'vkCreateShaderModule': None, 'vkDestroyShaderModule': None}
mapDict['VkShaderModuleCreateFlags'] = {'VkShaderModuleCreateInfo': None}
mapDict['VkShaderModuleCreateInfo'] = {'VkStructureType': None, 'VkShaderModuleCreateFlags': None, 'vkCreateShaderModule': None}
mapDict['VkShaderModuleCreateInfo'] = {'vkCreateShaderModule': None, 'VkStructureType': None, 'VkShaderModuleCreateFlags': None}
mapDict['VkShaderStageFlagBits'] = {'VkPipelineShaderStageCreateInfo': None, 'VkShaderStageFlags': None}
mapDict['VkShaderStageFlags'] = {'VkShaderStageFlagBits': None, 'VkPushConstantRange': None, 'VkDescriptorSetLayoutBinding': None, 'vkCmdPushConstants': None}
mapDict['VkShaderStageFlags'] = {'VkDescriptorSetLayoutBinding': None, 'VkShaderStageFlagBits': None, 'VkPushConstantRange': None, 'vkCmdPushConstants': None}
mapDict['VkSharingMode'] = {'VkBufferCreateInfo': None, 'VkImageCreateInfo': None}
mapDict['VkSparseBufferMemoryBindInfo'] = {'VkBuffer': None, 'VkBindSparseInfo': None, 'VkSparseMemoryBind': None}
mapDict['VkSparseBufferMemoryBindInfo'] = {'VkSparseMemoryBind': None, 'VkBindSparseInfo': None, 'VkBuffer': None}
mapDict['VkSparseImageFormatFlagBits'] = {'VkSparseImageFormatFlags': None}
mapDict['VkSparseImageFormatFlags'] = {'VkSparseImageFormatProperties': None, 'VkSparseImageFormatFlagBits': None}
mapDict['VkSparseImageFormatProperties'] = {'VkSparseImageFormatFlags': None, 'VkImageAspectFlags': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'VkSparseImageMemoryRequirements': None, 'VkExtent3D': None}
mapDict['VkSparseImageMemoryBind'] = {'VkSparseImageMemoryBindInfo': None, 'VkImageSubresource': None, 'VkSparseMemoryBindFlags': None, 'VkDeviceMemory': None, 'VkOffset3D': None, 'VkDeviceSize': None, 'VkExtent3D': None}
mapDict['VkSparseImageMemoryBindInfo'] = {'VkBindSparseInfo': None, 'VkSparseImageMemoryBind': None, 'VkImage': None}
mapDict['VkSparseImageFormatProperties'] = {'VkExtent3D': None, 'VkSparseImageFormatFlags': None, 'vkGetPhysicalDeviceSparseImageFormatProperties': None, 'VkImageAspectFlags': None, 'VkSparseImageMemoryRequirements': None}
mapDict['VkSparseImageMemoryBind'] = {'VkDeviceMemory': None, 'VkSparseImageMemoryBindInfo': None, 'VkOffset3D': None, 'VkExtent3D': None, 'VkDeviceSize': None, 'VkImageSubresource': None, 'VkSparseMemoryBindFlags': None}
mapDict['VkSparseImageMemoryBindInfo'] = {'VkSparseImageMemoryBind': None, 'VkImage': None, 'VkBindSparseInfo': None}
mapDict['VkSparseImageMemoryRequirements'] = {'VkSparseImageFormatProperties': None, 'vkGetImageSparseMemoryRequirements': None, 'VkDeviceSize': None}
mapDict['VkSparseImageOpaqueMemoryBindInfo'] = {'VkBindSparseInfo': None, 'VkSparseMemoryBind': None, 'VkImage': None}
mapDict['VkSparseMemoryBind'] = {'VkSparseImageOpaqueMemoryBindInfo': None, 'VkDeviceMemory': None, 'VkSparseMemoryBindFlags': None, 'VkDeviceSize': None, 'VkSparseBufferMemoryBindInfo': None}
mapDict['VkSparseImageOpaqueMemoryBindInfo'] = {'VkSparseMemoryBind': None, 'VkImage': None, 'VkBindSparseInfo': None}
mapDict['VkSparseMemoryBind'] = {'VkDeviceMemory': None, 'VkSparseImageOpaqueMemoryBindInfo': None, 'VkDeviceSize': None, 'VkSparseMemoryBindFlags': None, 'VkSparseBufferMemoryBindInfo': None}
mapDict['VkSparseMemoryBindFlagBits'] = {'VkSparseMemoryBindFlags': None}
mapDict['VkSparseMemoryBindFlags'] = {'VkSparseMemoryBindFlagBits': None, 'VkSparseImageMemoryBind': None, 'VkSparseMemoryBind': None}
mapDict['VkSparseMemoryBindFlags'] = {'VkSparseMemoryBind': None, 'VkSparseImageMemoryBind': None, 'VkSparseMemoryBindFlagBits': None}
mapDict['VkSpecializationInfo'] = {'VkPipelineShaderStageCreateInfo': None, 'VkSpecializationMapEntry': None}
mapDict['VkSpecializationMapEntry'] = {'VkSpecializationInfo': None}
mapDict['VkStencilFaceFlagBits'] = {'VkStencilFaceFlags': None}
mapDict['VkStencilFaceFlags'] = {'vkCmdSetStencilWriteMask': None, 'VkStencilFaceFlagBits': None, 'vkCmdSetStencilReference': None, 'vkCmdSetStencilCompareMask': None}
mapDict['VkStencilFaceFlags'] = {'vkCmdSetStencilWriteMask': None, 'vkCmdSetStencilReference': None, 'VkStencilFaceFlagBits': None, 'vkCmdSetStencilCompareMask': None}
mapDict['VkStencilOp'] = {'VkStencilOpState': None}
mapDict['VkStencilOpState'] = {'VkStencilOp': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkCompareOp': None}
mapDict['VkStructureType'] = {'VkPipelineMultisampleStateCreateInfo': None, 'VkFramebufferCreateInfo': None, 'VkDescriptorSetLayoutCreateInfo': None, 'VkImageViewCreateInfo': None, 'VkApplicationInfo': None, 'VkImageMemoryBarrier': None, 'VkMemoryAllocateInfo': None, 'VkPipelineVertexInputStateCreateInfo': None, 'VkEventCreateInfo': None, 'VkCommandPoolCreateInfo': None, 'VkBufferMemoryBarrier': None, 'VkPipelineColorBlendStateCreateInfo': None, 'VkWriteDescriptorSet': None, 'VkDeviceQueueCreateInfo': None, 'VkRenderPassBeginInfo': None, 'VkSemaphoreCreateInfo': None, 'VkPipelineInputAssemblyStateCreateInfo': None, 'VkPipelineRasterizationStateCreateInfo': None, 'VkBufferCreateInfo': None, 'VkSubmitInfo': None, 'VkCommandBufferAllocateInfo': None, 'VkPipelineViewportStateCreateInfo': None, 'VkPipelineShaderStageCreateInfo': None, 'VkPipelineTessellationStateCreateInfo': None, 'VkDescriptorPoolCreateInfo': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkPipelineDynamicStateCreateInfo': None, 'VkFenceCreateInfo': None, 'VkBufferViewCreateInfo': None, 'VkMappedMemoryRange': None, 'VkCommandBufferBeginInfo': None, 'VkPipelineLayoutCreateInfo': None, 'VkMemoryBarrier': None, 'VkCommandBufferInheritanceInfo': None, 'VkDescriptorSetAllocateInfo': None, 'VkImageCreateInfo': None, 'VkPipelineCacheCreateInfo': None, 'VkComputePipelineCreateInfo': None, 'VkGraphicsPipelineCreateInfo': None, 'VkBindSparseInfo': None, 'VkQueryPoolCreateInfo': None, 'VkCopyDescriptorSet': None, 'VkInstanceCreateInfo': None, 'VkRenderPassCreateInfo': None, 'VkDeviceCreateInfo': None, 'VkSamplerCreateInfo': None, 'VkShaderModuleCreateInfo': None}
mapDict['VkSubmitInfo'] = {'VkPipelineStageFlags': None, 'VkStructureType': None, 'VkCommandBuffer': None, 'VkSemaphore': None, 'vkQueueSubmit': None}
mapDict['VkStencilOpState'] = {'VkCompareOp': None, 'VkStencilOp': None, 'VkPipelineDepthStencilStateCreateInfo': None}
mapDict['VkStructureType'] = {'VkPipelineCacheCreateInfo': None, 'VkRenderPassBeginInfo': None, 'VkDeviceQueueCreateInfo': None, 'VkWriteDescriptorSet': None, 'VkBufferCreateInfo': None, 'VkImageCreateInfo': None, 'VkShaderModuleCreateInfo': None, 'VkSamplerCreateInfo': None, 'VkMemoryBarrier': None, 'VkPipelineShaderStageCreateInfo': None, 'VkDescriptorSetLayoutCreateInfo': None, 'VkFenceCreateInfo': None, 'VkQueryPoolCreateInfo': None, 'VkBufferMemoryBarrier': None, 'VkImageViewCreateInfo': None, 'VkPipelineVertexInputStateCreateInfo': None, 'VkPipelineTessellationStateCreateInfo': None, 'VkGraphicsPipelineCreateInfo': None, 'VkDeviceCreateInfo': None, 'VkPipelineColorBlendStateCreateInfo': None, 'VkMemoryAllocateInfo': None, 'VkInstanceCreateInfo': None, 'VkCommandBufferInheritanceInfo': None, 'VkFramebufferCreateInfo': None, 'VkDescriptorPoolCreateInfo': None, 'VkPipelineMultisampleStateCreateInfo': None, 'VkPipelineDynamicStateCreateInfo': None, 'VkPipelineInputAssemblyStateCreateInfo': None, 'VkCopyDescriptorSet': None, 'VkPipelineDepthStencilStateCreateInfo': None, 'VkPipelineViewportStateCreateInfo': None, 'VkBufferViewCreateInfo': None, 'VkPipelineRasterizationStateCreateInfo': None, 'VkComputePipelineCreateInfo': None, 'VkImageMemoryBarrier': None, 'VkRenderPassCreateInfo': None, 'VkSemaphoreCreateInfo': None, 'VkApplicationInfo': None, 'VkCommandPoolCreateInfo': None, 'VkPipelineLayoutCreateInfo': None, 'VkCommandBufferBeginInfo': None, 'VkCommandBufferAllocateInfo': None, 'VkEventCreateInfo': None, 'VkMappedMemoryRange': None, 'VkBindSparseInfo': None, 'VkSubmitInfo': None, 'VkDescriptorSetAllocateInfo': None}
mapDict['VkSubmitInfo'] = {'vkQueueSubmit': None, 'VkStructureType': None, 'VkCommandBuffer': None, 'VkSemaphore': None, 'VkPipelineStageFlags': None}
mapDict['VkSubpassContents'] = {'vkCmdBeginRenderPass': None, 'vkCmdNextSubpass': None}
mapDict['VkSubpassDependency'] = {'VkRenderPassCreateInfo': None, 'VkPipelineStageFlags': None, 'VkDependencyFlags': None, 'VkAccessFlags': None}
mapDict['VkSubpassDescription'] = {'VkRenderPassCreateInfo': None, 'VkPipelineBindPoint': None, 'VkSubpassDescriptionFlags': None, 'VkAttachmentReference': None}
mapDict['VkSubpassDependency'] = {'VkDependencyFlags': None, 'VkAccessFlags': None, 'VkPipelineStageFlags': None, 'VkRenderPassCreateInfo': None}
mapDict['VkSubpassDescription'] = {'VkRenderPassCreateInfo': None, 'VkSubpassDescriptionFlags': None, 'VkPipelineBindPoint': None, 'VkAttachmentReference': None}
mapDict['VkSubpassDescriptionFlags'] = {'VkSubpassDescription': None}
mapDict['VkSubresourceLayout'] = {'vkGetImageSubresourceLayout': None, 'VkDeviceSize': None}
mapDict['VkVertexInputAttributeDescription'] = {'VkFormat': None, 'VkPipelineVertexInputStateCreateInfo': None}
mapDict['VkVertexInputBindingDescription'] = {'VkVertexInputRate': None, 'VkPipelineVertexInputStateCreateInfo': None}
mapDict['VkSubresourceLayout'] = {'VkDeviceSize': None, 'vkGetImageSubresourceLayout': None}
mapDict['VkVertexInputAttributeDescription'] = {'VkPipelineVertexInputStateCreateInfo': None, 'VkFormat': None}
mapDict['VkVertexInputBindingDescription'] = {'VkPipelineVertexInputStateCreateInfo': None, 'VkVertexInputRate': None}
mapDict['VkVertexInputRate'] = {'VkVertexInputBindingDescription': None}
mapDict['VkViewport'] = {'vkCmdSetViewport': None, 'VkPipelineViewportStateCreateInfo': None}
mapDict['VkWriteDescriptorSet'] = {'vkUpdateDescriptorSets': None, 'VkDescriptorBufferInfo': None, 'VkDescriptorSet': None, 'VkBufferView': None, 'VkDescriptorType': None, 'VkStructureType': None, 'VkDescriptorImageInfo': None}
mapDict['vkAllocateCommandBuffers'] = {'VkDevice': None, 'VkCommandBuffer': None, 'VkCommandBufferAllocateInfo': None}
mapDict['vkAllocateDescriptorSets'] = {'VkDevice': None, 'VkDescriptorSetAllocateInfo': None, 'VkDescriptorSet': None}
mapDict['vkAllocateMemory'] = {'VkDevice': None, 'VkDeviceMemory': None, 'VkAllocationCallbacks': None, 'VkMemoryAllocateInfo': None}
mapDict['VkWriteDescriptorSet'] = {'VkDescriptorBufferInfo': None, 'VkDescriptorImageInfo': None, 'vkUpdateDescriptorSets': None, 'VkStructureType': None, 'VkDescriptorSet': None, 'VkDescriptorType': None, 'VkBufferView': None}
mapDict['vkAllocateCommandBuffers'] = {'VkDevice': None, 'VkCommandBufferAllocateInfo': None, 'VkCommandBuffer': None}
mapDict['vkAllocateDescriptorSets'] = {'VkDevice': None, 'VkDescriptorSet': None, 'VkDescriptorSetAllocateInfo': None}
mapDict['vkAllocateMemory'] = {'VkDeviceMemory': None, 'VkDevice': None, 'VkMemoryAllocateInfo': None, 'VkAllocationCallbacks': None}
mapDict['vkBeginCommandBuffer'] = {'VkCommandBuffer': None, 'VkCommandBufferBeginInfo': None}
mapDict['vkBindBufferMemory'] = {'VkBuffer': None, 'VkDevice': None, 'VkDeviceMemory': None, 'VkDeviceSize': None}
mapDict['vkBindImageMemory'] = {'VkDevice': None, 'VkDeviceMemory': None, 'VkDeviceSize': None, 'VkImage': None}
mapDict['vkCmdBeginQuery'] = {'VkQueryPool': None, 'VkQueryControlFlags': None, 'VkCommandBuffer': None}
mapDict['vkBindBufferMemory'] = {'VkDeviceMemory': None, 'VkDevice': None, 'VkDeviceSize': None, 'VkBuffer': None}
mapDict['vkBindImageMemory'] = {'VkDeviceMemory': None, 'VkDevice': None, 'VkImage': None, 'VkDeviceSize': None}
mapDict['vkCmdBeginQuery'] = {'VkQueryControlFlags': None, 'VkQueryPool': None, 'VkCommandBuffer': None}
mapDict['vkCmdBeginRenderPass'] = {'VkSubpassContents': None, 'VkCommandBuffer': None, 'VkRenderPassBeginInfo': None}
mapDict['vkCmdBindDescriptorSets'] = {'VkPipelineBindPoint': None, 'VkCommandBuffer': None, 'VkDescriptorSet': None, 'VkPipelineLayout': None}
mapDict['vkCmdBindIndexBuffer'] = {'VkBuffer': None, 'VkCommandBuffer': None, 'VkIndexType': None, 'VkDeviceSize': None}
mapDict['vkCmdBindDescriptorSets'] = {'VkDescriptorSet': None, 'VkPipelineLayout': None, 'VkPipelineBindPoint': None, 'VkCommandBuffer': None}
mapDict['vkCmdBindIndexBuffer'] = {'VkDeviceSize': None, 'VkIndexType': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdBindPipeline'] = {'VkPipelineBindPoint': None, 'VkCommandBuffer': None, 'VkPipeline': None}
mapDict['vkCmdBindVertexBuffers'] = {'VkBuffer': None, 'VkCommandBuffer': None, 'VkDeviceSize': None}
mapDict['vkCmdBlitImage'] = {'VkImageBlit': None, 'VkImageLayout': None, 'VkCommandBuffer': None, 'VkFilter': None, 'VkImage': None}
mapDict['vkCmdClearAttachments'] = {'VkClearRect': None, 'VkClearAttachment': None, 'VkCommandBuffer': None}
mapDict['vkCmdClearColorImage'] = {'VkImageLayout': None, 'VkCommandBuffer': None, 'VkClearColorValue': None, 'VkImageSubresourceRange': None, 'VkImage': None}
mapDict['vkCmdClearDepthStencilImage'] = {'VkImageLayout': None, 'VkCommandBuffer': None, 'VkClearDepthStencilValue': None, 'VkImageSubresourceRange': None, 'VkImage': None}
mapDict['vkCmdCopyBuffer'] = {'VkBuffer': None, 'VkBufferCopy': None, 'VkCommandBuffer': None}
mapDict['vkCmdCopyBufferToImage'] = {'VkBuffer': None, 'VkImageLayout': None, 'VkCommandBuffer': None, 'VkBufferImageCopy': None, 'VkImage': None}
mapDict['vkCmdCopyImage'] = {'VkImageCopy': None, 'VkImageLayout': None, 'VkCommandBuffer': None, 'VkImage': None}
mapDict['vkCmdCopyImageToBuffer'] = {'VkBuffer': None, 'VkImageLayout': None, 'VkCommandBuffer': None, 'VkBufferImageCopy': None, 'VkImage': None}
mapDict['vkCmdCopyQueryPoolResults'] = {'VkQueryPool': None, 'VkBuffer': None, 'VkCommandBuffer': None, 'VkDeviceSize': None, 'VkQueryResultFlags': None}
mapDict['vkCmdBindVertexBuffers'] = {'VkDeviceSize': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdBlitImage'] = {'VkImage': None, 'VkFilter': None, 'VkImageBlit': None, 'VkCommandBuffer': None, 'VkImageLayout': None}
mapDict['vkCmdClearAttachments'] = {'VkClearAttachment': None, 'VkClearRect': None, 'VkCommandBuffer': None}
mapDict['vkCmdClearColorImage'] = {'VkImage': None, 'VkClearColorValue': None, 'VkCommandBuffer': None, 'VkImageSubresourceRange': None, 'VkImageLayout': None}
mapDict['vkCmdClearDepthStencilImage'] = {'VkClearDepthStencilValue': None, 'VkImage': None, 'VkImageSubresourceRange': None, 'VkCommandBuffer': None, 'VkImageLayout': None}
mapDict['vkCmdCopyBuffer'] = {'VkBufferCopy': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdCopyBufferToImage'] = {'VkBufferImageCopy': None, 'VkImage': None, 'VkCommandBuffer': None, 'VkBuffer': None, 'VkImageLayout': None}
mapDict['vkCmdCopyImage'] = {'VkImage': None, 'VkImageCopy': None, 'VkCommandBuffer': None, 'VkImageLayout': None}
mapDict['vkCmdCopyImageToBuffer'] = {'VkBufferImageCopy': None, 'VkImage': None, 'VkCommandBuffer': None, 'VkBuffer': None, 'VkImageLayout': None}
mapDict['vkCmdCopyQueryPoolResults'] = {'VkDeviceSize': None, 'VkQueryPool': None, 'VkCommandBuffer': None, 'VkQueryResultFlags': None, 'VkBuffer': None}
mapDict['vkCmdDispatch'] = {'VkCommandBuffer': None}
mapDict['vkCmdDispatchIndirect'] = {'VkBuffer': None, 'VkCommandBuffer': None, 'VkDeviceSize': None}
mapDict['vkCmdDispatchIndirect'] = {'VkDeviceSize': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdDraw'] = {'VkCommandBuffer': None}
mapDict['vkCmdDrawIndexed'] = {'VkCommandBuffer': None}
mapDict['vkCmdDrawIndexedIndirect'] = {'VkBuffer': None, 'VkCommandBuffer': None, 'VkDeviceSize': None}
mapDict['vkCmdDrawIndirect'] = {'VkBuffer': None, 'VkCommandBuffer': None, 'VkDeviceSize': None}
mapDict['vkCmdDrawIndexedIndirect'] = {'VkDeviceSize': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdDrawIndirect'] = {'VkDeviceSize': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdEndQuery'] = {'VkQueryPool': None, 'VkCommandBuffer': None}
mapDict['vkCmdEndRenderPass'] = {'VkCommandBuffer': None}
mapDict['vkCmdExecuteCommands'] = {'VkCommandBuffer': None}
mapDict['vkCmdFillBuffer'] = {'VkBuffer': None, 'VkCommandBuffer': None, 'VkDeviceSize': None}
mapDict['vkCmdFillBuffer'] = {'VkDeviceSize': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdNextSubpass'] = {'VkSubpassContents': None, 'VkCommandBuffer': None}
mapDict['vkCmdPipelineBarrier'] = {'VkImageMemoryBarrier': None, 'VkBufferMemoryBarrier': None, 'VkPipelineStageFlags': None, 'VkCommandBuffer': None, 'VkDependencyFlags': None, 'VkMemoryBarrier': None}
mapDict['vkCmdPushConstants'] = {'VkShaderStageFlags': None, 'VkCommandBuffer': None, 'VkPipelineLayout': None}
mapDict['vkCmdResetEvent'] = {'VkPipelineStageFlags': None, 'VkCommandBuffer': None, 'VkEvent': None}
mapDict['vkCmdPipelineBarrier'] = {'VkPipelineStageFlags': None, 'VkMemoryBarrier': None, 'VkBufferMemoryBarrier': None, 'VkDependencyFlags': None, 'VkCommandBuffer': None, 'VkImageMemoryBarrier': None}
mapDict['vkCmdPushConstants'] = {'VkPipelineLayout': None, 'VkCommandBuffer': None, 'VkShaderStageFlags': None}
mapDict['vkCmdResetEvent'] = {'VkEvent': None, 'VkCommandBuffer': None, 'VkPipelineStageFlags': None}
mapDict['vkCmdResetQueryPool'] = {'VkQueryPool': None, 'VkCommandBuffer': None}
mapDict['vkCmdResolveImage'] = {'VkImageLayout': None, 'VkCommandBuffer': None, 'VkImageResolve': None, 'VkImage': None}
mapDict['vkCmdResolveImage'] = {'VkImage': None, 'VkCommandBuffer': None, 'VkImageResolve': None, 'VkImageLayout': None}
mapDict['vkCmdSetBlendConstants'] = {'VkCommandBuffer': None}
mapDict['vkCmdSetDepthBias'] = {'VkCommandBuffer': None}
mapDict['vkCmdSetDepthBounds'] = {'VkCommandBuffer': None}
mapDict['vkCmdSetEvent'] = {'VkPipelineStageFlags': None, 'VkCommandBuffer': None, 'VkEvent': None}
mapDict['vkCmdSetEvent'] = {'VkEvent': None, 'VkCommandBuffer': None, 'VkPipelineStageFlags': None}
mapDict['vkCmdSetLineWidth'] = {'VkCommandBuffer': None}
mapDict['vkCmdSetScissor'] = {'VkCommandBuffer': None, 'VkRect2D': None}
mapDict['vkCmdSetStencilCompareMask'] = {'VkCommandBuffer': None, 'VkStencilFaceFlags': None}
mapDict['vkCmdSetStencilReference'] = {'VkCommandBuffer': None, 'VkStencilFaceFlags': None}
mapDict['vkCmdSetStencilWriteMask'] = {'VkCommandBuffer': None, 'VkStencilFaceFlags': None}
mapDict['vkCmdSetViewport'] = {'VkCommandBuffer': None, 'VkViewport': None}
mapDict['vkCmdUpdateBuffer'] = {'VkBuffer': None, 'VkCommandBuffer': None, 'VkDeviceSize': None}
mapDict['vkCmdWaitEvents'] = {'VkImageMemoryBarrier': None, 'VkBufferMemoryBarrier': None, 'VkEvent': None, 'VkPipelineStageFlags': None, 'VkCommandBuffer': None, 'VkMemoryBarrier': None}
mapDict['vkCmdSetScissor'] = {'VkRect2D': None, 'VkCommandBuffer': None}
mapDict['vkCmdSetStencilCompareMask'] = {'VkStencilFaceFlags': None, 'VkCommandBuffer': None}
mapDict['vkCmdSetStencilReference'] = {'VkStencilFaceFlags': None, 'VkCommandBuffer': None}
mapDict['vkCmdSetStencilWriteMask'] = {'VkStencilFaceFlags': None, 'VkCommandBuffer': None}
mapDict['vkCmdSetViewport'] = {'VkViewport': None, 'VkCommandBuffer': None}
mapDict['vkCmdUpdateBuffer'] = {'VkDeviceSize': None, 'VkCommandBuffer': None, 'VkBuffer': None}
mapDict['vkCmdWaitEvents'] = {'VkPipelineStageFlags': None, 'VkMemoryBarrier': None, 'VkBufferMemoryBarrier': None, 'VkEvent': None, 'VkCommandBuffer': None, 'VkImageMemoryBarrier': None}
mapDict['vkCmdWriteTimestamp'] = {'VkQueryPool': None, 'VkCommandBuffer': None, 'VkPipelineStageFlagBits': None}
mapDict['vkCreateBuffer'] = {'VkBuffer': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkBufferCreateInfo': None}
mapDict['vkCreateBufferView'] = {'VkDevice': None, 'VkBufferView': None, 'VkAllocationCallbacks': None, 'VkBufferViewCreateInfo': None}
mapDict['vkCreateCommandPool'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkCommandPoolCreateInfo': None, 'VkCommandPool': None}
mapDict['vkCreateComputePipelines'] = {'VkDevice': None, 'VkPipeline': None, 'VkAllocationCallbacks': None, 'VkPipelineCache': None, 'VkComputePipelineCreateInfo': None}
mapDict['vkCreateBuffer'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkBufferCreateInfo': None, 'VkBuffer': None}
mapDict['vkCreateBufferView'] = {'VkDevice': None, 'VkBufferViewCreateInfo': None, 'VkAllocationCallbacks': None, 'VkBufferView': None}
mapDict['vkCreateCommandPool'] = {'VkCommandPool': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkCommandPoolCreateInfo': None}
mapDict['vkCreateComputePipelines'] = {'VkDevice': None, 'VkComputePipelineCreateInfo': None, 'VkPipelineCache': None, 'VkAllocationCallbacks': None, 'VkPipeline': None}
mapDict['vkCreateDescriptorPool'] = {'VkDevice': None, 'VkDescriptorPoolCreateInfo': None, 'VkAllocationCallbacks': None, 'VkDescriptorPool': None}
mapDict['vkCreateDescriptorSetLayout'] = {'VkDescriptorSetLayout': None, 'VkDevice': None, 'VkDescriptorSetLayoutCreateInfo': None, 'VkAllocationCallbacks': None}
mapDict['vkCreateDevice'] = {'VkDeviceCreateInfo': None, 'VkAllocationCallbacks': None, 'VkPhysicalDevice': None, 'VkDevice': None}
mapDict['vkCreateEvent'] = {'VkDevice': None, 'VkEvent': None, 'VkAllocationCallbacks': None, 'VkEventCreateInfo': None}
mapDict['vkCreateFence'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkFence': None, 'VkFenceCreateInfo': None}
mapDict['vkCreateFramebuffer'] = {'VkFramebufferCreateInfo': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkFramebuffer': None}
mapDict['vkCreateGraphicsPipelines'] = {'VkDevice': None, 'VkPipeline': None, 'VkAllocationCallbacks': None, 'VkPipelineCache': None, 'VkGraphicsPipelineCreateInfo': None}
mapDict['vkCreateImage'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkImageCreateInfo': None, 'VkImage': None}
mapDict['vkCreateImageView'] = {'VkDevice': None, 'VkImageView': None, 'VkAllocationCallbacks': None, 'VkImageViewCreateInfo': None}
mapDict['vkCreateInstance'] = {'VkInstance': None, 'VkAllocationCallbacks': None, 'VkInstanceCreateInfo': None}
mapDict['vkCreatePipelineCache'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkPipelineCacheCreateInfo': None, 'VkPipelineCache': None}
mapDict['vkCreatePipelineLayout'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkPipelineLayoutCreateInfo': None, 'VkPipelineLayout': None}
mapDict['vkCreateQueryPool'] = {'VkQueryPool': None, 'VkDevice': None, 'VkQueryPoolCreateInfo': None, 'VkAllocationCallbacks': None}
mapDict['vkCreateRenderPass'] = {'VkRenderPassCreateInfo': None, 'VkDevice': None, 'VkRenderPass': None, 'VkAllocationCallbacks': None}
mapDict['vkCreateSampler'] = {'VkDevice': None, 'VkSamplerCreateInfo': None, 'VkAllocationCallbacks': None, 'VkSampler': None}
mapDict['vkCreateSemaphore'] = {'VkSemaphoreCreateInfo': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkSemaphore': None}
mapDict['vkCreateShaderModule'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkShaderModuleCreateInfo': None, 'VkShaderModule': None}
mapDict['vkDestroyBuffer'] = {'VkBuffer': None, 'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkCreateDescriptorSetLayout'] = {'VkDescriptorSetLayoutCreateInfo': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkDescriptorSetLayout': None}
mapDict['vkCreateDevice'] = {'VkDeviceCreateInfo': None, 'VkPhysicalDevice': None, 'VkAllocationCallbacks': None, 'VkDevice': None}
mapDict['vkCreateEvent'] = {'VkEventCreateInfo': None, 'VkEvent': None, 'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkCreateFence'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkFence': None, 'VkFenceCreateInfo': None}
mapDict['vkCreateFramebuffer'] = {'VkFramebuffer': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkFramebufferCreateInfo': None}
mapDict['vkCreateGraphicsPipelines'] = {'VkGraphicsPipelineCreateInfo': None, 'VkDevice': None, 'VkPipelineCache': None, 'VkAllocationCallbacks': None, 'VkPipeline': None}
mapDict['vkCreateImage'] = {'VkDevice': None, 'VkImage': None, 'VkAllocationCallbacks': None, 'VkImageCreateInfo': None}
mapDict['vkCreateImageView'] = {'VkImageViewCreateInfo': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkImageView': None}
mapDict['vkCreateInstance'] = {'VkInstanceCreateInfo': None, 'VkAllocationCallbacks': None, 'VkInstance': None}
mapDict['vkCreatePipelineCache'] = {'VkPipelineCacheCreateInfo': None, 'VkDevice': None, 'VkPipelineCache': None, 'VkAllocationCallbacks': None}
mapDict['vkCreatePipelineLayout'] = {'VkPipelineLayoutCreateInfo': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkPipelineLayout': None}
mapDict['vkCreateQueryPool'] = {'VkDevice': None, 'VkQueryPool': None, 'VkAllocationCallbacks': None, 'VkQueryPoolCreateInfo': None}
mapDict['vkCreateRenderPass'] = {'VkDevice': None, 'VkRenderPass': None, 'VkAllocationCallbacks': None, 'VkRenderPassCreateInfo': None}
mapDict['vkCreateSampler'] = {'VkSampler': None, 'VkDevice': None, 'VkSamplerCreateInfo': None, 'VkAllocationCallbacks': None}
mapDict['vkCreateSemaphore'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkSemaphoreCreateInfo': None, 'VkSemaphore': None}
mapDict['vkCreateShaderModule'] = {'VkShaderModuleCreateInfo': None, 'VkDevice': None, 'VkAllocationCallbacks': None, 'VkShaderModule': None}
mapDict['vkDestroyBuffer'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkBuffer': None}
mapDict['vkDestroyBufferView'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkBufferView': None}
mapDict['vkDestroyCommandPool'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkCommandPool': None}
mapDict['vkDestroyDescriptorPool'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkDescriptorPool': None}
mapDict['vkDestroyDescriptorSetLayout'] = {'VkDescriptorSetLayout': None, 'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyCommandPool'] = {'VkCommandPool': None, 'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyDescriptorPool'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkDescriptorPool': None}
mapDict['vkDestroyDescriptorSetLayout'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkDescriptorSetLayout': None}
mapDict['vkDestroyDevice'] = {'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyEvent'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkEvent': None}
mapDict['vkDestroyFence'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkFence': None}
mapDict['vkDestroyFramebuffer'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkFramebuffer': None}
mapDict['vkDestroyImage'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkImage': None}
mapDict['vkDestroyImageView'] = {'VkDevice': None, 'VkImageView': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyInstance'] = {'VkInstance': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyEvent'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkEvent': None}
mapDict['vkDestroyFence'] = {'VkDevice': None, 'VkFence': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyFramebuffer'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkFramebuffer': None}
mapDict['vkDestroyImage'] = {'VkDevice': None, 'VkImage': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyImageView'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkImageView': None}
mapDict['vkDestroyInstance'] = {'VkAllocationCallbacks': None, 'VkInstance': None}
mapDict['vkDestroyPipeline'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkPipeline': None}
mapDict['vkDestroyPipelineCache'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkPipelineCache': None}
mapDict['vkDestroyPipelineLayout'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkPipelineLayout': None}
mapDict['vkDestroyQueryPool'] = {'VkQueryPool': None, 'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyRenderPass'] = {'VkDevice': None, 'VkRenderPass': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroySampler'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkSampler': None}
mapDict['vkDestroySemaphore'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkSemaphore': None}
mapDict['vkDestroyShaderModule'] = {'VkDevice': None, 'VkAllocationCallbacks': None, 'VkShaderModule': None}
mapDict['vkDestroyPipelineCache'] = {'VkDevice': None, 'VkPipelineCache': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyPipelineLayout'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkPipelineLayout': None}
mapDict['vkDestroyQueryPool'] = {'VkDevice': None, 'VkQueryPool': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroyRenderPass'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkRenderPass': None}
mapDict['vkDestroySampler'] = {'VkSampler': None, 'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkDestroySemaphore'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkSemaphore': None}
mapDict['vkDestroyShaderModule'] = {'VkAllocationCallbacks': None, 'VkDevice': None, 'VkShaderModule': None}
mapDict['vkDeviceWaitIdle'] = {'VkDevice': None}
mapDict['vkEndCommandBuffer'] = {'VkCommandBuffer': None}
mapDict['vkEnumerateDeviceExtensionProperties'] = {'VkExtensionProperties': None, 'VkPhysicalDevice': None}
mapDict['vkEnumerateDeviceLayerProperties'] = {'VkLayerProperties': None, 'VkPhysicalDevice': None}
mapDict['vkEnumerateDeviceExtensionProperties'] = {'VkPhysicalDevice': None, 'VkExtensionProperties': None}
mapDict['vkEnumerateDeviceLayerProperties'] = {'VkPhysicalDevice': None, 'VkLayerProperties': None}
mapDict['vkEnumerateInstanceExtensionProperties'] = {'VkExtensionProperties': None}
mapDict['vkEnumerateInstanceLayerProperties'] = {'VkLayerProperties': None}
mapDict['vkEnumeratePhysicalDevices'] = {'VkInstance': None, 'VkPhysicalDevice': None}
mapDict['vkEnumeratePhysicalDevices'] = {'VkPhysicalDevice': None, 'VkInstance': None}
mapDict['vkFlushMappedMemoryRanges'] = {'VkDevice': None, 'VkMappedMemoryRange': None}
mapDict['vkFreeCommandBuffers'] = {'VkDevice': None, 'VkCommandBuffer': None, 'VkCommandPool': None}
mapDict['vkFreeCommandBuffers'] = {'VkCommandPool': None, 'VkDevice': None, 'VkCommandBuffer': None}
mapDict['vkFreeDescriptorSets'] = {'VkDevice': None, 'VkDescriptorSet': None, 'VkDescriptorPool': None}
mapDict['vkFreeMemory'] = {'VkDevice': None, 'VkDeviceMemory': None, 'VkAllocationCallbacks': None}
mapDict['vkGetBufferMemoryRequirements'] = {'VkBuffer': None, 'VkDevice': None, 'VkMemoryRequirements': None}
mapDict['vkGetDeviceMemoryCommitment'] = {'VkDevice': None, 'VkDeviceMemory': None, 'VkDeviceSize': None}
mapDict['vkFreeMemory'] = {'VkDeviceMemory': None, 'VkDevice': None, 'VkAllocationCallbacks': None}
mapDict['vkGetBufferMemoryRequirements'] = {'VkDevice': None, 'VkMemoryRequirements': None, 'VkBuffer': None}
mapDict['vkGetDeviceMemoryCommitment'] = {'VkDeviceMemory': None, 'VkDevice': None, 'VkDeviceSize': None}
mapDict['vkGetDeviceProcAddr'] = {'VkDevice': None}
mapDict['vkGetDeviceQueue'] = {'VkDevice': None, 'VkQueue': None}
mapDict['vkGetDeviceQueue'] = {'VkQueue': None, 'VkDevice': None}
mapDict['vkGetEventStatus'] = {'VkDevice': None, 'VkEvent': None}
mapDict['vkGetFenceStatus'] = {'VkDevice': None, 'VkFence': None}
mapDict['vkGetImageMemoryRequirements'] = {'VkDevice': None, 'VkMemoryRequirements': None, 'VkImage': None}
mapDict['vkGetImageSparseMemoryRequirements'] = {'VkDevice': None, 'VkSparseImageMemoryRequirements': None, 'VkImage': None}
mapDict['vkGetImageSubresourceLayout'] = {'VkDevice': None, 'VkSubresourceLayout': None, 'VkImageSubresource': None, 'VkImage': None}
mapDict['vkGetImageMemoryRequirements'] = {'VkDevice': None, 'VkImage': None, 'VkMemoryRequirements': None}
mapDict['vkGetImageSparseMemoryRequirements'] = {'VkDevice': None, 'VkImage': None, 'VkSparseImageMemoryRequirements': None}
mapDict['vkGetImageSubresourceLayout'] = {'VkDevice': None, 'VkImage': None, 'VkImageSubresource': None, 'VkSubresourceLayout': None}
mapDict['vkGetInstanceProcAddr'] = {'VkInstance': None}
mapDict['vkGetPhysicalDeviceFeatures'] = {'VkPhysicalDeviceFeatures': None, 'VkPhysicalDevice': None}
mapDict['vkGetPhysicalDeviceFormatProperties'] = {'VkFormatProperties': None, 'VkFormat': None, 'VkPhysicalDevice': None}
mapDict['vkGetPhysicalDeviceImageFormatProperties'] = {'VkFormat': None, 'VkImageTiling': None, 'VkImageUsageFlags': None, 'VkImageFormatProperties': None, 'VkPhysicalDevice': None, 'VkImageCreateFlags': None, 'VkImageType': None}
mapDict['vkGetPhysicalDeviceMemoryProperties'] = {'VkPhysicalDevice': None, 'VkPhysicalDeviceMemoryProperties': None}
mapDict['vkGetPhysicalDeviceProperties'] = {'VkPhysicalDeviceProperties': None, 'VkPhysicalDevice': None}
mapDict['vkGetPhysicalDeviceQueueFamilyProperties'] = {'VkQueueFamilyProperties': None, 'VkPhysicalDevice': None}
mapDict['vkGetPhysicalDeviceSparseImageFormatProperties'] = {'VkFormat': None, 'VkPhysicalDevice': None, 'VkImageUsageFlags': None, 'VkSampleCountFlagBits': None, 'VkSparseImageFormatProperties': None, 'VkImageTiling': None, 'VkImageType': None}
mapDict['vkGetPhysicalDeviceFeatures'] = {'VkPhysicalDevice': None, 'VkPhysicalDeviceFeatures': None}
mapDict['vkGetPhysicalDeviceFormatProperties'] = {'VkPhysicalDevice': None, 'VkFormatProperties': None, 'VkFormat': None}
mapDict['vkGetPhysicalDeviceImageFormatProperties'] = {'VkImageUsageFlags': None, 'VkFormat': None, 'VkImageTiling': None, 'VkPhysicalDevice': None, 'VkImageType': None, 'VkImageCreateFlags': None, 'VkImageFormatProperties': None}
mapDict['vkGetPhysicalDeviceMemoryProperties'] = {'VkPhysicalDeviceMemoryProperties': None, 'VkPhysicalDevice': None}
mapDict['vkGetPhysicalDeviceProperties'] = {'VkPhysicalDevice': None, 'VkPhysicalDeviceProperties': None}
mapDict['vkGetPhysicalDeviceQueueFamilyProperties'] = {'VkPhysicalDevice': None, 'VkQueueFamilyProperties': None}
mapDict['vkGetPhysicalDeviceSparseImageFormatProperties'] = {'VkPhysicalDevice': None, 'VkImageTiling': None, 'VkFormat': None, 'VkImageUsageFlags': None, 'VkSparseImageFormatProperties': None, 'VkSampleCountFlagBits': None, 'VkImageType': None}
mapDict['vkGetPipelineCacheData'] = {'VkDevice': None, 'VkPipelineCache': None}
mapDict['vkGetQueryPoolResults'] = {'VkQueryPool': None, 'VkDevice': None, 'VkDeviceSize': None, 'VkQueryResultFlags': None}
mapDict['vkGetRenderAreaGranularity'] = {'VkDevice': None, 'VkRenderPass': None, 'VkExtent2D': None}
mapDict['vkGetQueryPoolResults'] = {'VkDevice': None, 'VkQueryPool': None, 'VkDeviceSize': None, 'VkQueryResultFlags': None}
mapDict['vkGetRenderAreaGranularity'] = {'VkDevice': None, 'VkExtent2D': None, 'VkRenderPass': None}
mapDict['vkInvalidateMappedMemoryRanges'] = {'VkDevice': None, 'VkMappedMemoryRange': None}
mapDict['vkMapMemory'] = {'VkDevice': None, 'VkDeviceMemory': None, 'VkMemoryMapFlags': None, 'VkDeviceSize': None}
mapDict['vkMapMemory'] = {'VkDeviceMemory': None, 'VkDevice': None, 'VkMemoryMapFlags': None, 'VkDeviceSize': None}
mapDict['vkMergePipelineCaches'] = {'VkDevice': None, 'VkPipelineCache': None}
mapDict['vkQueueBindSparse'] = {'VkQueue': None, 'VkBindSparseInfo': None, 'VkFence': None}
mapDict['vkQueueSubmit'] = {'VkSubmitInfo': None, 'VkQueue': None, 'VkFence': None}
mapDict['vkQueueBindSparse'] = {'VkQueue': None, 'VkFence': None, 'VkBindSparseInfo': None}
mapDict['vkQueueSubmit'] = {'VkQueue': None, 'VkFence': None, 'VkSubmitInfo': None}
mapDict['vkQueueWaitIdle'] = {'VkQueue': None}
mapDict['vkResetCommandBuffer'] = {'VkCommandBufferResetFlags': None, 'VkCommandBuffer': None}
mapDict['vkResetCommandPool'] = {'VkDevice': None, 'VkCommandPoolResetFlags': None, 'VkCommandPool': None}
mapDict['vkResetDescriptorPool'] = {'VkDevice': None, 'VkDescriptorPoolResetFlags': None, 'VkDescriptorPool': None}
mapDict['vkResetCommandPool'] = {'VkCommandPool': None, 'VkDevice': None, 'VkCommandPoolResetFlags': None}
mapDict['vkResetDescriptorPool'] = {'VkDescriptorPoolResetFlags': None, 'VkDevice': None, 'VkDescriptorPool': None}
mapDict['vkResetEvent'] = {'VkDevice': None, 'VkEvent': None}
mapDict['vkResetFences'] = {'VkDevice': None, 'VkFence': None}
mapDict['vkSetEvent'] = {'VkDevice': None, 'VkEvent': None}
mapDict['vkUnmapMemory'] = {'VkDevice': None, 'VkDeviceMemory': None}
mapDict['vkUpdateDescriptorSets'] = {'VkDevice': None, 'VkCopyDescriptorSet': None, 'VkWriteDescriptorSet': None}
mapDict['vkWaitForFences'] = {'VkDevice': None, 'VkBool32': None, 'VkFence': None}
mapDict['vkUnmapMemory'] = {'VkDeviceMemory': None, 'VkDevice': None}
mapDict['vkUpdateDescriptorSets'] = {'VkCopyDescriptorSet': None, 'VkDevice': None, 'VkWriteDescriptorSet': None}
mapDict['vkWaitForFences'] = {'VkDevice': None, 'VkFence': None, 'VkBool32': None}

28
out/genRef.html
View File

@ -1,28 +0,0 @@
<html>
<head>
<title>Vulkan Spec Sandbox - autogenerated reference page index </title>
</head>
<body>
<h1>Vulkan Spec Sandbox - autogenerated reference page index </h1>
<p> This is the vulkan spec sandbox for the 'genRef' branch, showing
autogenerated API reference pages. </p>
<ul>
<li> <b> Core API Specifications </b>
<ul>
<li> <a href="genRef/xhtml/vkspec.html">Single document</a> (XHTML from 'a2x') </li>
<li> <a href="genRef/pdf/vkspec.pdf"> Vulkan API spec (PDF)</a> </li>
</ul>
</li>
<li> <b> Reference pages (Core API only)</b>
<ul>
<li> <a href="genRef/apispec.html">Vulkan ref pages</a> (HTML, single document) </li>
<li> <a href="genRef/apispec.pdf">Vulkan ref pages</a> (PDF, single document) </li>
<li> <a href="genRef/man/html/">Vulkan ref pages</a> (HTML, separate files) </li>
<li> <a href="genRef/man/3/">Vulkan ref pages</a> (nroff / Unix man page markup, separate files) </li>
</ul>
</li>
</ul>
</body>
</html>

15
out/index.html
View File

@ -9,11 +9,12 @@
related documents. It is updated by hand periodically by Jon Leech. </p>
<ul>
<li> The <a href="1.0/styleguide.html">Vulkan Style Guide</a> is a work in
progress (but significantly complete) document, useful when writing
and modifying Specification and reference page language. </li>
<li> The <a href="1.0/readme.pdf">XML Registry README</a> describes the
schema and some use cases for <tt>vk.xml</tt>. </li>
<li> The <a href="1.0/styleguide.html">Vulkan API and Documentation
Style Guide</a> defines mandatory and recommended practices
for writing and modigying Specifications, extensions,
and reference page language. </li>
<li> The <a href="1.0/readme.pdf">XML Registry README (PDF)</a> describes
the schema and some use cases for <tt>vk.xml</tt>. </li>
<li> <b> Core API Specifications </b>
<ul>
<li> <a href="1.0/xhtml/vkspec.html">Single document</a> (XHTML from 'a2x') </li>
@ -54,9 +55,9 @@
</b> </li>
<ul>
<li> Core API <a href="1.0/html/vkspec.html">Single document</a> (HTML from
'asciibook') </li>
'asciidoc') </li>
<li> Core+WSI API <a href="1.0-wsi_extensions/html/vkspec.html">Single
document</a> (HTML from 'asciibook') </li>
document</a> (HTML from 'asciidoc') </li>
</ul>
</li>
</ul>

6
src/spec/README
View File

@ -62,7 +62,7 @@ MAKEFILE TARGETS
Again, in general this should be left until a branch is merged to
master.
readme.pdf - detailed description of the XML schema. Normally this need
not be rebuilt unless you're changing the schema and updating
not be rebuilt unless you are changing the schema and updating
readme.tex.
test - make sure ../vulkan/vulkan.h compiles. Important!
validate - validate vk.xml against the schema. Requires 'jing' tool
@ -116,12 +116,12 @@ CHANGE LOG
2015/06/01
The header that's generated has been improved relative to the first
The header that is generated has been improved relative to the first
version. Function arguments are indented like the hand-generated header,
enumerant BEGIN/END_RANGE enums are named the same, etc. The ordering of
declarations is unlike the hand-generated header, and probably always
will because it results from a type/enum/function dependency analysis.
Some of this can be forced by being more explicit about it, if that's a
Some of this can be forced by being more explicit about it, if that is a
big deal.
2015/06/02

35
src/spec/readme.tex
View File

@ -43,7 +43,7 @@
\title{The Khronos Vulkan API Registry for Vulkan}
\author{Jon Leech}
\date{Last updated 2016/02/22}
\date{Last updated 2016/07/10}
\maketitle
\begin{abstract}
@ -97,9 +97,9 @@ that people writing output generators for other languages will have to
include enough logic to parse the C declarations and extract the relevant
information.
People who don't find the supplied Python scripts to suit their needs are
People who do not find the supplied Python scripts to suit their needs are
likely to write their own parsers, interpreters, and/or converters operating
on the registry XML. We hope that we've provided enough information in this
on the registry XML. We hope that we have provided enough information in this
document, the RNC schema ({\tt registry.rnc}), and comments in the Registry
({\tt vk.xml}) itself to enable such projects. If not and you need
clarifications; if you have other problems using the registry; or if you
@ -173,7 +173,7 @@ Other Makefile targets include:
\item \code{full_install} - equivalent to \code{install} followed by
\code{vulkan-docs}.
\item \code{validate} - validate \code{vk.xml} against the XML schema.
Recommended if you're making nontrivial changes.
Recommended if you are making nontrivial changes.
\item \code{readme.pdf} - regenerate this document from the LaTeX source.
Most people will never need to do this. If you do, you must have
pdflatex installed, preferably from the TeTeX distribution.
@ -188,7 +188,7 @@ and ref page include generation, or to generate headers for languages
other than C, start with the Makefile rules and inspect the files
\code{vk.xml}, \code{genvk.py}, \code{reg.py}, and \code{generator.py}.
If you're using other platforms, merge requests with additional
If you are using other platforms, merge requests with additional
documentation on using the tools on those platforms would be very helpful.
\subsection{Header Generation Script - \code{genvk.py}}
@ -266,7 +266,7 @@ None.
\subsection{Contents of \tag{registry} tags}
Zero or more of each of the following tags, normally in this order
(although order shouldn't be important):
(although order should not be important):
\begin{itemize}
\item \tag{comment} - Contains arbitrary text, such as a copyright
@ -799,7 +799,7 @@ members.
\item \attr{len} - if the param is an array, len may be one or more of the
following things, separated by commas (one for each array
indirection): another param of that command; ``null-terminated'' for a
string; ``1'' to indicate it's just a pointer (used for nested
string; ``1'' to indicate it is just a pointer (used for nested
pointers); or an equation (a simple expression prefixed with
``math:'')
\item \attr{optional} - a value of 'true' or 'false' determines whether this
@ -1228,13 +1228,13 @@ typedef enum VkResult {
\section{Examples / FAQ / How Do I?}
\label{examples}
For people new to the Registry, it won't be immediately obvious how to make
For people new to the Registry, it will not be immediately obvious how to make
changes. This section includes some tips and examples that will help you
make changes to the Vulkan headers by changing the Registry XML description.
First, follow the steps in section~\ref{starting} to get the Vulkan Gitlab
repository containing the registry and assemble the tools necessary to work
with the XML registry. Once you're able to regenerate \code{vulkan.h} from
with the XML registry. Once you are able to regenerate \code{vulkan.h} from
\code{vk.xml}, you can start making changes.
@ -1312,7 +1312,7 @@ Consider the first few lines of the \tag{feature}:
The first \tag{require} block says to require a type named
\code{vk_platform}. If you look at the beginning of the \tag{types} section,
there's a corresponding definition:
there is a corresponding definition:
\begin{verbatim}
@ -1323,7 +1323,7 @@ there's a corresponding definition:
\end{verbatim}
\noindent section which is invoked by the requirement and emits a bunch of
boilerplate C code. The explicit dependency isn't strictly required since
boilerplate C code. The explicit dependency is not strictly required since
\code{vk_platform} will be required by many other types, but placing it
first causes this to appear first in the output file.
@ -1331,7 +1331,7 @@ Note that \code{vk_platform} does not correspond to an actual C type, but
instead to a collection of freeform preprocessor includes and macros and
comments. Most other \tag{type} tags do define a specific type and are much
simpler, but this approach can be used to inject arbitrary C into
\code{vulkan.h} {\bf when there's no other way}. In general inserting
\code{vulkan.h} {\bf when there is no other way}. In general inserting
arbitrary C is strongly discouraged outside of specific special cases like
this.
@ -1414,7 +1414,7 @@ required \tag{type} is:
\noindent In this case, the type \code{VkInstance} is defined by a special
compile-time macro which defines it as a derived class of \code{VkObject}
(for C++) or a less typesafe definition for (for C). This macro isn't part
(for C++) or a less typesafe definition for (for C). This macro is not part
of the type dependency analysis, just the boilerplate used in the header.
If these are the only \tag{feature} dependencies in \code{vk.xml}, the
@ -1581,7 +1581,7 @@ typedef struct {
If \code{VkInstanceCreateInfo} is the type of a parameter of a command in
the API, make sure that command's definition (see below for how to add a
command) puts \code{VkInstanceCreateInfo} in nested \tag{type} tags where
it's used.
it is used.
Otherwise, if the struct type is not used directly by a command in the API,
nor required by a chain of type dependencies for other commands, an explicit
@ -1651,7 +1651,7 @@ typedef enum {
If \code{VkDeviceCreateFlagBits} is the type of a parameter to a command in
the API, or of a member in a structure or union, make sure that command
parameter or struct member's definition puts \code{VkDeviceCreateFlagBits}
in nested \tag{type} tags where it's used.
in nested \tag{type} tags where it is used.
Otherwise, if the enumerated type is not used directly by a command in the
API, nor required by a chain of type dependencies for commands and structs,
@ -1746,7 +1746,7 @@ ease of reading, as follows:
The \tag{proto} tag defines the return type and function name of the
command. The \tag{param} tags define the command's parameters in the order
in which they're passed, including the parameter type and name. The contents
in which they are passed, including the parameter type and name. The contents
are laid out in the same way as the structure \tag{member} tags described
previously.
@ -1796,7 +1796,7 @@ various properties of API features, such as:
\end{itemize}
These tags will be used by other tools for purposes such as helping create
validation layers, generating serialization code, and so on. We'd like to
validation layers, generating serialization code, and so on. We would like to
eventually represent everything about the API that is amenable to automatic
processing within the registry schema. Please make suggestions on the Gitlab
issue tracker.
@ -1859,6 +1859,7 @@ log of this document (see section~\ref{changelog}). Changes to the
examples of making changes in appendix~\ref{examples}.
\item 2015/06/02 - Branch from OpenGL specfile documentation and bring up to
date with current Vulkan schema.
\item 2015/07/10 - Remove contractions to match the style guide.
\end{itemize}
% \input{readme.ind}

38
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> 20</type>
#define <name>VK_HEADER_VERSION</name> 21</type>
<type category="define">
#define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@ -814,16 +814,9 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>pname:mipLevels must: be less than or equal to latexmath:[$\lfloor\log_2(\max(\mathit{extent.width}, \mathit{extent.height}, \mathit{extent.depth}))\rfloor + 1$]</usage>
<usage>If any of pname:extent.width, pname:extent.height or pname:extent.depth are greater than the equivalently named members of sname:VkPhysicalDeviceLimits::pname:maxImageDimension3D, pname:mipLevels must: be less than or equal to sname:VkImageFormatProperties::pname:maxMipLevels (as returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure)</usage>
<usage>pname:arrayLayers must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxImageArrayLayers, or sname:VkImageFormatProperties::pname:maxArrayLayers (as returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure) - whichever is higher</usage>
<usage>pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampleCounts returned by flink:vkGetPhysicalDeviceProperties, or sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT or ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT, pname:extent.width must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxFramebufferWidth</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT or ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT, pname:extent.height must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxFramebufferHeight</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:framebufferColorSampleCounts</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, and pname:format includes a depth aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:framebufferDepthSampleCounts</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, and pname:format includes a stencil aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:framebufferStencilSampleCounts</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format includes a color aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampledImageColorSampleCounts</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format includes a depth aspect, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampledImageDepthSampleCounts</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_SAMPLED_BIT, and pname:format is an integer format, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:sampledImageIntegerSampleCounts</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_STORAGE_BIT, pname:samples must: be a bit value that is set in sname:VkPhysicalDeviceLimits::pname:storageImageSampleCounts</usage>
<usage>pname:samples must: be a bit value that is set in sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, pname:usage and pname:flags equal to those in this structure</usage>
<usage>If the &lt;&lt;features-features-textureCompressionETC2,ETC2 texture compression&gt;&gt; feature is not enabled, pname:format mustnot: be ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK, ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK, ename:VK_FORMAT_EAC_R11_UNORM_BLOCK, ename:VK_FORMAT_EAC_R11_SNORM_BLOCK, ename:VK_FORMAT_EAC_R11G11_UNORM_BLOCK, or ename:VK_FORMAT_EAC_R11G11_SNORM_BLOCK</usage>
<usage>If the &lt;&lt;features-features-textureCompressionASTC_LDR,ASTC LDR texture compression&gt;&gt; feature is not enabled, pname:format mustnot: be ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK, ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK, ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK, ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK, ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK, ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK, ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK, ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK, ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK, ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK, ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK, ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK, ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK, ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK, ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK, or ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK</usage>
<usage>If the &lt;&lt;features-features-textureCompressionBC,BC texture compression&gt;&gt; feature is not enabled, pname:format mustnot: be ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK, ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK, ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK, ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK, ename:VK_FORMAT_BC2_UNORM_BLOCK, ename:VK_FORMAT_BC2_SRGB_BLOCK, ename:VK_FORMAT_BC3_UNORM_BLOCK, ename:VK_FORMAT_BC3_SRGB_BLOCK, ename:VK_FORMAT_BC4_UNORM_BLOCK, ename:VK_FORMAT_BC4_SNORM_BLOCK, ename:VK_FORMAT_BC5_UNORM_BLOCK, ename:VK_FORMAT_BC5_SNORM_BLOCK, ename:VK_FORMAT_BC6H_UFLOAT_BLOCK, ename:VK_FORMAT_BC6H_SFLOAT_BLOCK, ename:VK_FORMAT_BC7_UNORM_BLOCK, or ename:VK_FORMAT_BC7_SRGB_BLOCK</usage>
@ -996,6 +989,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If either of the calling command's pname:srcImage or pname:dstImage parameters are of elink:VkImageType ename:VK_IMAGE_TYPE_3D, the pname:baseArrayLayer and pname:layerCount members of both pname:srcSubresource and pname:dstSubresource must: be `0` and `1`, respectively</usage>
<usage>The pname:aspectMask member of pname:srcSubresource must: specify aspects present in the calling command's pname:srcImage</usage>
<usage>The pname:aspectMask member of pname:dstSubresource must: specify aspects present in the calling command's pname:dstImage</usage>
<usage>The pname:layerCount member of pname:dstSubresource must: be equal to the pname:layerCount member of pname:srcSubresource</usage>
<usage>pname:srcOffset[0].x and pname:srcOffset[1].x must: both be greater than or equal to `0` and less than or equal to the source image subresource width</usage>
<usage>pname:srcOffset[0].y and pname:srcOffset[1].y must: both be greater than or equal to `0` and less than or equal to the source image subresource height</usage>
<usage>pname:srcOffset[0].z and pname:srcOffset[1].z must: both be greater than or equal to `0` and less than or equal to the source image subresource depth</usage>
@ -1378,11 +1372,12 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage>If pname:pStages includes a tessellation control shader stage, it must: include a tessellation evaluation shader stage</usage>
<usage>If pname:pStages includes a tessellation evaluation shader stage, it must: include a tessellation control shader stage</usage>
<usage>If pname:pStages includes a tessellation control shader stage and a tessellation evaluation shader stage, pname:pTessellationState mustnot: be `NULL`</usage>
<usage>If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, the shader code of at least one must: contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline</usage>
<usage>If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, and the shader code of both contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline, they must: both specify the same subdivision mode</usage>
<usage>If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, the shader code of at least one must: contain an code:OpExecutionMode instruction that specifies the output patch size in the pipeline</usage>
<usage>If pname:pStages includes both a tessellation control shader stage and a tessellation evaluation shader stage, and the shader code of both contain an code:OpExecutionMode instruction that specifies the out patch size in the pipeline, they must: both specify the same patch size</usage>
<usage>If pname:pStages includes tessellation shader stages, the shader code of at least one stage must: contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline</usage>
<usage>If pname:pStages includes tessellation shader stages, and the shader code of both stages contain an code:OpExecutionMode instruction that specifies the type of subdivision in the pipeline, they must: both specify the same subdivision mode</usage>
<usage>If pname:pStages includes tessellation shader stages, the shader code of at least one stage must: contain an code:OpExecutionMode instruction that specifies the output patch size in the pipeline</usage>
<usage>If pname:pStages includes tessellation shader stages, and the shader code of both contain an code:OpExecutionMode instruction that specifies the out patch size in the pipeline, they must: both specify the same patch size</usage>
<usage>If pname:pStages includes tessellation shader stages, the pname:topology member of pname:pInputAssembly must: be ename:VK_PRIMITIVE_TOPOLOGY_PATCH_LIST</usage>
<usage>If the pname:topology member of pname:pInputAssembly is ename:VK_PRIMITIVE_TOPOLOGY_PATCH_LIST, pname:pStages must: include tessellation shader stages</usage>
<usage>If pname:pStages includes a geometry shader stage, and does not include any tessellation shader stages, its shader code must: contain an code:OpExecutionMode instruction that specifies an input primitive type that is &lt;&lt;shaders-geometry-execution, compatible&gt;&gt; with the primitive topology specified in pname:pInputAssembly</usage>
<usage>If pname:pStages includes a geometry shader stage, and also includes tessellation shader stages, its shader code must: contain an code:OpExecutionMode instruction that specifies an input primitive type that is &lt;&lt;shaders-geometry-execution, compatible&gt;&gt; with the primitive topology that is output by the tessellation stages</usage>
<usage>If pname:pStages includes a fragment shader stage and a geometry shader stage, and the fragment shader code reads from an input variable that is decorated with code:PrimitiveID, then the geometry shader code must: write to a matching output variable, decorated with code:PrimitiveID, in all execution paths</usage>
@ -3279,11 +3274,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<param optional="false,true"><type>uint32_t</type>* <name>pPropertyCount</name></param>
<param optional="true" len="pPropertyCount"><type>VkSparseImageFormatProperties</type>* <name>pProperties</name></param>
<validity>
<usage>If pname:format is an integer format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageIntegerSampleCounts</usage>
<usage>If pname:format is a non-integer color format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageColorSampleCounts</usage>
<usage>If pname:format is a depth format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageDepthSampleCounts</usage>
<usage>If pname:format is a stencil format, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:sampledImageStencilSampleCounts</usage>
<usage>If pname:usage includes ename:VK_IMAGE_USAGE_STORAGE_BIT, samples must: be one of the bit flags specified in sname:VkPhysicalDeviceLimits::pname:storageImageSampleCounts</usage>
<usage>pname:samples must: be a bit value that is set in sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, and pname:usage equal to those in this command and pname:flags equal to the value that is set in sname::VkImageCreateInfo::pname::flags when the image is created</usage>
</validity>
</command>
<command queues="sparse_binding" successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY,VK_ERROR_DEVICE_LOST">
@ -4185,7 +4176,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<validity>
<usage>The source region specified by a given element of pname:pRegions must: be a region that is contained within pname:srcImage</usage>
<usage>The destination region specified by a given element of pname:pRegions must: be a region that is contained within pname:dstImage</usage>
<usage>The union of all source regions, and the union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory</usage>
<usage>The union of all destination regions, specified by the elements of pname:pRegions, mustnot: overlap in memory with any texel that may: be sampled during the blit operation</usage>
<usage>pname:srcImage must: use a format that supports ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT, which is indicated by sname:VkFormatProperties::pname:linearTilingFeatures (for linear tiled images) or sname:VkFormatProperties::pname:optimalTilingFeatures (for optimally tiled images) - as returned by fname:vkGetPhysicalDeviceFormatProperties</usage>
<usage>pname:srcImage must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage flag</usage>
<usage>pname:srcImageLayout must: specify the layout of the image subresources of pname:srcImage specified in pname:pRegions at the time this command is executed on a sname:VkDevice</usage>
@ -4199,6 +4190,8 @@ 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>pname:srcImage must: have been created with a pname:samples value of ename:VK_SAMPLE_COUNT_1_BIT</usage>
<usage>pname:dstImage must: have been created with a pname:samples value of ename:VK_SAMPLE_COUNT_1_BIT</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>
@ -5144,6 +5137,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<enum offset="1" dir="-" extends="VkResult" name="VK_ERROR_INCOMPATIBLE_DISPLAY_KHR"/>
<type name="VkDisplayPresentInfoKHR"/>
<command name="vkCreateSharedSwapchainsKHR"/>
<usage command="vkQueuePresentKHR">If more than one member of 'pSwapchains' was created from a display surface, all display surfaces referenced that refer to the same display must: use the same display mode.</usage>
</require>
</extension>
<extension name="VK_KHR_xlib_surface" number="5" protect="VK_USE_PLATFORM_XLIB_KHR" supported="vulkan">
@ -5516,5 +5510,11 @@ maintained in the master branch of the Khronos Vulkan Github project.
<enum value="&quot;VK_NVX_extension_52&quot;" name="VK_NVX_EXTENSION_52_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_NV_extension_53" number="53" author="NVIDIA" contact="Jeff Bolz @jbolz" supported="disabled">
<require>
<enum value="0" name="VK_NV_EXTENSION_53_SPEC_VERSION"/>
<enum value="&quot;VK_NV_extension_53&quot;" name="VK_NV_EXTENSION_53_EXTENSION_NAME"/>
</require>
</extension>
</extensions>
</registry>

14
src/vulkan/vk_platform.h
View File

@ -51,13 +51,13 @@ extern "C"
#define VKAPI_ATTR
#define VKAPI_CALL __stdcall
#define VKAPI_PTR VKAPI_CALL
#elif defined(__ANDROID__) && defined(__ARM_EABI__) && !defined(__ARM_ARCH_7A__)
// Android does not support Vulkan in native code using the "armeabi" ABI.
#error "Vulkan requires the 'armeabi-v7a' or 'armeabi-v7a-hard' ABI on 32-bit ARM CPUs"
#elif defined(__ANDROID__) && defined(__ARM_ARCH_7A__)
// On Android/ARMv7a, Vulkan functions use the armeabi-v7a-hard calling
// convention, even if the application's native code is compiled with the
// armeabi-v7a calling convention.
#elif defined(__ANDROID__) && defined(__ARM_ARCH) && __ARM_ARCH < 7
#error "Vulkan isn't supported for the 'armeabi' NDK ABI"
#elif defined(__ANDROID__) && __ARM_ARCH >= 7 && __ARM_32BIT_STATE
// On Android 32-bit ARM targets, Vulkan functions use the "hardfloat"
// calling convention, i.e. float parameters are passed in registers. This
// is true even if the rest of the application passes floats on the stack,
// as it does by default when compiling for the armeabi-v7a NDK ABI.
#define VKAPI_ATTR __attribute__((pcs("aapcs-vfp")))
#define VKAPI_CALL
#define VKAPI_PTR VKAPI_ATTR

2
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 20
#define VK_HEADER_VERSION 21
#define VK_NULL_HANDLE 0