5769283448
* Bump API patch number and header version number to 68 for this update.
Github Issues:
* Added more details in the
<<extended-functionality-extensions-compatibility, Extension
Compatibility>> section, allowing explicit incompatibilities, and
simplify corresponding language in the style guide, which now defers to
the API Specification on this point (public issue 638).
* Fix typo in description of slink:VkCommandBufferLevel::pname:level
(public issue 651).
* Only include extension-dependent valid usage statement for
slink:VkImageSubresourceRange, and note that the extension names for
header files described in the <<boilerplate-wsi-header, Window
System-Specific Header Control>> section are only valid links, when the
specification being viewed is built with the corresponding extensions
enabled (public issue 652).
Internal Issues:
* Add language to elink:VkResult specifying that when commands return an
error, output parameter contents are undefined instead of unmodified
(except for pname:sType and pname:pNext). Note that this is a behavior
change. Add notes calling out slink:VkImageFormatProperties as an
exception (internal issue 1118).
* Add "`general-purpose`" to the style guide, and correct existing uses of
"`general purpose`" as an adjective (internal issue 1121).
* Add the ename:VK_DEBUG_REPORT_OBJECT_TYPE_VALIDATION_CACHE_EXT_EXT token
for the `VK_EXT_validation_cache` extension, following the same naming
pattern as other tokens in the extension, but keep the old
ename:VK_DEBUG_REPORT_OBJECT_TYPE_VALIDATION_CACHE_EXT token around for
backwards compatibility (internal issue 1126).
Other Issues:
* Specify that flink:vkCmdSetDiscardRectangleEXT does not affect copies or
clears, matching existing language for the scissor rectangle test.
* Move the <<boilerplate-sType, pname:sType>> definition from the
boilerplate appendix to the Fundamentals chapter, putting it together
with the valid usage of pname:sType rather than having the definition
split across two places.
* Inline all of the etext:Vk*Flags definitions, moving each one from the
boilerplate appendix to appear either after the corresponding
etext:Vk*FlagBits value if one is defined, or after the first structure
that includes them if not.
|
||
|---|---|---|
| doc/specs | ||
| out | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| COPYING.md | ||
| ChangeLog.txt | ||
| README.adoc | ||
| update_valid_usage_ids.sh | ||
README.adoc
Vulkan^(R)^ API Documentation Project
=====================================
This repository contains formal documentation of the Vulkan API. This
includes the main API Specification, the reference (man) pages, the XML API
Registry, and related tools and scripts.
Single-Branch Model
-------------------
As of the 1.0.25 release, we have switched to a new "`single-branch`" model
in which all extensions are included in the source of the 1.0 branch of the
Specification, and can be configured in or out of the build using Makefile
options.
Repository Structure
--------------------
```
README.adoc This file
ChangeLog.txt Change log summary for each public spec update
doc/specs/ Main documentation tree
vulkan/ Vulkan specification
appendices/ Appendices - one file each
chapters/ Chapters - one file each
config/ asciidoc configuration
images/ Images (figures, diagrams, icons)
man/ Reference (manual) pages for API, mostly extracted from the spec source
misc/ Related specifications (GL_KHR_vulkan_glsl)
src/spec/ XML API Registry (vk.xml) and related scripts
src/vulkan/ Vulkan headers, generated from the Registry
```
Building the Specification and Reference Pages
----------------------------------------------
As of the 1.0.40 release, we have moved from the old `asciidoc` toolchain to
a new one based on `asciidoctor`. See `doc/specs/vulkan/README.adoc` for
more information on installing the toolchain and building the Specification.
Generating Headers and Related Files
------------------------------------
The header file (`src/vulkan/vulkan.h`) and many parts of the specification
and reference page documents are generated from descriptions in the XML API
Registry (`src/spec/vk.xml`). The generated files, with the exception of
`vulkan.h`, are not checked into the repository. If you change `vk.xml`, you
can regenerate the header by going to `src/spec` and running:
$ make clobber install
The other generated files are built as required via dependencies in
`doc/specs/vulkan/Makefile` .