| // Copyright 2014-2023 The Khronos Group Inc. |
| // |
| // SPDX-License-Identifier: CC-BY-4.0 |
| |
| [[introduction]] |
| = Introduction |
| |
| This document contains required procedures and conventions when writing |
| specifications for new Vulkan APIs, extensions and layers, or related |
| Khronos^{reg}^ 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*, *required*, *should*, *recommend*, *may*, and |
| *optional* in this document are to be interpreted as described in RFC 2119 |
| and by the Vulkan Specification in the "`Terminology`" section. |
| |
| |
| [[introduction-structure]] |
| == Document Structure |
| |
| The style guide is broken into four sections: |
| |
| * <<naming,API Naming Conventions>> - the required rules for choosing |
| names of Vulkan identifiers of all types. |
| * <<extensions,Extensions and Layers>> - the required procedures for |
| creating formal Vulkan extensions and layers. |
| * <<markup,Markup Style>> - the required and recommended markup style for |
| writing asciidoctor and XML source that follows consistent formatting |
| and layout guidelines, tags special terms and phrases for proper |
| processing by the spec generation tools, etc. |
| * <<writing,Writing Style>> - the required and recommended writing style |
| for overall and fine-grained structure and conventions, normative |
| language use, API naming conventions, common words and phrases to use |
| and to avoid, linking and cross-referencing, etc. |
| |
| |
| [[introduction-asciidoc]] |
| == Asciidoctor Markup |
| |
| Vulkan Documentation is primarily written in Asciidoctor, a text markup |
| language. |
| We use the command-line asciidoctor client that is actively maintained by |
| asciidoctor, which is documented on its website at https://asciidoctor.org. |
| |
| References to the Asciidoctor User Manual are to sections in the document at |
| https://asciidoctor.org/docs/user-manual/. |
| |
| Asciidoctor is implemented in Ruby (https://www.ruby-lang.org/), which is |
| available for Linux, MacOS, and Microsoft Windows. |
| |
| [NOTE] |
| .Note |
| ==== |
| There are other implementations of asciidoctor, such as AsciidoctorJ |
| (https://github.com/asciidoctor/asciidoctorj) and asciidoctor.js |
| (https://github.com/asciidoctor/asciidoctor.js). |
| In particular, GitHub and GitLab both have preview renderers for .adoc or |
| .asciidoc files in repositories, and live preview extensions exist for |
| Chrome and Firefox. |
| |
| However, because of the use of custom Ruby macros in the Vulkan |
| Specification toolchain, and the high complexity of the documents and |
| toolchain used to generate it, these web tools cannot currently render the |
| Specification from source. |
| Instead, we generate HTML and PDF versions of the Specification and publish |
| them on the Khronos website. |
| |
| The Asciidoctor 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. |
| |
| [[acm-references]] |
| Association for Computing Machinery. |
| _Citation Style and Reference Formats_. |
| Retrieved July 27, 2019. |
| https://www.acm.org/publications/authors/reference-formatting . |
| |
| [[iso-8601]] |
| International Organization for Standardization. |
| _Data elements and interchange formats -- Information interchange -- |
| Representation of dates and times_ (2004-12-01). |
| https://www.iso.org/standard/40874.html . |
| Also see https://www.w3.org/QA/Tips/iso-date for colloquial examples. |
| |
| [[vulkan-docs]] |
| Khronos Vulkan Working Group. |
| `KhronosGroup/Vulkan-Docs` project on GitHub (July 5, 2016). |
| https://github.com/KhronosGroup/Vulkan-Docs . |
| |
| [[vulkan-registry]] |
| Jon Leech. |
| _The Khronos Vulkan API Registry_ (February 26, 2023). |
| https://registry.khronos.org/vulkan/specs/1.3/registry.html . |
| |
| [[vulkan-spec]] |
| Khronos Vulkan Working Group. |
| _Vulkan 1.3.242 - A Specification_ (February 26, 2023). |
| https://registry.khronos.org/vulkan/ . |
| |
| Version 1.3.242 is the latest patch release of the Vulkan API Specification |
| as of the time this reference was last updated, but the 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. |