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

1334 lines
34 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>
</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="#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), you should be able to go to
&#8230;path-to-git-repo/vulkan/doc/specs/vulkan and:</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 chunked pdf manhtml manpdf manpages manhtmlpages checkinc checklinks</pre>
</div></div>
<div class="paragraph"><p>This should generate a variety of targets under $(OUTDIR) (by default,
../../../out/). The checked-in file $(OUTDIR)/index.html links to them
all, 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>
Single-file XHTML (from a2x) - $(OUTDIR)/xhtml/vkspec.html
</p>
</li>
<li>
<p>
Chunked HTML (from a2x) - $(OUTDIR)/vkspec.chunked/index.html
</p>
</li>
<li>
<p>
PDF (from a2x) - $(OUTDIR)/pdf/vkspec.pdf
</p>
</li>
</ul></div>
</li>
<li>
<p>
Man pages:
</p>
<div class="ulist"><ul>
<li>
<p>
Single-file HTML - $(OUTDIR)/apispec.html
</p>
</li>
<li>
<p>
File-per-entry-point HTML - $(OUTDIR)/man/html/*
</p>
</li>
<li>
<p>
File-per-entry-point nroff source - $(OUTDIR)/man/3/*
</p>
</li>
</ul></div>
</li>
<li>
<p>
Validator output:
</p>
<div class="ulist"><ul>
<li>
<p>
List of commands, structs, etc. missing from the API spec -
$(OUTDIR)/checks/notInSpec.txt
</p>
</li>
<li>
<p>
Validator script output for API spec - $(OUTDIR)/checks/specErrs.txt
</p>
</li>
<li>
<p>
Validator script output for reference pages -
$(OUTDIR)/checks/manErrs.txt
</p>
</li>
</ul></div>
</li>
</ul></div>
<div class="paragraph"><p>We strongly sugges that once you have the basic build working, you use e.g.
<em>-j 8</em> (or other appropriate number depending on the number of cores in your
CPU) to parallelize the reference page builds, since there are so many of
them.</p></div>
<div class="paragraph"><p>If your asciidoc installation does not put the stylesheets and xsl files in
the standard /etc/asciidoc/dblatex directory, set the environment variable
DBLATEXPREFIX to the path to that directory (the one containing the
asciidoc-dblatex.xsl and asciidoc-dblatex.sty installed with asciidoc).</p></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., you
can edit test.txt, which is a stripped-down version of vkspec.txt,
and build an alternate version of the spec with either</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>$ make TOPDOCHTML=test.txt xhtml</pre>
</div></div>
<div class="paragraph"><p>or the simpler</p></div>
<div class="literalblock">
<div class="content monospaced">
<pre>tmake xhtml</pre>
</div></div>
<div class="paragraph"><p>This example will generate the file $(OUTDIR)/xhtml/test.html . Note that
TOPDOCHTML only applies to the xhtml and chunked targets at present.</p></div>
<div class="paragraph"><p>In addition to the XHTML and PDF targets, there is also a single-file HTML5
target, <em>html</em>, which generates output directly from asciidoc without going
through Docbook. This is somewhat quicker to generate, but formatting and
section numbers aren&#8217;t consistent with the other builds and it is not for
publication - just testing. The <em>html</em> target will generate the file
$(OUTDIR)/html/vkspec.html .</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 images/ 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 images/ . On the rare occasions that
someone changes a source document and needs to regenerate the other forms,
go into images and <em>make</em> in the directory.</p></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 config/vkspec.conf (for the API spec)
and config/manpages.conf (for the reference pages).</p></div>
<div class="paragraph"><p>Tags used in both the specification and reference pages:</p></div>
<div class="ulist"><ul>
<li>
<p>
flink:vkBlah - the name of an API command.
</p>
</li>
<li>
<p>
fname:vkBlah - the name of an API command.
</p>
</li>
<li>
<p>
ftext:anything - the name of something that looks like an API command, but
isn&#8217;t (wildcards like ftext:vkCmd*).
</p>
</li>
<li>
<p>
slink:VkBlah - the name of an API C structure, handle, or scalar type. The
slink:VkBlah.membername syntax is <strong>not</strong> currently supported.
</p>
</li>
<li>
<p>
sname:VkBlah - the name of an API C structure, handle, or scalar type. The
notation sname:VkBlah.membername is also allowed where that makes sense
(NOTE: VkBlah.membername is <strong>not</strong> properly validated at present).
</p>
</li>
<li>
<p>
stext:anything - the name of something that looks like an API structure,
handle, or scalar type, but isn&#8217;t (wildcards like stext:Vk*CreateInfo).
</p>
</li>
<li>
<p>
elink:VkBlahFlags - the name of an API C "enum" type (bitmask or
enumeration).
</p>
</li>
<li>
<p>
ename:VK_BLAH - the name of an API enumeration or #define token.
</p>
</li>
<li>
<p>
etext:anything - the name of something that looks like an API "enum" type,
enumeration or #define token, but isn&#8217;t (wildcards or partial token names,
like etext:BC5).
</p>
</li>
<li>
<p>
pname:param - the name of a command parameter or struct member being
documented
</p>
</li>
<li>
<p>
basetype:type - the name of a base scalar type, such as basetype:VkBool32.
</p>
</li>
<li>
<p>
code:varname - the name of a shading language variable
</p>
</li>
</ul></div>
<div class="paragraph"><p>Tags used only in the specification, at present:</p></div>
<div class="ulist"><ul>
<li>
<p>
can:, cannot:, may:, maynot:, must:, mustnot:, optional:, recommend:,
required:, should:, and shouldnot: - used to tag places in the spec where
these terms are used in accordance with their definitions in section 1.3
"Terminology". They do not currently do anything but expand to their names
(adding a space for e.g. mustnot: &#8594; must not), but may be used to
generate an index or some visual indicator in the future.
</p>
</li>
</ul></div>
<div class="paragraph"><p>The [efs]link: macros are used for validation, and are also expanded into
xref links to the correspondingly named anchor.</p></div>
<div class="paragraph"><p>The [efsp]name: macros are used for validation, but are <strong>not</strong> expanded into
links.</p></div>
<div class="paragraph"><p>The [efs]text: macros are not used for validation, and are not expanded into
links.</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, you could click/hover on 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>In that light, the [fs]name: vs. [fs]link: distinction seems mostly
unneeded. Probably the only time we would not want a tag to be a link to its
definition is when tagging a function name inside its own ref page. So once
the plumbing is done, most of the [fs]name: tags can turn into [fs]link:
tags.</p></div>
<div class="paragraph"><p>The ename: vs. elink: distinction is different since they&#8217;re referring to
different namespaces - individual enumerant names vs. "enum" type names -
rather than different ways of presenting the same command or struct name as
for the other tags.</p></div>
<div class="paragraph"><p>Most of these macros deeply need more intuitive names.</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>This branch introduces a Vulkan-specific XHTML CSS stylesheet
in config/vkspec-xhtml.css. Mostly it just clones the default
Asciidoc stylesheet, but adds some new features:</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
(<em>xhtml</em> and <em>chunked</em>), 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>
<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 (<em>xhtml</em> and <em>chunked</em>).</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 must: and may: and cannot:,
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. There will be some way to turn this on or off at
build time shortly.</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 &lt; &gt; &amp; can currently be used only in
[latexmath] block macros, not in latexmath:[] inline macros.
Instead use \lt for &lt; and \gt for &gt;. &amp; 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 stuff like \Large or
\hbox{\tt\small VK\_FOO} does 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 <em>synchronization.txt</em>:</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 ({protos,flags,enums,structs}/*.txt) 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 Jon&#8217;s 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 / a2x (asciidoc version: 8.6.9-3)
</p>
</li>
<li>
<p>
Python 3 (python, version: 3.4.2)
</p>
</li>
<li>
<p>
Python LXML library (python-lxml, version: 3.4.0-1)
</p>
</li>
<li>
<p>
Git command-line client (git, version: 2.1.4)
Only needed if regenerating specversion.txt. Any version supporting the
operations <em>git symbolic-ref --short HEAD</em> and <em>git log -1
--format="%H"</em> 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-cygin">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>
2015/11/11 - Add new can: 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
2015-11-20 03:16:40 PST
</div>
</div>
</body>
</html>