eb9997129d
* Bump API patch number and header version number to 18 for this
update.
Github Issues:
* Added "queue operation" terminology, and modified spec to actually
use this terminology (public issue 155). The act of submitting a
piece of work to a queue now generates "operations" for the queue to
execute, including operations to wait on/signal semaphores and
fences. Synchronization waits on these operations, making execution
dependency chains more obvious for semaphores and fences (though
additional work is still needed here). These changes include:
** Overview of "queue submission" commands in chapter
<<devsandqueues-submission>>.
** Updated descriptions for fence and semaphore waits and signals in
the synchronization chapter <<synchronization-semaphores-waiting>>,
<<synchronization-semaphores-signaling>> and
<<synchronization-fences-waiting>>.
** Clarifications to semaphore and fence operation within queue
submission functions.
** New glossary terms.
** Moved device idle and queue wait idle to synchronization chapter in
order to describe them in terms of other synchronization
primitives.
** Clarifications to semaphore and fence operation allowed removal of
the "implicit ordering guarantees" section, as this information is
now wholly covered where these primitives are described.
*** The "host writes" section of this is still there for now - in its
own section. This could probably be merged into other sections
later.
*** Modified fundamentals chapter on queue ordering to make sense in
context of the new changes, and avoid duplication.
<<fundamentals-queueoperation>>
* Added "aspect" and "component" definitions to the glossary, and made
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
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).
* Change the WSI extension dependencies to refer to version 1.0 of the
Vulkan API, instead of the pre-1.0-release internal revisions
numbers (public issue 238).
* Specified that <<interfaces-fragmentoutput,undeclared fragment
shader outputs>> result in undefined values input to the blending
unit or color attachment (public issue 240).
Internal Issues:
* Better documented that the registry XML "optional" tag for values
only applies when that value is the size of an array (internal issue
335).
* Add a stronger definition for the valid usages of
VkSpecializationMapEntry.size in the
<<pipelines-specialization-constants,Specialization Constants>>
section (internal issue 345).
* Change code:OpName to code:OpDecorate (along with appropriate
syntax) for vertex shader built-ins (internal issue 368).
* Add missing ref pages (those which are not currently stubs) to
apispec.txt for the single-page version of the ref pages (internal
issue 378).
Other Commits:
* Fix example in the <<descriptorsets,Descriptor Sets>> section to use
M, N, and I, describing set, binding, and index, consistently
throughout the example code.
|
||
|---|---|---|
| doc/specs | ||
| out | ||
| src | ||
| .gitignore | ||
| ChangeLog.txt | ||
| README.md | ||
README.md
Vulkan 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.
Repository Structure
README.md This file
ChangeLog.txt Change log summary
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
enums/ Includeable snippets for enumerations from vk.xml
flags/ Includeable snippets for flags from vk.xml
protos/ Includeable snippets for prototypes from vk.xml
structs/ Includeable snippets for structures from vk.xml
validity/ Includeable validity language from vk.xml
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
To build the documents, you need to install, at a minimum:
- GNU-compatible make
- asciidoc (http://www.methods.co.nz/asciidoc/)
On some systems/build targets you may also need:
- dblatex
- source-highlight
These tools are known to work on several varieties of Linux, MacOS X, and Cygwin running under Microsoft Windows.
There are several make targets in doc/specs/vulkan :
- make xhtml - Build one large HTML specification document.
- make pdf - Build one large PDF specification document.
- make chunked - Build an HTML document broken into one file per chapter.
- make manhtml - Make HTML API reference (all man pages as one big file).
- make manpdf - Make a one-giant PDF API reference.
- make manhtmlpages - Make man pages as one-file-per-API.
- make manpages - Make man pages as nroff Unix-style (real) man pages.
- make allchecks - Run the validation rules on the specification.
The outputs will be written to $(OUTDIR), which defaults to out/ at the root of the checked-out git repository.
To build PDF outputs (make pdf, make manpdf), you need a2x (part of the asciidoc) package, dblatex and a LaTeX processor. The PDF builds are currently configured to use a2x to go from asciidoc markdown to docbook, and then run the result through dblatex to go from there to LaTeX and then through your LaTeX processor to PDF.
Spec Validation
There are a couple of validation tools which look for inconsistencies and missing material between the specification and ref pages, and the canonical description of the API in vk.xml :
- checkinc
- checklinks
- allchecks - both checkinc and checklinks
They are necessarily heuristic since they're dealing with lots of hand-written material. To use them you'll also need to install:
- python3
The '''checkinc''' target uses Unix filters to determine which autogenerated API include files are used (and not used) in the spec. It generates several output files, but the only one you're likely to care about is '''actual.only'''. This is a list of the include files which are not referenced anywhere in the spec, and probably correspond to undocumented material in the spec.
The '''checklinks''' target validates the various internal tagged links in the man pages and spec (e.g. the '''fname:vkFuncBlah''', '''sname:VkStructBlah''', etc.) against the canonical description of the API in vk.xml . It generates two output files, manErrs.txt and specErrs.txt, which report problematic tags and the filenames/lines on which those tags were found.
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). All the generated files are checked into the repository, and should not be modified directly. If you change vk.xml, you can regenerated these files by going to src/spec and running:
- make clobber (get rid of all old generated files)
- make full_install (regenerate all the files)