From f4c4113d070c0c9b55b4482055be054dd6466c96 Mon Sep 17 00:00:00 2001 From: Jon Leech Date: Fri, 15 Jul 2016 19:05:43 -0700 Subject: [PATCH] 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 <> relate to the limits in slink:VkPhysicalDeviceLimits. (public issue 185). * Clarify in the <> 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 <> section (internal issue 370). * Add mathematical description of blitting to flink:vkCmdBlitImage, and link it to the <> chapter. Use mathematical notation for ranges of texel coordinates in the <> 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. --- ChangeLog.txt | 114 +++- doc/specs/vulkan/Makefile | 97 +-- doc/specs/vulkan/README.html | 107 ++- doc/specs/vulkan/README.txt | 57 +- doc/specs/vulkan/appendices/boilerplate.txt | 10 +- doc/specs/vulkan/appendices/extensions.txt | 579 +---------------- doc/specs/vulkan/appendices/spirvenv.txt | 2 +- doc/specs/vulkan/chapters/copies.txt | 92 ++- doc/specs/vulkan/chapters/devsandqueues.txt | 5 +- doc/specs/vulkan/chapters/features.txt | 95 ++- doc/specs/vulkan/chapters/fundamentals.txt | 5 +- doc/specs/vulkan/chapters/fxvertex.txt | 6 +- doc/specs/vulkan/chapters/interfaces.txt | 4 + doc/specs/vulkan/chapters/introduction.txt | 5 + doc/specs/vulkan/chapters/textures.txt | 10 +- doc/specs/vulkan/config/manpages.conf | 2 +- doc/specs/vulkan/{man => config}/vkman.css | 0 doc/specs/vulkan/copyright-ccby.txt | 4 + .../vulkan/defines/VK_HEADER_VERSION.txt | 2 +- doc/specs/vulkan/genRef.py | 30 +- doc/specs/vulkan/genRelease | 16 +- doc/specs/vulkan/man/VK_API_VERSION.txt | 2 +- doc/specs/vulkan/man/VK_API_VERSION_1_0.txt | 7 +- .../man/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt | 1 - doc/specs/vulkan/man/VkBufferCopy.txt | 2 +- doc/specs/vulkan/man/VkBufferCreateInfo.txt | 2 +- doc/specs/vulkan/man/VkBufferImageCopy.txt | 2 +- .../vulkan/man/VkBufferMemoryBarrier.txt | 2 +- .../vulkan/man/VkBufferViewCreateInfo.txt | 2 +- .../man/VkCommandBufferInheritanceInfo.txt | 2 +- .../vulkan/man/VkDescriptorBufferInfo.txt | 2 +- .../vulkan/man/VkImageFormatProperties.txt | 18 +- doc/specs/vulkan/man/VkMappedMemoryRange.txt | 2 +- doc/specs/vulkan/man/VkMemoryAllocateInfo.txt | 2 +- doc/specs/vulkan/man/VkMemoryHeap.txt | 2 +- doc/specs/vulkan/man/VkMemoryRequirements.txt | 2 +- .../vulkan/man/VkPhysicalDeviceFeatures.txt | 2 +- .../vulkan/man/VkPhysicalDeviceLimits.txt | 35 +- .../vulkan/man/VkPhysicalDeviceProperties.txt | 5 +- .../man/VkPhysicalDeviceSparseProperties.txt | 2 +- .../VkPipelineColorBlendAttachmentState.txt | 2 +- .../VkPipelineColorBlendStateCreateInfo.txt | 2 +- .../VkPipelineDepthStencilStateCreateInfo.txt | 2 +- ...VkPipelineInputAssemblyStateCreateInfo.txt | 2 +- .../VkPipelineMultisampleStateCreateInfo.txt | 2 +- ...VkPipelineRasterizationStateCreateInfo.txt | 2 +- doc/specs/vulkan/man/VkSamplerCreateInfo.txt | 2 +- .../vulkan/man/VkSparseImageMemoryBind.txt | 2 +- .../man/VkSparseImageMemoryRequirements.txt | 2 +- doc/specs/vulkan/man/VkSparseMemoryBind.txt | 2 +- doc/specs/vulkan/man/VkSubresourceLayout.txt | 2 +- doc/specs/vulkan/man/vkBindBufferMemory.txt | 2 +- doc/specs/vulkan/man/vkBindImageMemory.txt | 2 +- doc/specs/vulkan/man/vkCmdBindIndexBuffer.txt | 2 +- .../vulkan/man/vkCmdBindVertexBuffers.txt | 2 +- doc/specs/vulkan/man/vkCmdBlitImage.txt | 92 ++- .../vulkan/man/vkCmdCopyQueryPoolResults.txt | 2 +- .../vulkan/man/vkCmdDispatchIndirect.txt | 2 +- .../vulkan/man/vkCmdDrawIndexedIndirect.txt | 2 +- doc/specs/vulkan/man/vkCmdDrawIndirect.txt | 2 +- doc/specs/vulkan/man/vkCmdFillBuffer.txt | 2 +- doc/specs/vulkan/man/vkCmdUpdateBuffer.txt | 2 +- .../man/vkGetDeviceMemoryCommitment.txt | 2 +- .../vulkan/man/vkGetQueryPoolResults.txt | 2 +- doc/specs/vulkan/man/vkMapMemory.txt | 2 +- doc/specs/vulkan/man/vkWaitForFences.txt | 2 +- doc/specs/vulkan/style/extensions.txt | 613 ++++++++++++++++++ .../style/{styleguide.txt => markup.txt} | 548 ++-------------- doc/specs/vulkan/style/naming.txt | 424 ++++++++++++ doc/specs/vulkan/style/writing.txt | 338 ++++++++++ doc/specs/vulkan/styleguide.txt | 182 ++++++ .../vulkan/validity/protos/vkCmdBlitImage.txt | 4 +- ...sicalDeviceSparseImageFormatProperties.txt | 6 +- .../structs/VkGraphicsPipelineCreateInfo.txt | 9 +- .../vulkan/validity/structs/VkImageBlit.txt | 1 + .../validity/structs/VkImageCreateInfo.txt | 9 +- doc/specs/vulkan/vkapi.py | 486 +++++++------- out/genRef.html | 28 - out/index.html | 15 +- src/spec/README | 6 +- src/spec/readme.tex | 35 +- src/spec/vk.xml | 38 +- src/vulkan/vk_platform.h | 14 +- src/vulkan/vulkan.h | 2 +- 84 files changed, 2522 insertions(+), 1714 deletions(-) rename doc/specs/vulkan/{man => config}/vkman.css (100%) create mode 100644 doc/specs/vulkan/copyright-ccby.txt create mode 100644 doc/specs/vulkan/style/extensions.txt rename doc/specs/vulkan/style/{styleguide.txt => markup.txt} (52%) create mode 100644 doc/specs/vulkan/style/naming.txt create mode 100644 doc/specs/vulkan/style/writing.txt create mode 100644 doc/specs/vulkan/styleguide.txt delete mode 100644 out/genRef.html diff --git a/ChangeLog.txt b/ChangeLog.txt index a277faf0..27e32914 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -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 <> diagram. Use more easily distinguished symbols in tables in the <> 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 <> 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 <> @@ -550,7 +550,7 @@ Github Issues: * Note in the <> and <> 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 <> + relate to the limits in slink:VkPhysicalDeviceLimits. (public issue + 185). + * Clarify in the <> 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 + <> section (internal issue + 370). + * Add mathematical description of blitting to flink:vkCmdBlitImage, and + link it to the <> chapter. Use mathematical + notation for ranges of texel coordinates in the <> 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. diff --git a/doc/specs/vulkan/Makefile b/doc/specs/vulkan/Makefile index 550c06b2..d2f7aa00 100644 --- a/doc/specs/vulkan/Makefile +++ b/doc/specs/vulkan/Makefile @@ -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 diff --git a/doc/specs/vulkan/README.html b/doc/specs/vulkan/README.html index 049cbaee..bcf28232 100644 --- a/doc/specs/vulkan/README.html +++ b/doc/specs/vulkan/README.html @@ -729,6 +729,14 @@ install: function(toclevels) { asciidoc.install(); /*]]>*/ + + @@ -1227,7 +1276,7 @@ Devel/git (2.5.1-1) - Needed for updating specversion.txt

  • -2015/11/11 - Add new can: etc. macros and DBLATEXPREFIX variable. +2015/11/11 - Add new can etc. macros and DBLATEXPREFIX variable.

  • @@ -1261,7 +1310,7 @@ Devel/git (2.5.1-1) - Needed for updating specversion.txt diff --git a/doc/specs/vulkan/README.txt b/doc/specs/vulkan/README.txt index dede033c..97062b66 100644 --- a/doc/specs/vulkan/README.txt +++ b/doc/specs/vulkan/README.txt @@ -22,8 +22,15 @@ specification and reference pages building properly. == Building The Spec == Assuming you have all the right tools installed (see <> 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]] diff --git a/doc/specs/vulkan/appendices/boilerplate.txt b/doc/specs/vulkan/appendices/boilerplate.txt index bb677a96..f0e977b5 100644 --- a/doc/specs/vulkan/appendices/boilerplate.txt +++ b/doc/specs/vulkan/appendices/boilerplate.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/extensions.txt b/doc/specs/vulkan/appendices/extensions.txt index 452cac18..4aee597c 100644 --- a/doc/specs/vulkan/appendices/extensions.txt +++ b/doc/specs/vulkan/appendices/extensions.txt @@ -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_+. - * Layers are named with the syntax: +VK_LAYER_{AUTHOR|FQDN}_+. - -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 -<>. The merge must: add a ++ 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 -<>. 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 -<>. 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 -<>. The merge must: add a ++ 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 ++ 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 <>. The merge should: add a new ++ 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 ++ 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: +-+ - -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 -<> 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 <>) 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 <>. 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 <>). 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 -<> 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 <> 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 <> +document. Authors creating extensions and layers must follow the mandatory +procedures in that document. diff --git a/doc/specs/vulkan/appendices/spirvenv.txt b/doc/specs/vulkan/appendices/spirvenv.txt index b2573bd8..068e9167 100644 --- a/doc/specs/vulkan/appendices/spirvenv.txt +++ b/doc/specs/vulkan/appendices/spirvenv.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/copies.txt b/doc/specs/vulkan/chapters/copies.txt index f54606c9..97aa4f07 100644 --- a/doc/specs/vulkan/chapters/copies.txt +++ b/doc/specs/vulkan/chapters/copies.txt @@ -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 + <>: +[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 +<>, 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 diff --git a/doc/specs/vulkan/chapters/devsandqueues.txt b/doc/specs/vulkan/chapters/devsandqueues.txt index a07628a2..03b651df 100644 --- a/doc/specs/vulkan/chapters/devsandqueues.txt +++ b/doc/specs/vulkan/chapters/devsandqueues.txt @@ -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 <> section. Khronos vendor IDs are allocated starting at 0x10000, + described in the <> + 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 diff --git a/doc/specs/vulkan/chapters/features.txt b/doc/specs/vulkan/chapters/features.txt index c4bd4981..280935f3 100644 --- a/doc/specs/vulkan/chapters/features.txt +++ b/doc/specs/vulkan/chapters/features.txt @@ -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 <>. 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, <>, or <>. |========================================= + == 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 + <>. * 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 diff --git a/doc/specs/vulkan/chapters/fundamentals.txt b/doc/specs/vulkan/chapters/fundamentals.txt index 9362c7c1..02e3aea8 100644 --- a/doc/specs/vulkan/chapters/fundamentals.txt +++ b/doc/specs/vulkan/chapters/fundamentals.txt @@ -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 <> section. If that extension is supported by the +ptext:pNext members as described in the <> 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 diff --git a/doc/specs/vulkan/chapters/fxvertex.txt b/doc/specs/vulkan/chapters/fxvertex.txt index e011c24c..fc9c67cb 100644 --- a/doc/specs/vulkan/chapters/fxvertex.txt +++ b/doc/specs/vulkan/chapters/fxvertex.txt @@ -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]] diff --git a/doc/specs/vulkan/chapters/interfaces.txt b/doc/specs/vulkan/chapters/interfaces.txt index de9623bb..9054fb9c 100644 --- a/doc/specs/vulkan/chapters/interfaces.txt +++ b/doc/specs/vulkan/chapters/interfaces.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/introduction.txt b/doc/specs/vulkan/chapters/introduction.txt index 7fcac7cc..182e547f 100644 --- a/doc/specs/vulkan/chapters/introduction.txt +++ b/doc/specs/vulkan/chapters/introduction.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/textures.txt b/doc/specs/vulkan/chapters/textures.txt index c2fdab2e..d0f5c2e5 100644 --- a/doc/specs/vulkan/chapters/textures.txt +++ b/doc/specs/vulkan/chapters/textures.txt @@ -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 diff --git a/doc/specs/vulkan/config/manpages.conf b/doc/specs/vulkan/config/manpages.conf index d0a7c2d4..a050cc78 100644 --- a/doc/specs/vulkan/config/manpages.conf +++ b/doc/specs/vulkan/config/manpages.conf @@ -54,7 +54,7 @@ max-width="1024px" (?su)(?Pptext):(?P[\w*]+(\.[\w*]+)*)=param (?su)(?Ptlink):(?P\w+)=link (?su)(?Ptname):(?P\w+)=strong -(?su)(?Pbasetype):(?P\w+)=code +(?su)(?Pbasetype):(?P\w+)=link (?su)(?Pcode):(?P\w+)=strong [normative-inlinemacro] diff --git a/doc/specs/vulkan/man/vkman.css b/doc/specs/vulkan/config/vkman.css similarity index 100% rename from doc/specs/vulkan/man/vkman.css rename to doc/specs/vulkan/config/vkman.css diff --git a/doc/specs/vulkan/copyright-ccby.txt b/doc/specs/vulkan/copyright-ccby.txt new file mode 100644 index 00000000..8c1d6169 --- /dev/null +++ b/doc/specs/vulkan/copyright-ccby.txt @@ -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]. + diff --git a/doc/specs/vulkan/defines/VK_HEADER_VERSION.txt b/doc/specs/vulkan/defines/VK_HEADER_VERSION.txt index 13d826b2..18ed76d4 100644 --- a/doc/specs/vulkan/defines/VK_HEADER_VERSION.txt +++ b/doc/specs/vulkan/defines/VK_HEADER_VERSION.txt @@ -8,6 +8,6 @@ ifdef::doctype-manpage[] endif::doctype-manpage[] ------------------------------------------------------------------------------ // Version of this file -#define VK_HEADER_VERSION 20 +#define VK_HEADER_VERSION 21 ------------------------------------------------------------------------------ diff --git a/doc/specs/vulkan/genRef.py b/doc/specs/vulkan/genRef.py index 33180936..0091c78a 100755 --- a/doc/specs/vulkan/genRef.py +++ b/doc/specs/vulkan/genRef.py @@ -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', '--------', diff --git a/doc/specs/vulkan/genRelease b/doc/specs/vulkan/genRelease index 878d680a..f9153851 100755 --- a/doc/specs/vulkan/genRelease +++ b/doc/specs/vulkan/genRelease @@ -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) diff --git a/doc/specs/vulkan/man/VK_API_VERSION.txt b/doc/specs/vulkan/man/VK_API_VERSION.txt index 7e9fbaf6..56d8b1f7 100644 --- a/doc/specs/vulkan/man/VK_API_VERSION.txt +++ b/doc/specs/vulkan/man/VK_API_VERSION.txt @@ -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[] diff --git a/doc/specs/vulkan/man/VK_API_VERSION_1_0.txt b/doc/specs/vulkan/man/VK_API_VERSION_1_0.txt index e8edddf2..36b7f9ee 100644 --- a/doc/specs/vulkan/man/VK_API_VERSION_1_0.txt +++ b/doc/specs/vulkan/man/VK_API_VERSION_1_0.txt @@ -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[] diff --git a/doc/specs/vulkan/man/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt b/doc/specs/vulkan/man/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt index 4a1a9825..dc7d6b23 100644 --- a/doc/specs/vulkan/man/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt +++ b/doc/specs/vulkan/man/VK_DEFINE_NON_DISPATCHABLE_HANDLE.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkBufferCopy.txt b/doc/specs/vulkan/man/VkBufferCopy.txt index f0dae887..b2be61b3 100644 --- a/doc/specs/vulkan/man/VkBufferCopy.txt +++ b/doc/specs/vulkan/man/VkBufferCopy.txt @@ -38,7 +38,7 @@ include::../validity/structs/VkBufferCopy.txt[] See Also -------- -basetypes:VkDeviceSize, flink:vkCmdCopyBuffer +basetype:VkDeviceSize, flink:vkCmdCopyBuffer Document Notes diff --git a/doc/specs/vulkan/man/VkBufferCreateInfo.txt b/doc/specs/vulkan/man/VkBufferCreateInfo.txt index 00eaeb5c..94735bd6 100644 --- a/doc/specs/vulkan/man/VkBufferCreateInfo.txt +++ b/doc/specs/vulkan/man/VkBufferCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkBufferImageCopy.txt b/doc/specs/vulkan/man/VkBufferImageCopy.txt index d4cd3a8f..8041e9b2 100644 --- a/doc/specs/vulkan/man/VkBufferImageCopy.txt +++ b/doc/specs/vulkan/man/VkBufferImageCopy.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkBufferMemoryBarrier.txt b/doc/specs/vulkan/man/VkBufferMemoryBarrier.txt index a395be16..990df2bc 100644 --- a/doc/specs/vulkan/man/VkBufferMemoryBarrier.txt +++ b/doc/specs/vulkan/man/VkBufferMemoryBarrier.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkBufferViewCreateInfo.txt b/doc/specs/vulkan/man/VkBufferViewCreateInfo.txt index 277d7b98..24b4445b 100644 --- a/doc/specs/vulkan/man/VkBufferViewCreateInfo.txt +++ b/doc/specs/vulkan/man/VkBufferViewCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkCommandBufferInheritanceInfo.txt b/doc/specs/vulkan/man/VkCommandBufferInheritanceInfo.txt index e5ce44dd..1d747688 100644 --- a/doc/specs/vulkan/man/VkCommandBufferInheritanceInfo.txt +++ b/doc/specs/vulkan/man/VkCommandBufferInheritanceInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkDescriptorBufferInfo.txt b/doc/specs/vulkan/man/VkDescriptorBufferInfo.txt index ee5883fa..4f468000 100644 --- a/doc/specs/vulkan/man/VkDescriptorBufferInfo.txt +++ b/doc/specs/vulkan/man/VkDescriptorBufferInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkImageFormatProperties.txt b/doc/specs/vulkan/man/VkImageFormatProperties.txt index 49672f5b..207d7105 100644 --- a/doc/specs/vulkan/man/VkImageFormatProperties.txt +++ b/doc/specs/vulkan/man/VkImageFormatProperties.txt @@ -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 + <>. * 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 diff --git a/doc/specs/vulkan/man/VkMappedMemoryRange.txt b/doc/specs/vulkan/man/VkMappedMemoryRange.txt index 0537ac15..ef332b9b 100644 --- a/doc/specs/vulkan/man/VkMappedMemoryRange.txt +++ b/doc/specs/vulkan/man/VkMappedMemoryRange.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkMemoryAllocateInfo.txt b/doc/specs/vulkan/man/VkMemoryAllocateInfo.txt index 3c45847e..96785b2b 100644 --- a/doc/specs/vulkan/man/VkMemoryAllocateInfo.txt +++ b/doc/specs/vulkan/man/VkMemoryAllocateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkMemoryHeap.txt b/doc/specs/vulkan/man/VkMemoryHeap.txt index cf70aa2e..18611b21 100644 --- a/doc/specs/vulkan/man/VkMemoryHeap.txt +++ b/doc/specs/vulkan/man/VkMemoryHeap.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkMemoryRequirements.txt b/doc/specs/vulkan/man/VkMemoryRequirements.txt index 6cc58b25..f7dfe03d 100644 --- a/doc/specs/vulkan/man/VkMemoryRequirements.txt +++ b/doc/specs/vulkan/man/VkMemoryRequirements.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkPhysicalDeviceFeatures.txt b/doc/specs/vulkan/man/VkPhysicalDeviceFeatures.txt index e5577506..67de38fe 100644 --- a/doc/specs/vulkan/man/VkPhysicalDeviceFeatures.txt +++ b/doc/specs/vulkan/man/VkPhysicalDeviceFeatures.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkPhysicalDeviceLimits.txt b/doc/specs/vulkan/man/VkPhysicalDeviceLimits.txt index 1ee56431..2867b76f 100644 --- a/doc/specs/vulkan/man/VkPhysicalDeviceLimits.txt +++ b/doc/specs/vulkan/man/VkPhysicalDeviceLimits.txt @@ -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 <>. 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 diff --git a/doc/specs/vulkan/man/VkPhysicalDeviceProperties.txt b/doc/specs/vulkan/man/VkPhysicalDeviceProperties.txt index 715e0044..c11befa7 100644 --- a/doc/specs/vulkan/man/VkPhysicalDeviceProperties.txt +++ b/doc/specs/vulkan/man/VkPhysicalDeviceProperties.txt @@ -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 <> section. Khronos vendor IDs are allocated starting at 0x10000, + described in the <> + 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 diff --git a/doc/specs/vulkan/man/VkPhysicalDeviceSparseProperties.txt b/doc/specs/vulkan/man/VkPhysicalDeviceSparseProperties.txt index 6926bcd4..213ee596 100644 --- a/doc/specs/vulkan/man/VkPhysicalDeviceSparseProperties.txt +++ b/doc/specs/vulkan/man/VkPhysicalDeviceSparseProperties.txt @@ -76,7 +76,7 @@ include::../validity/structs/VkPhysicalDeviceSparseProperties.txt[] See Also -------- -basetypes:VkBool32, slink:VkPhysicalDeviceProperties +basetype:VkBool32, slink:VkPhysicalDeviceProperties Document Notes diff --git a/doc/specs/vulkan/man/VkPipelineColorBlendAttachmentState.txt b/doc/specs/vulkan/man/VkPipelineColorBlendAttachmentState.txt index 5601c8de..0a3f2de6 100644 --- a/doc/specs/vulkan/man/VkPipelineColorBlendAttachmentState.txt +++ b/doc/specs/vulkan/man/VkPipelineColorBlendAttachmentState.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkPipelineColorBlendStateCreateInfo.txt b/doc/specs/vulkan/man/VkPipelineColorBlendStateCreateInfo.txt index 01a464b5..83570862 100644 --- a/doc/specs/vulkan/man/VkPipelineColorBlendStateCreateInfo.txt +++ b/doc/specs/vulkan/man/VkPipelineColorBlendStateCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkPipelineDepthStencilStateCreateInfo.txt b/doc/specs/vulkan/man/VkPipelineDepthStencilStateCreateInfo.txt index 8f3b8650..0580a31e 100644 --- a/doc/specs/vulkan/man/VkPipelineDepthStencilStateCreateInfo.txt +++ b/doc/specs/vulkan/man/VkPipelineDepthStencilStateCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkPipelineInputAssemblyStateCreateInfo.txt b/doc/specs/vulkan/man/VkPipelineInputAssemblyStateCreateInfo.txt index 4264914c..18555df5 100644 --- a/doc/specs/vulkan/man/VkPipelineInputAssemblyStateCreateInfo.txt +++ b/doc/specs/vulkan/man/VkPipelineInputAssemblyStateCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkPipelineMultisampleStateCreateInfo.txt b/doc/specs/vulkan/man/VkPipelineMultisampleStateCreateInfo.txt index d04cac6c..04214f92 100644 --- a/doc/specs/vulkan/man/VkPipelineMultisampleStateCreateInfo.txt +++ b/doc/specs/vulkan/man/VkPipelineMultisampleStateCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkPipelineRasterizationStateCreateInfo.txt b/doc/specs/vulkan/man/VkPipelineRasterizationStateCreateInfo.txt index 873e89de..d4843103 100644 --- a/doc/specs/vulkan/man/VkPipelineRasterizationStateCreateInfo.txt +++ b/doc/specs/vulkan/man/VkPipelineRasterizationStateCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkSamplerCreateInfo.txt b/doc/specs/vulkan/man/VkSamplerCreateInfo.txt index 620dc9a8..f3102b6c 100644 --- a/doc/specs/vulkan/man/VkSamplerCreateInfo.txt +++ b/doc/specs/vulkan/man/VkSamplerCreateInfo.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkSparseImageMemoryBind.txt b/doc/specs/vulkan/man/VkSparseImageMemoryBind.txt index 8657e484..caff7b8d 100644 --- a/doc/specs/vulkan/man/VkSparseImageMemoryBind.txt +++ b/doc/specs/vulkan/man/VkSparseImageMemoryBind.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkSparseImageMemoryRequirements.txt b/doc/specs/vulkan/man/VkSparseImageMemoryRequirements.txt index a37692c5..008d0782 100644 --- a/doc/specs/vulkan/man/VkSparseImageMemoryRequirements.txt +++ b/doc/specs/vulkan/man/VkSparseImageMemoryRequirements.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkSparseMemoryBind.txt b/doc/specs/vulkan/man/VkSparseMemoryBind.txt index 8e2fd452..e8ba16e3 100644 --- a/doc/specs/vulkan/man/VkSparseMemoryBind.txt +++ b/doc/specs/vulkan/man/VkSparseMemoryBind.txt @@ -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 diff --git a/doc/specs/vulkan/man/VkSubresourceLayout.txt b/doc/specs/vulkan/man/VkSubresourceLayout.txt index ca755ee7..98255d53 100644 --- a/doc/specs/vulkan/man/VkSubresourceLayout.txt +++ b/doc/specs/vulkan/man/VkSubresourceLayout.txt @@ -86,7 +86,7 @@ include::../validity/structs/VkSubresourceLayout.txt[] See Also -------- -basetypes:VkDeviceSize, flink:vkGetImageSubresourceLayout +basetype:VkDeviceSize, flink:vkGetImageSubresourceLayout Document Notes diff --git a/doc/specs/vulkan/man/vkBindBufferMemory.txt b/doc/specs/vulkan/man/vkBindBufferMemory.txt index a819032e..ae16c9c2 100644 --- a/doc/specs/vulkan/man/vkBindBufferMemory.txt +++ b/doc/specs/vulkan/man/vkBindBufferMemory.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkBindImageMemory.txt b/doc/specs/vulkan/man/vkBindImageMemory.txt index cddd2fef..382dd029 100644 --- a/doc/specs/vulkan/man/vkBindImageMemory.txt +++ b/doc/specs/vulkan/man/vkBindImageMemory.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdBindIndexBuffer.txt b/doc/specs/vulkan/man/vkCmdBindIndexBuffer.txt index aac18abf..f39ec0fb 100644 --- a/doc/specs/vulkan/man/vkCmdBindIndexBuffer.txt +++ b/doc/specs/vulkan/man/vkCmdBindIndexBuffer.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdBindVertexBuffers.txt b/doc/specs/vulkan/man/vkCmdBindVertexBuffers.txt index a32de3b3..ea0b917a 100644 --- a/doc/specs/vulkan/man/vkCmdBindVertexBuffers.txt +++ b/doc/specs/vulkan/man/vkCmdBindVertexBuffers.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdBlitImage.txt b/doc/specs/vulkan/man/vkCmdBlitImage.txt index afde7606..7ba51d19 100644 --- a/doc/specs/vulkan/man/vkCmdBlitImage.txt +++ b/doc/specs/vulkan/man/vkCmdBlitImage.txt @@ -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 + <>: +[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 +<>, 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 diff --git a/doc/specs/vulkan/man/vkCmdCopyQueryPoolResults.txt b/doc/specs/vulkan/man/vkCmdCopyQueryPoolResults.txt index dd7e7281..230872d8 100644 --- a/doc/specs/vulkan/man/vkCmdCopyQueryPoolResults.txt +++ b/doc/specs/vulkan/man/vkCmdCopyQueryPoolResults.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdDispatchIndirect.txt b/doc/specs/vulkan/man/vkCmdDispatchIndirect.txt index 4b327654..34851956 100644 --- a/doc/specs/vulkan/man/vkCmdDispatchIndirect.txt +++ b/doc/specs/vulkan/man/vkCmdDispatchIndirect.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdDrawIndexedIndirect.txt b/doc/specs/vulkan/man/vkCmdDrawIndexedIndirect.txt index aa15d682..c8faf7e3 100644 --- a/doc/specs/vulkan/man/vkCmdDrawIndexedIndirect.txt +++ b/doc/specs/vulkan/man/vkCmdDrawIndexedIndirect.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdDrawIndirect.txt b/doc/specs/vulkan/man/vkCmdDrawIndirect.txt index efaa6516..fccd29b3 100644 --- a/doc/specs/vulkan/man/vkCmdDrawIndirect.txt +++ b/doc/specs/vulkan/man/vkCmdDrawIndirect.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdFillBuffer.txt b/doc/specs/vulkan/man/vkCmdFillBuffer.txt index 1660ccaa..7a8957dc 100644 --- a/doc/specs/vulkan/man/vkCmdFillBuffer.txt +++ b/doc/specs/vulkan/man/vkCmdFillBuffer.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkCmdUpdateBuffer.txt b/doc/specs/vulkan/man/vkCmdUpdateBuffer.txt index e83a7dc8..bf6e3c76 100644 --- a/doc/specs/vulkan/man/vkCmdUpdateBuffer.txt +++ b/doc/specs/vulkan/man/vkCmdUpdateBuffer.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkGetDeviceMemoryCommitment.txt b/doc/specs/vulkan/man/vkGetDeviceMemoryCommitment.txt index 5406d5b6..177931b8 100644 --- a/doc/specs/vulkan/man/vkGetDeviceMemoryCommitment.txt +++ b/doc/specs/vulkan/man/vkGetDeviceMemoryCommitment.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkGetQueryPoolResults.txt b/doc/specs/vulkan/man/vkGetQueryPoolResults.txt index 1966f50d..6d094b91 100644 --- a/doc/specs/vulkan/man/vkGetQueryPoolResults.txt +++ b/doc/specs/vulkan/man/vkGetQueryPoolResults.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkMapMemory.txt b/doc/specs/vulkan/man/vkMapMemory.txt index f309f20a..6b59b06b 100644 --- a/doc/specs/vulkan/man/vkMapMemory.txt +++ b/doc/specs/vulkan/man/vkMapMemory.txt @@ -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 diff --git a/doc/specs/vulkan/man/vkWaitForFences.txt b/doc/specs/vulkan/man/vkWaitForFences.txt index 337947bc..0197636e 100644 --- a/doc/specs/vulkan/man/vkWaitForFences.txt +++ b/doc/specs/vulkan/man/vkWaitForFences.txt @@ -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 diff --git a/doc/specs/vulkan/style/extensions.txt b/doc/specs/vulkan/style/extensions.txt new file mode 100644 index 00000000..bfb5c5fb --- /dev/null +++ b/doc/specs/vulkan/style/extensions.txt @@ -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 +<>. Prior to revision 1.0.19 of the +<>, 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_+. + * Layers are named with the syntax: +VK_LAYER_{AUTHOR|FQDN}_+. + +Both extensions and layer names include a +VK_+ prefix, as described in the +<> 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 ++ 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 <> 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 +<>+ 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 +<> in the +1.0+ branch. The merge must +add a ++ 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 <>. 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 +<>. 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 <> in the ++1.0+ branch. The merge must add a ++ 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 +++ 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 <>. The merge should add a new ++ 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 <> 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 ++ 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: +-+ + +For example, the VK_KHR_surface extension will be documented relative to +version 1.0 of the <>. As such, the branch name +will be: +1.0-VK_KHR_surface+ in the Github +<>+ +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 +<> 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 +<> 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 <>) 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 <>. 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 +<>). 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 +<>. 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. diff --git a/doc/specs/vulkan/style/styleguide.txt b/doc/specs/vulkan/style/markup.txt similarity index 52% rename from doc/specs/vulkan/style/styleguide.txt rename to doc/specs/vulkan/style/markup.txt index dc9c8841..e9e749eb 100644 --- a/doc/specs/vulkan/style/styleguide.txt +++ b/doc/specs/vulkan/style/markup.txt @@ -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: : - -: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: - - * <> - 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. - * <> - 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 <>, 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 <>. 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 <>. 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 <>. 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. +<> 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 <>. 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 +<>, 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 <>, 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 +<>. 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 <>. .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 -<>. - - -[[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 <> 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 - <> 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. diff --git a/doc/specs/vulkan/style/naming.txt b/doc/specs/vulkan/style/naming.txt new file mode 100644 index 00000000..e2e38661 --- /dev/null +++ b/doc/specs/vulkan/style/naming.txt @@ -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 +<> and <> 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 + <>. + ** 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 <>, 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 +<> +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 +<> 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. diff --git a/doc/specs/vulkan/style/writing.txt b/doc/specs/vulkan/style/writing.txt new file mode 100644 index 00000000..58f7a125 --- /dev/null +++ b/doc/specs/vulkan/style/writing.txt @@ -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 <> +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 <>. Do not vary from them without +compelling need. + +Normative parts of the <> 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 <> +using <>. + + +[[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 <> is a sample based on the <>, +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 + <> 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[] +==== diff --git a/doc/specs/vulkan/styleguide.txt b/doc/specs/vulkan/styleguide.txt new file mode 100644 index 00000000..edcbfd42 --- /dev/null +++ b/doc/specs/vulkan/styleguide.txt @@ -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: : + +: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: + + * <> - the required rules for choosing names + of Vulkan identifiers of all types. + * <> - the required procedures + for creating formal Vulkan extensions and layers. + * <> - 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. + * <> - 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. diff --git a/doc/specs/vulkan/validity/protos/vkCmdBlitImage.txt b/doc/specs/vulkan/validity/protos/vkCmdBlitImage.txt index 9726e9ce..0458d676 100644 --- a/doc/specs/vulkan/validity/protos/vkCmdBlitImage.txt +++ b/doc/specs/vulkan/validity/protos/vkCmdBlitImage.txt @@ -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[] ******************************************************************************** diff --git a/doc/specs/vulkan/validity/protos/vkGetPhysicalDeviceSparseImageFormatProperties.txt b/doc/specs/vulkan/validity/protos/vkGetPhysicalDeviceSparseImageFormatProperties.txt index cf0c9cbf..c2f9598f 100644 --- a/doc/specs/vulkan/validity/protos/vkGetPhysicalDeviceSparseImageFormatProperties.txt +++ b/doc/specs/vulkan/validity/protos/vkGetPhysicalDeviceSparseImageFormatProperties.txt @@ -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[] diff --git a/doc/specs/vulkan/validity/structs/VkGraphicsPipelineCreateInfo.txt b/doc/specs/vulkan/validity/structs/VkGraphicsPipelineCreateInfo.txt index f418f5b5..d59bdef2 100644 --- a/doc/specs/vulkan/validity/structs/VkGraphicsPipelineCreateInfo.txt +++ b/doc/specs/vulkan/validity/structs/VkGraphicsPipelineCreateInfo.txt @@ -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 <> 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 <> 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 diff --git a/doc/specs/vulkan/validity/structs/VkImageBlit.txt b/doc/specs/vulkan/validity/structs/VkImageBlit.txt index 71398c97..3b27c0c9 100644 --- a/doc/specs/vulkan/validity/structs/VkImageBlit.txt +++ b/doc/specs/vulkan/validity/structs/VkImageBlit.txt @@ -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 diff --git a/doc/specs/vulkan/validity/structs/VkImageCreateInfo.txt b/doc/specs/vulkan/validity/structs/VkImageCreateInfo.txt index dcb7856c..81483f22 100644 --- a/doc/specs/vulkan/validity/structs/VkImageCreateInfo.txt +++ b/doc/specs/vulkan/validity/structs/VkImageCreateInfo.txt @@ -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 <> 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 <> 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 <> 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 diff --git a/doc/specs/vulkan/vkapi.py b/doc/specs/vulkan/vkapi.py index 552231be..68021173 100644 --- a/doc/specs/vulkan/vkapi.py +++ b/doc/specs/vulkan/vkapi.py @@ -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} diff --git a/out/genRef.html b/out/genRef.html deleted file mode 100644 index 1a460326..00000000 --- a/out/genRef.html +++ /dev/null @@ -1,28 +0,0 @@ - - -Vulkan Spec Sandbox - autogenerated reference page index - - -

    Vulkan Spec Sandbox - autogenerated reference page index

    - -

    This is the vulkan spec sandbox for the 'genRef' branch, showing - autogenerated API reference pages.

    - - - - diff --git a/out/index.html b/out/index.html index 8c155c73..3a2376d4 100644 --- a/out/index.html +++ b/out/index.html @@ -9,11 +9,12 @@ related documents. It is updated by hand periodically by Jon Leech.

      -
    • The Vulkan Style Guide is a work in - progress (but significantly complete) document, useful when writing - and modifying Specification and reference page language.
      • -
    • The XML Registry README describes the - schema and some use cases for vk.xml.
      • +
    • The Vulkan API and Documentation + Style Guide defines mandatory and recommended practices + for writing and modigying Specifications, extensions, + and reference page language.
      • +
    • The XML Registry README (PDF) describes + the schema and some use cases for vk.xml.
    • Core API Specifications diff --git a/src/spec/README b/src/spec/README index d7ce75d9..3afd5b9e 100644 --- a/src/spec/README +++ b/src/spec/README @@ -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 diff --git a/src/spec/readme.tex b/src/spec/readme.tex index 377d7b1a..6420a1a4 100644 --- a/src/spec/readme.tex +++ b/src/spec/readme.tex @@ -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} diff --git a/src/spec/vk.xml b/src/spec/vk.xml index d0036772..00c0e627 100644 --- a/src/spec/vk.xml +++ b/src/spec/vk.xml @@ -101,7 +101,7 @@ maintained in the master branch of the Khronos Vulkan Github project. // Vulkan 1.0 version number #define VK_API_VERSION_1_0 VK_MAKE_VERSION(1, 0, 0) // Version of this file -#define VK_HEADER_VERSION 20 +#define VK_HEADER_VERSION 21 #define VK_DEFINE_HANDLE(object) typedef struct object##_T* object; @@ -814,16 +814,9 @@ maintained in the master branch of the Khronos Vulkan Github project. 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 @@ -996,6 +989,7 @@ maintained in the master branch of the Khronos Vulkan Github project. 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 @@ -1378,11 +1372,12 @@ maintained in the master branch of the Khronos Vulkan Github project. 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 @@ -3279,11 +3274,7 @@ maintained in the master branch of the Khronos Vulkan Github project. uint32_t* pPropertyCount VkSparseImageFormatProperties* pProperties - 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 @@ -4185,7 +4176,7 @@ maintained in the master branch of the Khronos Vulkan Github project. 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 @@ -4199,6 +4190,8 @@ maintained in the master branch of the Khronos Vulkan Github project. 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 @@ -5144,6 +5137,7 @@ maintained in the master branch of the Khronos Vulkan Github project. + 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. @@ -5516,5 +5510,11 @@ maintained in the master branch of the Khronos Vulkan Github project. + + + + + + diff --git a/src/vulkan/vk_platform.h b/src/vulkan/vk_platform.h index 5d0fc766..c2232ec8 100644 --- a/src/vulkan/vk_platform.h +++ b/src/vulkan/vk_platform.h @@ -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 diff --git a/src/vulkan/vulkan.h b/src/vulkan/vulkan.h index 38affba4..34de8094 100644 --- a/src/vulkan/vulkan.h +++ b/src/vulkan/vulkan.h @@ -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