Jon Leech ca4abe0d34 Change log for January 23, 2017 Vulkan 1.0.39 spec update:
* Bump API patch number and header version number to 39 for this update.

Github Issues:

  * Clarified that only accesses via the specified buffer/image subresource
    ranges are included in the access scopes (public issue 306).
  * Add missing valid usage statements for flink:vkCreateComputePipelines
    and flink:vkCreateGraphicsPipelines (public issue 427).

Internal Issues:

  * Add a Note to the <<invariance,Invariance>> appendix about a difference
    between OpenGL and Vulkan with regards to how primitives derived from
    offsets are handled (internal issue 355).
  * Add the +<<VK_KHR_get_physical_device_properties2>>+,
    +<<VK_KHR_maintenance1>>+, and +<<VK_KHR_shader_draw_parameters>>+
    extensions (internal issue 448).
  * Add the +<<VK_EXT_shader_subgroup_vote>>+ and
    +<<VK_EXT_shader_subgroup_ballot>>+ extensions (internal issue 449).
  * Update the texture level-of-detail equation in the
    <<textures-scale-factor,Scale Factor Operation>> section to better
    approximate the ellipse major and minor axes (internal issue 547).
  * Forbid non-explicitly allowed uses of interface decorations in the
    introduction to the <<interfaces,Shader Interfaces>> chapter (internal
    issue 607).
  * Replace use of MathJax with KaTeX, for improved load-time performance as
    well as avoiding the scrolling-and-scrolling behavior due to MathJax
    asynchronous rendering when loading at an anchor inside the spec. This
    change also requires moving to HTML5 output for the spec instead of
    XHTML, and there is a visible difference in that the chapter navigation
    index is now in a scrollable sidebar instead of at the top of the
    document. We may or may not retain the nav sidebar based on feedback
    (internal issue 613).
  * Improve consistency of markup and formatting in extension appendices
    (internal issue 631).

Other Issues:

  * Add explicit valid usage statements to slink:VkImageCopy requiring that
    the source and destination layer ranges be contained in their respective
    source and destination images.
  * Add valid usage language for swapchain of flink:vkAcquireNextImage. If
    the swapchain has been replaced, then it should not be passed to
    flink:vkAcquireNextImage.
  * Add a valid usage statement to flink:vkCreateImageView, that the image
    must have been created with an appropriate usage bit set.
  * Noted that slink:VkDisplayPresentInfoKHR is a valid extension of
    slink:VkPresentInfoKHR in the <<wsi_swapchain,WSI Swapchain>> section.
  * Update valid usage for flink:vkCmdSetViewport and flink:vkCmdSetScissor
    to account for the multiple viewport feature. If the feature is not
    enabled, the parameters for these functions have required values that
    are defined in the <<features-features-multiViewport,multiple
    viewports>> section of the spec but were not reflected in the valid
    usage text for these functions.
  * Add the +<<VK_EXT_swapchain_colorspace>>+ extension defining common
    color spaces.
2017-01-17 20:11:25 -08:00

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.

Single-Branch Model

As of the 1.0.25 release, we have switch 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.

The single-branch model seems to be working for all the spec builds, although there are probably a few issues we haven't caught yet. The ref page build needs some additional work, as genRef.py is creating reference pages for all interfaces, not just those for the API and extensions being built, and we'll get to that within a week or two. The validation scripts also need to be tweaked further for the single-branch model.

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, 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

To build the documents, you need to install, at a minimum:

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 html - 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 dblatex and a LaTeX processor. The PDF builds are currently configured to use asciidoc 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.

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 .

Description
The Vulkan API Specification and related tools
Readme
Languages
JavaScript 59.4%
Python 32.6%
CSS 3.1%
Ruby 2%
Makefile 1.1%
Other 1.7%