Vulkan-Docs/doc/specs/vulkan/README.html

1340 lines
38 KiB
HTML

<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="generator" content="AsciiDoc 8.6.9">
<title>Vulkan Specification Build Instructions and Notes</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
/* Default font. */
body {
font-family: Georgia,serif;
}
/* Title font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
#toctitle,
#author, #revnumber, #revdate, #revremark,
#footer {
font-family: Arial,Helvetica,sans-serif;
}
body {
margin: 1em 5% 1em 5%;
}
a {
color: blue;
text-decoration: underline;
}
a:visited {
color: fuchsia;
}
em {
font-style: italic;
color: navy;
}
strong {
font-weight: bold;
color: #083194;
}
h1, h2, h3, h4, h5, h6 {
color: #527bbd;
margin-top: 1.2em;
margin-bottom: 0.5em;
line-height: 1.3;
}
h1, h2, h3 {
border-bottom: 2px solid silver;
}
h2 {
padding-top: 0.5em;
}
h3 {
float: left;
}
h3 + * {
clear: left;
}
h5 {
font-size: 1.0em;
}
div.sectionbody {
margin-left: 0;
}
hr {
border: 1px solid silver;
}
p {
margin-top: 0.5em;
margin-bottom: 0.5em;
}
ul, ol, li > p {
margin-top: 0;
}
ul > li { color: #aaa; }
ul > li > * { color: black; }
.monospaced, code, pre {
font-family: "Courier New", Courier, monospace;
font-size: inherit;
color: navy;
padding: 0;
margin: 0;
}
pre {
white-space: pre-wrap;
}
#author {
color: #527bbd;
font-weight: bold;
font-size: 1.1em;
}
#email {
}
#revnumber, #revdate, #revremark {
}
#footer {
font-size: small;
border-top: 2px solid silver;
padding-top: 0.5em;
margin-top: 4.0em;
}
#footer-text {
float: left;
padding-bottom: 0.5em;
}
#footer-badges {
float: right;
padding-bottom: 0.5em;
}
#preamble {
margin-top: 1.5em;
margin-bottom: 1.5em;
}
div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.admonitionblock {
margin-top: 2.0em;
margin-bottom: 2.0em;
margin-right: 10%;
color: #606060;
}
div.content { /* Block element content. */
padding: 0;
}
/* Block element titles. */
div.title, caption.title {
color: #527bbd;
font-weight: bold;
text-align: left;
margin-top: 1.0em;
margin-bottom: 0.5em;
}
div.title + * {
margin-top: 0;
}
td div.title:first-child {
margin-top: 0.0em;
}
div.content div.title:first-child {
margin-top: 0.0em;
}
div.content + div.title {
margin-top: 0.0em;
}
div.sidebarblock > div.content {
background: #ffffee;
border: 1px solid #dddddd;
border-left: 4px solid #f0f0f0;
padding: 0.5em;
}
div.listingblock > div.content {
border: 1px solid #dddddd;
border-left: 5px solid #f0f0f0;
background: #f8f8f8;
padding: 0.5em;
}
div.quoteblock, div.verseblock {
padding-left: 1.0em;
margin-left: 1.0em;
margin-right: 10%;
border-left: 5px solid #f0f0f0;
color: #888;
}
div.quoteblock > div.attribution {
padding-top: 0.5em;
text-align: right;
}
div.verseblock > pre.content {
font-family: inherit;
font-size: inherit;
}
div.verseblock > div.attribution {
padding-top: 0.75em;
text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
text-align: left;
}
div.admonitionblock .icon {
vertical-align: top;
font-size: 1.1em;
font-weight: bold;
text-decoration: underline;
color: #527bbd;
padding-right: 0.5em;
}
div.admonitionblock td.content {
padding-left: 0.5em;
border-left: 3px solid #dddddd;
}
div.exampleblock > div.content {
border-left: 3px solid #dddddd;
padding-left: 0.5em;
}
div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }
dl {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
dt {
margin-top: 0.5em;
margin-bottom: 0;
font-style: normal;
color: navy;
}
dd > *:first-child {
margin-top: 0.1em;
}
ul, ol {
list-style-position: outside;
}
ol.arabic {
list-style-type: decimal;
}
ol.loweralpha {
list-style-type: lower-alpha;
}
ol.upperalpha {
list-style-type: upper-alpha;
}
ol.lowerroman {
list-style-type: lower-roman;
}
ol.upperroman {
list-style-type: upper-roman;
}
div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
margin-top: 0.1em;
margin-bottom: 0.1em;
}
tfoot {
font-weight: bold;
}
td > div.verse {
white-space: pre;
}
div.hdlist {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
div.hdlist tr {
padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
font-weight: bold;
}
td.hdlist1 {
vertical-align: top;
font-style: normal;
padding-right: 0.8em;
color: navy;
}
td.hdlist2 {
vertical-align: top;
}
div.hdlist.compact tr {
margin: 0;
padding-bottom: 0;
}
.comment {
background: yellow;
}
.footnote, .footnoteref {
font-size: 0.8em;
}
span.footnote, span.footnoteref {
vertical-align: super;
}
#footnotes {
margin: 20px 0 20px 0;
padding: 7px 0 0 0;
}
#footnotes div.footnote {
margin: 0 0 5px 0;
}
#footnotes hr {
border: none;
border-top: 1px solid silver;
height: 1px;
text-align: left;
margin-left: 0;
width: 20%;
min-width: 100px;
}
div.colist td {
padding-right: 0.5em;
padding-bottom: 0.3em;
vertical-align: top;
}
div.colist td img {
margin-top: 0.3em;
}
@media print {
#footer-badges { display: none; }
}
#toc {
margin-bottom: 2.5em;
}
#toctitle {
color: #527bbd;
font-size: 1.1em;
font-weight: bold;
margin-top: 1.0em;
margin-bottom: 0.1em;
}
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
div.toclevel2 {
margin-left: 2em;
font-size: 0.9em;
}
div.toclevel3 {
margin-left: 4em;
font-size: 0.9em;
}
div.toclevel4 {
margin-left: 6em;
font-size: 0.9em;
}
span.aqua { color: aqua; }
span.black { color: black; }
span.blue { color: blue; }
span.fuchsia { color: fuchsia; }
span.gray { color: gray; }
span.green { color: green; }
span.lime { color: lime; }
span.maroon { color: maroon; }
span.navy { color: navy; }
span.olive { color: olive; }
span.purple { color: purple; }
span.red { color: red; }
span.silver { color: silver; }
span.teal { color: teal; }
span.white { color: white; }
span.yellow { color: yellow; }
span.aqua-background { background: aqua; }
span.black-background { background: black; }
span.blue-background { background: blue; }
span.fuchsia-background { background: fuchsia; }
span.gray-background { background: gray; }
span.green-background { background: green; }
span.lime-background { background: lime; }
span.maroon-background { background: maroon; }
span.navy-background { background: navy; }
span.olive-background { background: olive; }
span.purple-background { background: purple; }
span.red-background { background: red; }
span.silver-background { background: silver; }
span.teal-background { background: teal; }
span.white-background { background: white; }
span.yellow-background { background: yellow; }
span.big { font-size: 2em; }
span.small { font-size: 0.6em; }
span.underline { text-decoration: underline; }
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
div.unbreakable { page-break-inside: avoid; }
/*
* xhtml11 specific
*
* */
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.tableblock > table {
border: 3px solid #527bbd;
}
thead, p.table.header {
font-weight: bold;
color: #527bbd;
}
p.table {
margin-top: 0;
}
/* Because the table frame attribute is overriden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
border-style: none;
}
div.tableblock > table[frame="hsides"] {
border-left-style: none;
border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
border-top-style: none;
border-bottom-style: none;
}
/*
* html5 specific
*
* */
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
thead, p.tableblock.header {
font-weight: bold;
color: #527bbd;
}
p.tableblock {
margin-top: 0;
}
table.tableblock {
border-width: 3px;
border-spacing: 0px;
border-style: solid;
border-color: #527bbd;
border-collapse: collapse;
}
th.tableblock, td.tableblock {
border-width: 1px;
padding: 4px;
border-style: solid;
border-color: #527bbd;
}
table.tableblock.frame-topbot {
border-left-style: hidden;
border-right-style: hidden;
}
table.tableblock.frame-sides {
border-top-style: hidden;
border-bottom-style: hidden;
}
table.tableblock.frame-none {
border-style: hidden;
}
th.tableblock.halign-left, td.tableblock.halign-left {
text-align: left;
}
th.tableblock.halign-center, td.tableblock.halign-center {
text-align: center;
}
th.tableblock.halign-right, td.tableblock.halign-right {
text-align: right;
}
th.tableblock.valign-top, td.tableblock.valign-top {
vertical-align: top;
}
th.tableblock.valign-middle, td.tableblock.valign-middle {
vertical-align: middle;
}
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
vertical-align: bottom;
}
/*
* manpage specific
*
* */
body.manpage h1 {
padding-top: 0.5em;
padding-bottom: 0.5em;
border-top: 2px solid silver;
border-bottom: 2px solid silver;
}
body.manpage h2 {
border-style: none;
}
body.manpage div.sectionbody {
margin-left: 3em;
}
@media print {
body.manpage div#toc { display: none; }
}
</style>
<script type="text/javascript">
/*<![CDATA[*/
var asciidoc = { // Namespace.
/////////////////////////////////////////////////////////////////////
// Table Of Contents generator
/////////////////////////////////////////////////////////////////////
/* Author: Mihai Bazon, September 2002
* http://students.infoiasi.ro/~mishoo
*
* Table Of Content generator
* Version: 0.4
*
* Feel free to use this script under the terms of the GNU General Public
* License, as long as you do not remove or alter this notice.
*/
/* modified by Troy D. Hanson, September 2006. License: GPL */
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
// toclevels = 1..4.
toc: function (toclevels) {
function getText(el) {
var text = "";
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
text += i.data;
else if (i.firstChild != null)
text += getText(i);
}
return text;
}
function TocEntry(el, text, toclevel) {
this.element = el;
this.text = text;
this.toclevel = toclevel;
}
function tocEntries(el, toclevels) {
var result = new Array;
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
// Function that scans the DOM tree for header elements (the DOM2
// nodeIterator API would be a better technique but not supported by all
// browsers).
var iterate = function (el) {
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
var mo = re.exec(i.tagName);
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
}
iterate(i);
}
}
}
iterate(el);
return result;
}
var toc = document.getElementById("toc");
if (!toc) {
return;
}
// Delete existing TOC entries in case we're reloading the TOC.
var tocEntriesToRemove = [];
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
}
for (i = 0; i < tocEntriesToRemove.length; i++) {
toc.removeChild(tocEntriesToRemove[i]);
}
// Rebuild TOC entries.
var entries = tocEntries(document.getElementById("content"), toclevels);
for (var i = 0; i < entries.length; ++i) {
var entry = entries[i];
if (entry.element.id == "")
entry.element.id = "_toc_" + i;
var a = document.createElement("a");
a.href = "#" + entry.element.id;
a.appendChild(document.createTextNode(entry.text));
var div = document.createElement("div");
div.appendChild(a);
div.className = "toclevel" + entry.toclevel;
toc.appendChild(div);
}
if (entries.length == 0)
toc.parentNode.removeChild(toc);
},
/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////
/* Based on footnote generation code from:
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
*/
footnotes: function () {
// Delete existing footnote entries in case we're reloading the footnodes.
var i;
var noteholder = document.getElementById("footnotes");
if (!noteholder) {
return;
}
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
noteholder.removeChild(entriesToRemove[i]);
}
// Rebuild footnote entries.
var cont = document.getElementById("content");
var spans = cont.getElementsByTagName("span");
var refs = {};
var n = 0;
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnote") {
n++;
var note = spans[i].getAttribute("data-note");
if (!note) {
// Use [\s\S] in place of . so multi-line matches work.
// Because JavaScript has no s (dotall) regex flag.
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
spans[i].innerHTML =
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
spans[i].setAttribute("data-note", note);
}
noteholder.innerHTML +=
"<div class='footnote' id='_footnote_" + n + "'>" +
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
n + "</a>. " + note + "</div>";
var id =spans[i].getAttribute("id");
if (id != null) refs["#"+id] = n;
}
}
if (n == 0)
noteholder.parentNode.removeChild(noteholder);
else {
// Process footnoterefs.
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnoteref") {
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
href = href.match(/#.*/)[0]; // Because IE return full URL.
n = refs[href];
spans[i].innerHTML =
"[<a href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
}
}
}
},
install: function(toclevels) {
var timerId;
function reinstall() {
asciidoc.footnotes();
if (toclevels) {
asciidoc.toc(toclevels);
}
}
function reinstallAndRemoveTimer() {
clearInterval(timerId);
reinstall();
}
timerId = setInterval(reinstall, 500);
if (document.addEventListener)
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
else
window.onload = reinstallAndRemoveTimer;
}
}
asciidoc.install();
/*]]>*/
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
MathML: { extensions: ["content-mathml.js"] },
tex2jax: { inlineMath: [['$','$'], ['\\(','\\)']] }
});
</script>
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
</head>
<body class="article">
<div id="header">
<h1>Vulkan Specification Build Instructions and Notes</h1>
</div>
<div id="content">
<div id="preamble">
<div class="sectionbody">
<div class="ulist"><ul>
<li>
<p>
<a href="#intro">Introduction</a>
</p>
</li>
<li>
<p>
<a href="#building">Building the spec</a>
</p>
</li>
<li>
<p>
<a href="#macros">Our asciidoc macros</a>
</p>
</li>
<li>
<p>
<a href="#refpages">Reference Pages</a>
</p>
</li>
<li>
<p>
<a href="#styles">Our stylesheets</a>
</p>
</li>
<li>
<p>
<a href="#equations">Imbedding equations</a>
</p>
</li>
<li>
<p>
<a href="#anchors">Anchors and xrefs</a>
</p>
</li>
<li>
<p>
<a href="#depends">Software dependencies</a> (general and platform-specific)
</p>
</li>
<li>
<p>
<a href="#history">Revision history</a>
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="intro">Introduction</h2>
<div class="sectionbody">
<div class="paragraph"><p>This README describes important stuff for getting the Vulkan API
specification and reference pages building properly.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="building">Building The Spec</h2>
<div class="sectionbody">
<div class="paragraph"><p>Assuming you have all the right tools installed (see <a href="#depends">Software Dependencies</a> below), go to
<span class="monospaced">&#8230;path-to-git-repo/vulkan/doc/specs/vulkan</span> .</p></div>
<div class="paragraph"><p>If the default value of ASCIIDOC is not correct for the
<span class="monospaced">asciidoc</span> script on your platform, change it via
environment variables, command line options, or by modifying the
<span class="monospaced">Makefile</span>. The default script names have <span class="monospaced">.py</span> suffixes. These suffixes
should be removed for Linux platforms, and possibly for other
non-Windows environments.</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>$ make all</pre>
</div></div>
<div class="paragraph"><p>or equivalently:</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>$ make xhtml pdf styleguide manhtml manpdf manhtmlpages checkinc checklinks</pre>
</div></div>
<div class="paragraph"><p>will generate a variety of targets in the directory specified by the
Makefile variable <span class="monospaced">$(OUTDIR)</span> (by default, <span class="monospaced">../../../out/1.0</span>). The
checked-in file <span class="monospaced">../../../out/1.0/index.html</span> links to all these
targets, or they can individually be found as follows:</p></div>
<div class="ulist"><ul>
<li>
<p>
API spec:
</p>
<div class="ulist"><ul>
<li>
<p>
<span class="monospaced">xhtml</span> - Single-file XHTML in <span class="monospaced">$(OUTDIR)/xhtml/vkspec.html</span>
</p>
</li>
<li>
<p>
<span class="monospaced">pdf</span> - PDF in <span class="monospaced">$(OUTDIR)/pdf/vkspec.pdf</span>
</p>
</li>
</ul></div>
</li>
<li>
<p>
&#8220;Vulkan Documentation and Extensions&#8221; guide:
</p>
<div class="ulist"><ul>
<li>
<p>
<span class="monospaced">styleguide</span> - Single-file HTML5 in <span class="monospaced">$(OUTDIR)/styleguide.html</span>
</p>
</li>
</ul></div>
</li>
<li>
<p>
Reference pages:
</p>
<div class="ulist"><ul>
<li>
<p>
<span class="monospaced">manhtml</span> - Single-file HTML in <span class="monospaced">$(OUTDIR)/apispec.html</span>
</p>
</li>
<li>
<p>
<span class="monospaced">manpdf</span> - Single-file PDF in <span class="monospaced">$(OUTDIR)/apispec.html</span>
</p>
</li>
<li>
<p>
<span class="monospaced">manhtmlpages</span> - File-per-entry-point HTML in <span class="monospaced">$(OUTDIR)/man/html/*</span>
</p>
</li>
</ul></div>
</li>
<li>
<p>
Validator output:
</p>
<div class="ulist"><ul>
<li>
<p>
<span class="monospaced">checkinc</span> - List of commands, structs, etc. missing from the API
spec in <span class="monospaced">$(OUTDIR)/checks/notInSpec.txt</span>
</p>
</li>
<li>
<p>
<span class="monospaced">checklinks</span> - Validator script output for API spec in
<span class="monospaced">$(OUTDIR)/checks/specErrs.txt and for reference pages in
+$(OUTDIR)/checks/manErrs.txt</span>
</p>
</li>
</ul></div>
</li>
</ul></div>
<div class="paragraph"><p>Once you have the basic build working, an appropriate parallelization
option to make, such as</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>$ make -j 8</pre>
</div></div>
<div class="paragraph"><p>may significantly speed up the reference page builds.</p></div>
<div class="paragraph"><p>If your asciidoc installation does not put the stylesheets and xsl files in
the standard <span class="monospaced">/etc/asciidoc/dblatex</span> directory, set the environment variable
<span class="monospaced">DBLATEXPREFIX</span> to the path to that directory (the one containing the
<span class="monospaced">asciidoc-dblatex.xsl</span> and <span class="monospaced">asciidoc-dblatex.sty</span> files installed with
asciidoc).</p></div>
<div class="paragraph"><p>The <span class="monospaced">manpages</span> target is deprecated, as the resulting Unix man pages have
issues with content like embedded latexmath: constructs, but is still
available for third parties wishing to generate them:</p></div>
<div class="ulist"><ul>
<li>
<p>
<span class="monospaced">manpages</span> - File-per-entry-point nroff source in <span class="monospaced">$(OUTDIR)/man/3/*</span>
</p>
</li>
</ul></div>
<div class="sect2">
<h3 id="building-extensions">Building With Extensions Included</h3>
<div class="paragraph"><p>As of version 1.0.25 of the Specification, we are using a &#8220;single-branch
model&#8221;, where extensions are included in the same <span class="monospaced">1.0</span> branch as the core
Specification, instead of the older model where each extension lived in a
separate Git branch. Whether a given extension is generated in the output
depends on asciidoc and generator script options being specified.</p></div>
<div class="paragraph"><p>The extensions included are those specified as a space-separated list of
extension names (e.g. <span class="monospaced">VK_KHR_surface</span>) in the Makefile variable
<span class="monospaced">$(EXTENSIONS)</span>, normally set on the make command line. When changing
the list of extensions, it is critical to remove all generated files
using the <span class="monospaced">clean_generated</span> Makefile target, as the contents of
generated files depends on <span class="monospaced">$(EXTENSIONS)</span>. There are two helper scripts
which clean these files and then build one or more specified targets for
specified extensions:</p></div>
<div class="ulist"><ul>
<li>
<p>
<span class="monospaced">makeExt</span> - generate outputs with a single extension enabled. Usage is
<span class="monospaced">makeExt extension-name target(s)</span>, where <span class="monospaced">extension-name</span> is the
extension name string, such as <span class="monospaced">VK_EXT_debug_report</span>.
</p>
</li>
<li>
<p>
<span class="monospaced">makeKHR</span> - generate outputs with all Khronos (<span class="monospaced">VK_KHR_*</span>) extensions
enabled. Usage is <span class="monospaced">makeKHR target(s)</span>.
</p>
</li>
</ul></div>
<div class="paragraph"><p>The Makefile variable <span class="monospaced">$(APITITLE)</span> defines an additional string which is
appended to the specification title. When building with extensions enabled,
this should be set to something like <span class="monospaced">(with extension VK_extension_name)</span>.
The <span class="monospaced">makeExt</span> and <span class="monospaced">makeKHR</span> scripts already do this.</p></div>
</div>
<div class="sect2">
<h3 id="building-test">Alternate and Test Builds</h3>
<div class="paragraph"><p>If you are just testing asciidoc formatting, macros, stylesheets, etc.,
it is much faster to edit <span class="monospaced">vkspec.txt</span> to comment out most of the chapter
includes.</p></div>
<div class="paragraph"><p>In addition to the XHTML and PDF targets, there is also a single-file HTML5
target, <span class="monospaced">html</span>, which generates output directly from asciidoc without going
through Docbook. This is quicker to generate, but formatting and section
numbers aren&#8217;t neccessarily consistent with the other builds and it is not for
publication - just testing. The <span class="monospaced">html</span> target will generate the file
<span class="monospaced">$(OUTDIR)/html/vkspec.html</span> .</p></div>
</div>
<div class="sect2">
<h3 id="_rebuilding_the_generated_images">Rebuilding The Generated Images</h3>
<div class="paragraph"><p>There are some images in the <span class="monospaced">images/</span> directory which are maintained in one
format but need to be converted to another format for corresponding types of
output. Most are SVG converted to PDF, some are PPT converted to PDF
converted to SVG. SVG and PDF forms are needed for the HTML and PDF output
formats, respectively.</p></div>
<div class="paragraph"><p>These files are not automatically converted by the Makefile. Instead, all
output forms required are checked into <span class="monospaced">images/</span> . On the rare occasions that
someone changes a source document and needs to regenerate the other forms:</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>cd images
make</pre>
</div></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="macros">Our Asciidoc Macros</h2>
<div class="sectionbody">
<div class="paragraph"><p>We use a bunch of custom macros in the reference pages and API spec asciidoc
sources. The validator scripts rely on these macros as part of their sanity
checks, and you should use the macros whenever referring to an API command,
struct, token, or enum name, so the documents are semantically tagged and
more easily verifiable.</p></div>
<div class="paragraph"><p>The supported macros are defined in <span class="monospaced">config/vkspec.conf</span> (for the API spec)
and <span class="monospaced">config/manpages.conf</span> (for the reference pages).</p></div>
<div class="paragraph"><p>The tags used are described in the style guide (<span class="monospaced">styleguide.txt</span>).</p></div>
<div class="paragraph"><p>We will eventually tool up the spec and ref pages to the point that anywhere
there&#8217;s a type or token referred to, clicking on (or perhaps hovering over)
it in the HTML view and be taken to the definition of that type/token. That
will take some more plumbing work to tag the stuff in the autogenerated
include files, and do something sensible in the spec (e.g. resolve links to
internal references).</p></div>
<div class="paragraph"><p>Most of these macros deeply need more intuitive names.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="refpages">Reference Pages</h2>
<div class="sectionbody">
<div class="paragraph"><p>Prior to the 1.0.20 update of the API spec, the reference pages in <span class="monospaced">man/</span>
were handwritten, incomplete, and often way out of date with respect to the
spec.</p></div>
<div class="paragraph"><p>Our initial effort to address this was to tag the API spec to help identify
boundaries of language talking about different commands, structures,
enumerants, and other types, then use a set of Python scripts to
automatically extract that language into the corresponding ref page. Pages
without corresponding content in the API spec are generated automatically,
when possible.</p></div>
<div class="paragraph"><p>This has generated a semantically complete set of ref pages. Although they
are still far from ideal, they now fully document the API, and will stay in
sync with it.</p></div>
<div class="paragraph"><p>If for some reason you want to regenerate the ref pages from scratch
yourself, you can do so by</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>$ rm man/apispec.txt
$ make apispec.txt</pre>
</div></div>
<div class="paragraph"><p>The <span class="monospaced">genRef.py</span> script will generate many warnings, but most are just
reminders that some pages are automatically generated. If everything is
working correctly, all the <span class="monospaced">man/*.txt</span> files will be regenerated, but their
contents will not change.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="styles">Our stylesheets</h2>
<div class="sectionbody">
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">Section mostly TBD.</td>
</tr></table>
</div>
<div class="paragraph"><p>There is a Vulkan-specific XHTML CSS stylesheet in
<span class="monospaced">config/vkspec-xhtml.css</span> . It started as a clone of the default
Asciidoc stylesheet, but added some new features. Similar CSS in
<span class="monospaced">config/vkman.css</span> is used for the reference pages.</p></div>
<div class="sect2">
<h3 id="_marking_changes">Marking Changes</h3>
<div class="paragraph"><p>There is the start of support for marking added, removed, and changed text
in the spec body. Currently this is supported <strong>only</strong> in the XHTML targets
(<span class="monospaced">xhtml</span> and <span class="monospaced">chunked</span>), and <strong>only</strong> for paragraphs and spans of words.</p></div>
<div class="paragraph"><p>Added, removed, and changed material is marked with the asciidoc <strong>roles</strong>
named <em>added</em>, <em>removed</em>, and <em>changed</em> respectively. They can be used to
mark an entire paragraph, as follows:</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>[role="change"]
This paragraph shows change markings.</pre>
</div></div>
<div class="paragraph"><p>Or a few words in a sentence, as follows:</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>This sentence contains [added]#some added words# and [removed]#some
removed words#.</pre>
</div></div>
<div class="paragraph"><p>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.</p></div>
<div class="paragraph"><p>We don&#8217;t use this capability yet; it&#8217;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.</p></div>
</div>
<div class="sect2">
<h3 id="_marking_normative_language">Marking Normative Language</h3>
<div class="paragraph"><p>There is support for marking normative language in the document. Currently
this is supported <strong>only</strong> in the XHTML targets (<span class="monospaced">xhtml</span> and <span class="monospaced">chunked</span>).</p></div>
<div class="paragraph"><p>Normative language is marked with the asciidoc <strong>role</strong> named <em>normative</em>.
It can be used to mark entire paragraphs or spans of words, in the
same fashion as change markings (described above). In addition, the
normative terminology macros, such as <span role="normative">must</span> and <span role="normative">may</span> and <span role="normative">cannot</span>,
always use this role.</p></div>
<div class="paragraph"><p>The formatting of normative language depends on the stylesheet. Currently it
just comes out in purple. We may add a way to disable this formatting at
build time.</p></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="equations">Imbedding Equations</h2>
<div class="sectionbody">
<div class="paragraph"><p>Equations should be written using the latexmath: inline and block macros.
The contents of the latexmath: blocks should be LaTeX math notation,
surrounded by appropriate delimiters - $$, \[\], \(\),
or \begin{env}/\end{env} math environments such as {equation*}
or {align*}.</p></div>
<div class="paragraph"><p>The asciidoc macros and configuration files, as well as the dblatex
customization layers, have been modified significantly so that LaTeX math is
passed through unmodified to all HTML output forms (using the MathJax engine
for real-time rendering of equations) and to dblatex for PDF output.</p></div>
<div class="paragraph"><p>The following caveats apply:</p></div>
<div class="ulist"><ul>
<li>
<p>
The special characters <span class="monospaced">&lt;</span> , <span class="monospaced">&gt;</span> , and <span class="monospaced">&amp;</span> can currently be used only in
[latexmath] block macros, not in latexmath:[] inline macros.
Instead use <span class="monospaced">\lt</span> for <span class="monospaced">&lt;</span> and <span class="monospaced">\gt</span> for <span class="monospaced">&gt;</span>. <span class="monospaced">&amp;</span> is an alignment construct
for multiline equations, and should only appear in block macros anyway.
</p>
</li>
<li>
<p>
AMSmath environments (e.g. \begin{equation*}, {align*},
etc.) can be used, to the extent MathJax supports them.
</p>
</li>
<li>
<p>
When using AMSmath environments, do <strong>not</strong> also surround the equation block
with \[\] brackets. That is not legal LaTeX math and will break the
PDF build. It is good practice to make sure all spec targets build
properly before proposing a merge to master.
</p>
</li>
<li>
<p>
Arbitrary LaTeX constructs cannot be used with MathJax. It is an equation
renderer, not an full LaTeX engine. So imbedding LaTeX like \Large or
\hbox{\tt\small VK\_FOO} may not work in any of the HTML backends,
and should be avoided.
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="anchors">Asciidoc Anchors And Xrefs</h2>
<div class="sectionbody">
<div class="paragraph"><p>In the API spec, sections can have anchors (labels) applied with the
following syntax. In general the anchor should immediately precede the
chapter or section title and should use the form
<em>[[chapter-section-label]]</em>. For example,</p></div>
<div class="paragraph"><p>For example, in chapter <span class="monospaced">synchronization.txt</span>:</p></div>
<a id="synchronization-primitives"></a>
Synchronization Primitives
<div class="paragraph"><p>Cross-references to those anchors can then be generated with, for example,</p></div>
See the <<synchronization-primitives>> section for discussion
of fences, semaphores, and events.
<div class="paragraph"><p>You can also add anchors on arbitrary paragraphs, using a similar naming
scheme.</p></div>
<div class="paragraph"><p>Anything whose definition comes from one of the autogenerated API include
files (<span class="monospaced">.txt</span> files in the directories <span class="monospaced">basetypes</span>, <span class="monospaced">enums</span>, <span class="monospaced">flags</span>,
<span class="monospaced">funcpointers</span>, <span class="monospaced">handles</span>, <span class="monospaced">protos</span>, and <span class="monospaced">structs</span>) has a corresponding
anchor whose name is the name of the function, struct, etc. being defined.
Therefore you can say something like:</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>Fences are used with the +++&lt;&lt;vkQueueSubmit&gt;&gt;+++ command...</pre>
</div></div>
</div>
</div>
<div class="sect1">
<h2 id="depends">Software Dependencies</h2>
<div class="sectionbody">
<div class="paragraph"><p>This section describes the software components used by the Vulkan spec
toolchain. under the <a href="#depends-general">General Dependencies</a> below, then
describes specific considerations for Windows environments using Cygin under
<a href="#depends-cygwin">Cygwin Dependencies</a></p></div>
<div class="sect2">
<h3 id="depends-general">General Dependencies</h3>
<div class="paragraph"><p>These are versions of required tools in one of the editors' development
environment (Debian 8, shown as Debian package names). Earlier versions
<strong>may</strong> work but unless they are verified by someone else, there&#8217;s no way to
know that. Later versions should work.</p></div>
<div class="ulist"><ul>
<li>
<p>
GNU make (make version: 4.0.8-1; older versions probably OK)
</p>
</li>
<li>
<p>
Asciidoc (asciidoc version: 8.6.9-3)
</p>
</li>
<li>
<p>
Python 3 (python, version: 3.4.2)
</p>
</li>
<li>
<p>
Git command-line client (git, version: 2.1.4)
Only needed if regenerating specversion.txt. Any version supporting the
operations
&#8201;&#8212;&#8201;<span class="monospaced">git symbolic-ref --short HEAD</span> and
&#8201;&#8212;&#8201;<span class="monospaced">git log -1 --format="%H"</span> should work).
</p>
</li>
<li>
<p>
Docbook LaTeX toolchain (dblatex, version: 0.3.5-2)
</p>
</li>
<li>
<p>
Source code highlighter (source-highlight, version: 3.1.7-1+b1)
</p>
</li>
<li>
<p>
LaTeX distribution (texlive, version: 2014.20141024-2)
</p>
</li>
</ul></div>
</div>
<div class="sect2">
<h3 id="depends-cygwin">Cygwin Dependencies</h3>
<div class="paragraph"><p>The cygwin installer is at <a href="http://www.cygwin.org">http://www.cygwin.org</a>. Use the 64-bit version,
because the 32-bit version does not include the latest version of asciidoc
required for this project.</p></div>
<div class="paragraph"><p>Required Cygwin packages (current version):</p></div>
<div class="ulist"><ul>
<li>
<p>
Devel/make (4.1-1)
</p>
</li>
<li>
<p>
Python/python (2.7.10-1) - Needed for asciidoc toolchain
</p>
</li>
<li>
<p>
Python/python3 (3.4.3-1)
</p>
</li>
<li>
<p>
Python/python3-lxml (3.4.4-1) - Needed for generating vulkan.h
</p>
</li>
<li>
<p>
Text/asciidoc (8.6.8-1)
</p>
</li>
<li>
<p>
Text/dblatex (0.3.4-1)
</p>
</li>
<li>
<p>
Text/source-highlight (3.1.8-1)
</p>
</li>
</ul></div>
<div class="paragraph"><p>Optional Cygwin packages (current version):</p></div>
<div class="ulist"><ul>
<li>
<p>
Devel/gcc-core (4.9.3-1) - Needed for validating generated headers
</p>
</li>
<li>
<p>
Devel/gcc-g++ (4.9.3-1) - Needed for validating generated headers
</p>
</li>
<li>
<p>
Devel/git (2.5.1-1) - Needed for updating specversion.txt
</p>
</li>
</ul></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="history">Revision History</h2>
<div class="sectionbody">
<div class="ulist"><ul>
<li>
<p>
2016/08/25 - Update for the single-branch model.
</p>
</li>
<li>
<p>
2016/07/10 - Update for current state of spec and ref page generation.
</p>
</li>
<li>
<p>
2015/11/11 - Add new <span role="normative">can</span> etc. macros and DBLATEXPREFIX variable.
</p>
</li>
<li>
<p>
2015/09/21 - Convert document to asciidoc and rename to README.md
in the hope the gitlab browser will render it in some fashion.
</p>
</li>
<li>
<p>
2015/09/21 - Add descriptions of LaTeX+MathJax math support for all
output formats.
</p>
</li>
<li>
<p>
2015/09/02 - Added Cygwin package info.
</p>
</li>
<li>
<p>
2015/09/02 - Initial version documenting macros, required toolchain
components and versions, etc.
</p>
</li>
</ul></div>
</div>
</div>
</div>
<div id="footnotes"><hr></div>
<div id="footer">
<div id="footer-text">
Last updated
2016-08-26 17:00:49 PDT
</div>
</div>
</body>
</html>