2019-01-06 03:40:12 +00:00
|
|
|
// Copyright (c) 2015-2019 Khronos Group. This work is licensed under a
|
Change log for March 16, 2018 Vulkan 1.1.71 spec update:
* First public update for Vulkan 1.1.
Github Issues:
* Refer to standard sparse image block shape format tables explicitly in
the <<sparsememory-standard-shapes, Standard Sparse Image Block Shapes>>
section (public issue 93).
* Add the missing definition of the code:LocalInvocationIndex decoration
in the <<interfaces-builtin-variables, Built-In Variables>> section
(public issue 532).
* Clarify dynamic state definition in the introduction to the <<pipelines,
Pipelines>> section and the new <<pipelines-dynamic-state, Dynamic
State>> subsection (public issue 620).
* Clarified deprecation statement in the `VK_AMD_negative_viewport_height`
appendix (public issue 674).
* Fix parameter descriptions for flink:vkCreateIndirectCommandsLayoutNVX
(public issue 677).
Internal Issues:
* Remove description of <<primsrast-points, rasterization point size>>
being taken from the tessellation control shader, since there are no
circumstances under which you can have TCS without TES (internal issue
522).
* Define <<copies-images-format-size-compatibility, _size-compatible_
image formats>> for flink:vkCmdCopyImage, add it to the glossary, and
use that definition for slink:VkImageViewCreateInfo (internal issue
771).
* Change brief descriptions of enumerant names, and of parameters which
are enumerants, from "`enum *indicates*`" to "`enum *specifies*`" for
consistency, and add a markup style guide rule (internal issue 862).
* Clarify how execution dependencies interact with
<<synchronization-submission-order, submission order>> at numerous
places in the <<renderpass, Render Pass>> and <<synchronization,
Synchronization>> chapters (internal issue 1062).
* Clarify statement in the <<interfaces-resources-setandbinding,
DescriptorSet and Binding Assignment>> section that only interface
variables statically used by the entry point used in a pipeline must be
present in the descriptor set layout (internal issue 1172).
* Flip sparse image diagrams with partially full mip levels vertically, to
match graph origins of other image diagrams (internal issue 1176).
* Update new SVG diagrams to have consistent style and base font size,
increase consistency of primitive topology diagrams, and add a section
to the style guide on creating and editing images in a consistent style
(internal issue 1177).
* Resolve problems with valid usage statement extraction by fixing
existing VUID tags for interfaces promoted to version 1.1 and fixing
conditional directives around
VUID-VkMemoryDedicatedAllocateInfo-image-01797 (internal issue 1184).
* Strip `KHR` suffixes from a few interfaces promoted to Vulkan 1.1 that
were missed previously (internal issue 1185).
* Restrict code:OpImageQuerySizeLod and code:OpImageQueryLevels to only
work on code:Image operands with their code:Sampled operand set to 1. In
other words, these operations are not defined to work with storage
images (internal issue 1193).
* Recycle extension slot for extension #82 in `vk.xml`. This extension was
never published (internal issue 1195).
* Add an issue to the `VK_KHR_maintenance1` appendix noting that zero
height viewports are allowed when this extension is enabled (internal
issue 1202).
* Fix slink:VkDescriptorSetLayoutBinding description so that shader stages
always use descriptor bindings, not the other way around (internal issue
1206).
* Fix field name for
slink:VkInputAttachmentAspectReference::pname:inputAttachmentIndex
(internal issue 1210).
Other Issues:
* Fix a few broken links in the <<versions-1.1, Version 1.1>> appendix.
* Replace a few old refBegin/refEnd tags with open block markup around
interfaces, and remove old KHX VUID tags that were breaking the valid
usage statement extraction.
* Fix error codes accidentally tagged as success codes in `vk.xml` for
flink:vkGetSwapchainCounterEXT.
* Added valid usage statements for ftext:vkBind*Memory2 input structures
stext:VkBind*MemoryInfo, and fix a pname:image -> pname:buffer typo in a
couple of places.
* Fix swapped descriptions of elink:VkDescriptorType enums
ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE and
ename:VK_DESCRIPTOR_TYPE_STORAGE_IMAGE (reported via tweet).
New Extensions:
* `VK_ANDROID_external_memory_android_hardware_buffer`
2018-03-17 11:04:05 +00:00
|
|
|
// Creative Commons Attribution 4.0 International License; see
|
|
|
|
// http://creativecommons.org/licenses/by/4.0/
|
|
|
|
|
|
|
|
[[miscellaneous]]
|
|
|
|
= Image Authoring, Formats, and Style
|
|
|
|
|
|
|
|
Images used in the Vulkan documents must be kept in the directory `images/`
|
|
|
|
in SVG format.
|
|
|
|
|
|
|
|
Images should be authored in the open-source
|
|
|
|
https://inkscape.org/[`Inkscape`] tool, downloadable from its website or
|
|
|
|
packaged as an optional install for most Linux distributions.
|
|
|
|
This allows other people to easily edit your images in the future.
|
|
|
|
Also, while SVG is in principle a portable image format, some proprietary
|
|
|
|
image editors have been observed to produce images incompatible with the PDF
|
|
|
|
image pipeline used by the Specification.
|
|
|
|
|
|
|
|
Images must be authored at their actual image size in the HTML and PDF
|
|
|
|
output documents, and must not be scaled with asciidoctor options.
|
|
|
|
In most cases, images are included as standalone figures and should occupy
|
|
|
|
the full width of the document - don't leave unnecessary whitespace on
|
|
|
|
either side of the image.
|
|
|
|
|
|
|
|
The PDF output has an available width of just over 660px (at the default
|
|
|
|
96dpi), and a height somewhere around 1000px (which diagrams should really
|
|
|
|
go nowhere near anyway).
|
|
|
|
The html output is wider (800 pixels) and with practically unlimited height.
|
|
|
|
As the PDF dimensions are more restrictive, images should not exceed these
|
|
|
|
limits.
|
|
|
|
|
|
|
|
[NOTE]
|
|
|
|
.Note
|
|
|
|
====
|
|
|
|
According to the documentation available, the PDF output *should* have
|
|
|
|
dimensions of roughly 184mm x 271mm - or equivalently 697px x 1026px (A4
|
|
|
|
size [asciidoctor default] with a 0.5in margin [prawn-pdf default] on each
|
|
|
|
side).
|
|
|
|
However for reasons currently unknown, at least the available width before
|
|
|
|
images are scaled down lies is about 30-something pixels lower than that;
|
|
|
|
the height where this happens hasn't been measured, but is likely to
|
|
|
|
similarly be lower than it should be for reasons currently unknown.
|
|
|
|
====
|
|
|
|
|
|
|
|
Dimensions of elements in the SVG file should be authored in pixels (`px`)
|
|
|
|
such that lines/strokes are not unnecessarily anti-aliased (e.g. usually
|
|
|
|
stick to integer pixel widths for lines).
|
|
|
|
In many cases it is useful to also set the background grid to px, but it not
|
|
|
|
necessary; Inkscape has reliable conversions between px and mm using a
|
|
|
|
default dpi of 96 (which matches the PDF output), so the output dimension is
|
|
|
|
mostly irrelevant.
|
|
|
|
|
|
|
|
Text in images should usually appear at 12 point type so as to match that in
|
|
|
|
the body of the specification, though 10 point text can be used sparingly
|
|
|
|
where necessary (however this is often indicative of the diagram being too
|
|
|
|
cramped, so authors should consider scaling or reworking the diagram
|
|
|
|
instead).
|
|
|
|
Text should use the built-in generic sans serif font so as to ensure the
|
|
|
|
font in the output document matches whatever sans serif font is used for
|
|
|
|
that document.
|
|
|
|
Note that the character set is currently <<character-sets-in-svg,restricted
|
|
|
|
to Windows-1252>>.
|
|
|
|
|
|
|
|
The font and color scheme used for existing images (black, red, and 50%
|
|
|
|
gray) should be used for changes and new images whenever reasonable to do
|
|
|
|
so, to preserve a consistent look and feel.
|
|
|
|
Whilst a white background is typically assumed, explicitly adding white as a
|
|
|
|
color should be avoided - instead leave elements transparent so the diagrams
|
|
|
|
can be used in other documents.
|
|
|
|
|
|
|
|
Many other elements are consistent throughout the set of diagrams which
|
|
|
|
should be maintained in new diagrams where possible.
|
|
|
|
Examples include:
|
|
|
|
|
|
|
|
* Lines are usually either fully solid, or use a consistent, and
|
|
|
|
relatively spacious, dash style.
|
|
|
|
* Lines are capped with a consistent arrow shape where relevant.
|
|
|
|
* Small solid circles representing points are a consistently sized circle.
|
|
|
|
|
|
|
|
Whenever reasonable, it is advised to copy an existing similar diagram and
|
|
|
|
edit it rather than creating one from scratch in order to re-use elements
|
|
|
|
and maintain consistency.
|
|
|
|
|
|
|
|
|
|
|
|
[[character-sets-in-svg]]
|
|
|
|
== Character sets in SVG files
|
|
|
|
|
|
|
|
At the moment, the PDF conversion path only supports the Windows-1252
|
|
|
|
character set, as we are currently using the standard fonts built into every
|
|
|
|
PDF viewer - such that we don't have to embed a different font.
|
|
|
|
Unfortunately these only support Windows-1252, which is a highly limited
|
|
|
|
character set.
|
|
|
|
|
|
|
|
As such, characters not in that set will not display properly when present
|
|
|
|
in an SVG, and will fire a warning when building the PDF.
|
|
|
|
Luckily, Inkscape has an "Object to path" function built in, which will
|
|
|
|
convert text to a raw path, allowing these characters to be supported.
|
|
|
|
|
|
|
|
Please ensure that you build the PDF before submitting any new images,
|
|
|
|
particularly with non-standard characters, in order to catch such errors.
|
|
|
|
|
|
|
|
|
|
|
|
ifdef::editing-notes[]
|
|
|
|
[NOTE]
|
|
|
|
.editing-note
|
|
|
|
====
|
|
|
|
*Other Stuff Which May Be Described In This Chapter Eventually*
|
|
|
|
|
|
|
|
* Something about Image formats
|
|
|
|
* Something about validation scripts
|
|
|
|
* Glossary lists
|
|
|
|
* New param/enum macros
|
|
|
|
====
|
|
|
|
endif::editing-notes[]
|
|
|
|
|