Fix random grammar

This commit is contained in:
Petr Kraus 2017-12-15 21:01:02 +01:00
parent 2f5bc66d7a
commit b586690671
34 changed files with 77 additions and 74 deletions

View File

@ -85,7 +85,7 @@ to use the extension.
using the new relaxed mode?
*RESOLVED*: No.
The rasterization order is completely implementation dependent in this case
In this case the rasterization order is completely implementation dependent,
but in practice it is expected to partially still follow the order of
incoming primitives.

View File

@ -18,11 +18,11 @@ compressed multisampled color surfaces.
The fragment mask is a lookup table that associates color samples with color
fragment values.
The fragment mask can be fetched with a call to code:fragmentMaskFetchAMD
from a shader, which returns a single code:uint where each subsequent 4 bit
specifies the color fragment index corresponding to the color sample,
starting from the least significant bit.
For example, when 8 color samples are used, the color fragment index for
From a shader, the fragment mask can be fetched with a call to
code:fragmentMaskFetchAMD, which returns a single code:uint where each
subsequent four bits specify the color fragment index corresponding to the
color sample, starting from the least significant bit.
For example, when eight color samples are used, the color fragment index for
color sample 0 will be in bits 0-3 of the fragment mask, for color sample 7
the index will be in bits 28-31.

View File

@ -23,8 +23,8 @@ Firstly, support for the following SPIR-V extension in Vulkan is added:
* +SPV_AMD_texture_gather_bias_lod+
Secondly, the extension allows the application to query, which formats can
be used together with the new function prototypes introduced by the SPIR-V
Secondly, the extension allows the application to query which formats can be
used together with the new function prototypes introduced by the SPIR-V
extension.
=== New Object Types

View File

@ -9,7 +9,7 @@ This extension adds a number of "`advanced`" blending operations that can:
be used to perform new color blending operations, many of which are more
complex than the standard blend modes provided by unextended Vulkan.
This extension requires different styles of usage, depending on the level of
hardware support and the feature enable:
hardware support and the enabled features:
- If
slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::pname:advancedBlendCoherentOperations

View File

@ -155,7 +155,7 @@ While this fits with other Vulkan patterns and would allow more type safety
and future proofing against future objects, it has notable downsides.
In particular passing the name at stext:Vk*CreateInfo time does not allow
renaming, prevents late binding of naming information, and does not allow
naming of implicitly created objects such as queues and swap chain images.
naming of implicitly created objects such as queues and swapchain images.
2) Should the command annotation functions flink:vkCmdDebugMarkerBeginEXT
and flink:vkCmdDebugMarkerEndEXT support the ability to specify a color?

View File

@ -165,14 +165,14 @@ But it is not a requirement of this extension.
It is possible that a layer may intercept and change, or augment the flags
with extension values the application's debug report handler may not be
familiar with so it is important to treat each flag independently.
familiar with, so it is important to treat each flag independently.
2) Should there be a VU requiring
slink:VkDebugReportCallbackCreateInfoEXT::pname:flags to be non-zero?
*RESOLVED*: It may not be very useful, but we do not need VU statement
requiring the sname:VkDebugReportCallbackCreateInfoEXT::pname:msgFlags at
create-time be non-zero.
create-time to be non-zero.
One can imagine that apps may prefer it as it allows them to set the mask as
desired - including nothing - at runtime without having to check.

View File

@ -28,8 +28,8 @@ They need to know when presentable images were actually presented, and when
they could have been presented.
Applications also need to tell the presentation engine to display an image
no sooner than a given time.
This can allow the application's animation to look smooth to the user, with
no stuttering.
This allows the application to avoid stuttering, so the animation looks
smooth to the user.
This extension treats variable-refresh-rate (VRR) displays as if they are
fixed-refresh-rate (FRR) displays.

View File

@ -222,8 +222,8 @@ These objects can not be destroyed.
A future extension may be added to expose a way to destroy these objects
and/or support display hotplug.
19) Should persistent mode for smart panels be enabled/disabled at swap
chain creation time, or on a per-present basis.
19) Should persistent mode for smart panels be enabled/disabled at swapchain
creation time, or on a per-present basis.
*RESOLVED*: On a per-present basis.

View File

@ -125,7 +125,7 @@ Options for defining this transition include:
A new structure has the advantage that the type of external transition can
be described in as much detail as necessary.
However, there is not currently a known need for anything beyond
differentiating external Vs internal accesses, so this is likely an
differentiating external vs. internal accesses, so this is likely an
over-engineered solution.
The access flag bit has the advantage that it can be applied at buffer,
image, or global granularity, and semantically it maps pretty well to the
@ -248,7 +248,7 @@ exported memory object.
as input to memory import operations?
*RESOLVED*: Implementations must return an error to the application if the
provided memory handle can not be used to complete the requested import
provided memory handle cannot be used to complete the requested import
operation.
However, implementations need not validate handles are of the exact type
specified by the application.

View File

@ -66,7 +66,7 @@ OS-native objects that have far more limited capabilities than the very
generic Vulkan memory objects.
Not all memory handle types can name memory objects that support 3D images,
for example.
Some handle types can not even support the deferred image and memory binding
Some handle types cannot even support the deferred image and memory binding
behavior of Vulkan and require specifying the image when allocating or
importing the memory object.

View File

@ -13,7 +13,7 @@ include::meta/VK_KHR_push_descriptor.txt[]
- Michael Worcester, Imagination Technologies
This extension allows descriptors to be written into the command buffer,
with the implementation being responsible for managing their memory.
while the implementation is responsible for managing their memory.
Push descriptors may enable easier porting from older APIs and in some cases
can be more efficient than writing descriptors into descriptor sets.

View File

@ -28,7 +28,7 @@ surface or window objects for use with Vulkan.
It also provides a way to determine whether a queue family in a physical
device supports presenting to particular surface.
Separate extensions for each each platform provide the mechanisms for
Separate extensions for each platform provide the mechanisms for
creating slink:VkSurfaceKHR objects, but once created they may be used in
this and other platform-independent extensions, in particular the
+VK_KHR_swapchain+ extension.
@ -117,7 +117,7 @@ in many applications and likely will remain in use for the foreseeable
future.
Not all drivers necessarily need to support both, but including both as
options in the core specification will probably encourage support, which
should in turn eases adoption of the Vulkan API in older codebases.
should in turn ease adoption of the Vulkan API in older codebases.
Additionally, the performance improvements possible with XCB likely will not
have a measurable impact on the performance of Vulkan presentation and other
minimal window system interactions defined here.

View File

@ -395,8 +395,8 @@ function, for instance by using shader math.
A slink:VkSurfaceKHR owns the binding of the native window to the Vulkan
driver.
26) How can the client control the way the alpha channel of swap chain
images is treated by the presentation engine during compositing?
26) How can the client control the way the alpha channel of swapchain images
is treated by the presentation engine during compositing?
*RESOLVED*: We should add new enum values to allow the client to negotiate
with the presentation engine on how to treat image alpha values during the
@ -415,8 +415,8 @@ container holding the data that identifies a native window or other object
representing a surface on a particular platform.
For the surface factory functions to return this error, they would likely
need to register a reference on the native objects with the native display
server some how, and ensure no other such references exist.
Surfaces were not intended to be that heavy-weight.
server somehow, and ensure no other such references exist.
Surfaces were not intended to be that heavyweight.
Swapchains are intended to be the objects that directly manipulate native
windows and communicate with the native presentation mechanisms.
@ -583,7 +583,7 @@ https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/dem
- Added oldSwapchain member to VkSwapchainCreateInfoKHR.
* Revision 28, 2015-06-25 (James Jones)
- Added the "inherit" bits to the rotatation and mirroring flags and the
- Added the "inherit" bits to the rotation and mirroring flags and the
associated issue 21.
* Revision 29, 2015-06-25 (James Jones)
@ -601,7 +601,7 @@ https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/dem
"clipped".
- Example of using VkSurfacePropertiesKHR::{min|max}ImageCount to set
VkSwapchainCreateInfoKHR::minImageCount.
- Rename vkGetSurfaceInfoKHR()'s 4th param to "pDataSize", for
- Rename vkGetSurfaceInfoKHR()'s 4th parameter to "pDataSize", for
consistency with other functions.
- Add macro with C-string name of extension (just to header file).
@ -614,7 +614,7 @@ https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/dem
- Add usage flags to VkSwapchainCreateInfoKHR
* Revision 34, 2015-06-26 (Ian Elliott)
- Rename vkQueuePresentKHR()'s 2nd param to "pPresentInfo", for
- Rename vkQueuePresentKHR()'s 2nd parameter to "pPresentInfo", for
consistency with other functions.
* Revision 35, 2015-06-26 (Jason Ekstrand)

View File

@ -17,7 +17,7 @@ for command buffers.
When rendering a large number of objects, the device can be leveraged to
implement a number of critical functions, like updating matrices, or
implementing occlusion culling, frustum culling, front to back sorting...
implementing occlusion culling, frustum culling, front to back sorting, etc.
Implementing those on the device does not require any special extension,
since an application is free to define its own data structure, and just
process them using shaders.
@ -31,9 +31,9 @@ This extension allows an application to generate a device side stream of
state changes and commands, and convert it efficiently into a command buffer
without having to read it back on the host.
Furthermore, it allows incremental changes to such command buffers, by
manipulating only partial sections of a command stream, for example pipeline
bindings.
Furthermore, it allows incremental changes to such command buffers by
manipulating only partial sections of a command stream -- for example
pipeline bindings.
Unextended Vulkan requires re-creation of entire command buffers in such
scenario, or updates synchronized on the host.
@ -73,8 +73,8 @@ offsets whenever possible.
While the GPU can be faster than a CPU to generate the commands, it may not
happen asynchronously, therefore the primary use-case is generating "`less`"
total work (occlusion culling, classification to use specialized
shaders...).
total work (occlusion culling, classification to use specialized shaders,
etc.).
=== New Object Types
@ -148,22 +148,25 @@ Extending elink:VkAccessFlagBits:
*RESOLVED*: +VK_NVX_device_generated_commands+
As usual one of the hardest issues ;)
As usual, one of the hardest issues ;)
VK_gpu_commands VK_execute_commands VK_device_commands
VK_device_execute_commands VK_device_execute VK_device_created_commands
VK_device_recorded_commands VK_device_generated_commands
Alternatives:
`VK_gpu_commands`, `VK_execute_commands`, `VK_device_commands`,
`VK_device_execute_commands`, `VK_device_execute`,
`VK_device_created_commands`, `VK_device_recorded_commands`,
`VK_device_generated_commands`
2) Should we use serial tokens or redundant sequence description?
Similar to slink:VkPipeline, signatures have the most likeliness to be
Similarly to slink:VkPipeline, signatures have the most likelihood to be
cross-vendor adoptable.
They also benefit from being processable in parallel.
3) How to name sequence description
stext:ExecuteCommandSignature a bit long, just stext:ExecuteSignature or
actually more Vulkan nomenclature slink:VkIndirectCommandsLayoutNVX.
stext:ExecuteCommandSignature is a bit long. Maybe just
stext:ExecuteSignature, or actually more following Vulkan nomenclature:
slink:VkIndirectCommandsLayoutNVX.
4) Do we want to provide code:indirectCommands inputs with layout or at
code:indirectCommands time?
@ -173,8 +176,8 @@ Provide full flexibilty for code:indirectCommands.
5) Should the input be provided as SoA or AoS?
It is desired by application to reuse the list of objects and render them
with some kind override.
It is desirable for the application to reuse the list of objects and render
them with some kind of an override.
This can be done by just selecting a different input for a push constant or
a descriptor set, if they are defined as independent arrays.
If the data was interleaved, this would not be as easily possible.
@ -256,7 +259,7 @@ Considered legal, as long as the maximum dynamic count of all used
DescriptorSetLayouts is provided.
15) Should we add "`strides`" to input arrays, so that "`Array of
Structures`" type setups can be support more easily?
Structures`" type setups can be supported more easily?
Maybe provide a usage flag for packed tokens stream (all inputs from same
buffer, implicit stride).

View File

@ -26,7 +26,7 @@ function of [eq]#x# and [eq]#y# coordinates as follows:
[eq]#w' = w + Ax + By#
In the intended use case for viewport position scaling, an application
should use a set of 4 viewports, one for each of the 4 quadrants of a
should use a set of four viewports, one for each of the four quadrants of a
Cartesian coordinate system.
Each viewport is set to the dimension of the image, but is scissored to the
quadrant it represents.

View File

@ -63,7 +63,7 @@ Separate instances of the same Vulkan driver running on the same GPU should
have identical internal layout semantics, so applictions have the tools they
need to ensure views of images are consistent between the two instances.
Other APIs will fall into two categories: Those that are Vulkan compatible
(A term to be defined by subsequent interopability extensions), or Vulkan
(a term to be defined by subsequent interopability extensions), or Vulkan
incompatible.
When sharing images with Vulkan incompatible APIs, the Vulkan image must be
transitioned to the ename:VK_IMAGE_LAYOUT_GENERAL layout before handing it

View File

@ -47,7 +47,7 @@ that have far more limited capabilities than the very generic Vulkan memory
objects.
Not all memory handle types can name memory objects that support 3D images,
for example.
Some handle types can not even support the deferred image and memory binding
Some handle types cannot even support the deferred image and memory binding
behavior of Vulkan and require specifying the image when allocating or
importing the memory object.

View File

@ -63,7 +63,7 @@ Separate instances of the same Vulkan driver running on the same GPU should
have identical internal layout semantics, so applictions have the tools they
need to ensure views of images are consistent between the two instances.
Other APIs will fall into two categories: Those that are Vulkan compatible
(A term to be defined by subsequent interopability extensions), or Vulkan
(a term to be defined by subsequent interopability extensions), or Vulkan
incompatible.
When sharing images with Vulkan incompatible APIs, the Vulkan image must be
transitioned to the ename:VK_IMAGE_LAYOUT_GENERAL layout before handing it

View File

@ -83,7 +83,7 @@ count in the SPIR-V?
*RESOLVED*: Yes they should be required in the SPIR-V.
Per GL_NV_geometry_shader_passthrough they are not permitted in the GLSL
source shader, but SPIR-V is lower-level.
It is straight forward for the GLSL compiler to infer them from the input
It is straightforward for the GLSL compiler to infer them from the input
primitive type and to explicitly emit them in the SPIR-V according to the
following table.
@ -105,7 +105,7 @@ In Vulkan all SPIR-V shader inputs (except built-ins) must also have
location decorations specified.
Redeclarations of built-in varables that add the passthrough layout
qualifier are exempted from the rule requiring location assignment because
built-in variables are do not have locations and are matched by code:BuiltIn
built-in variables do not have locations and are matched by code:BuiltIn
decoration.

View File

@ -10,7 +10,7 @@ include::meta/VK_NV_glsl_shader.txt[]
This extension allows GLSL shaders written to the +GL_KHR_vulkan_glsl+
extension specification to be used instead of SPIR-V.
The implementation will automatically detect whether the shader is SPIR-V or
GLSL and compile it appropriatly.
GLSL, and compile it appropriately.
=== New Object Types

View File

@ -159,13 +159,13 @@ void main()
---------------------------------------------------
The application code is set up so that each of the six cube faces has a
separate viewport (numbered 0..5).
separate viewport (numbered 0 to 5).
Each face also has a separate swizzle, programmed via the
slink:VkPipelineViewportSwizzleStateCreateInfoNV pipeline state.
The viewport swizzle feature performs the coordinate transformation handled
by the code:rotate() function in the original shader.
The code:viewport_relative layout qualifier says that the viewport number
(0..5) is added to the base code:gl_Layer value of 0 to determine which
(0 to 5) is added to the base code:gl_Layer value of 0 to determine which
layer (cube face) the primitive should be sent to.
Note that the use of the passed through input code:normal in this example

View File

@ -991,7 +991,7 @@ Retired Swapchain::
Sampled Image::
A descriptor type that represents an image view, and supports filtered
(sampled) and unfiltered read-only acccess in a shader.
(sampled) and unfiltered read-only access in a shader.
Sampler::
An object that contains state that controls how sampled image data is

View File

@ -684,7 +684,7 @@ Other transfer functions, such as SMPTE 170M or SMPTE2084, must: not be
performed by the implementation, but can: be performed by the application
shader.
This extension defines enums for elink:VkColorSpaceKHR that correspond to
the following color spaces::
the following color spaces:
[[VK_EXT_swapchain_colorspace-table]]
.Color Spaces and Attributes

View File

@ -200,13 +200,13 @@ effects that require them to run for all pixels in the presentable image.
also allows the application to still present any images that are already
acquired from it.
Upon calling fname:vkCreateSwapchainKHR with a pname:oldSwapchain that is
Upon calling fname:vkCreateSwapchainKHR with an pname:oldSwapchain that is
not dlink:VK_NULL_HANDLE, pname:oldSwapchain is retired -- even if creation
of the new swapchain fails.
The new swapchain is created in the non-retired state whether or not
pname:oldSwapchain is dlink:VK_NULL_HANDLE.
Upon calling fname:vkCreateSwapchainKHR with a pname:oldSwapchain that is
Upon calling fname:vkCreateSwapchainKHR with an pname:oldSwapchain that is
not dlink:VK_NULL_HANDLE, any images from pname:oldSwapchain that are not
acquired by the application may: be freed by the implementation, which may:
occur even if creation of the new swapchain fails.
@ -439,7 +439,7 @@ destroyed.
If pname:oldSwapchain is not dlink:VK_NULL_HANDLE then pname:surface must:
be associated with pname:oldSwapchain.
Otherwise, the native window referred to by pname:surface must: not already
be associated with another swapchain, and must: not be already be associated
be associated with another swapchain, and must: not already be associated
with a non-Vulkan graphics API surface.
The native window referred to by pname:surface must: not become associated
with a non-Vulkan graphics API surface before the swapchain has been

View File

@ -1063,7 +1063,7 @@ destination image.
****
ifndef::VK_KHR_sampler_ycbcr_conversion[]
* [[VUID-VkBufferImageCopy-bufferOffset-00193]]
If the the calling command's sname:VkImage parameter's format is not a
If the calling command's sname:VkImage parameter's format is not a
depth/stencil format, then pname:bufferOffset must: be a multiple of the
format's element size
endif::VK_KHR_sampler_ycbcr_conversion[]
@ -1072,7 +1072,7 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[]
If the calling command's sname:VkImage parameter's format is not a
depth/stencil format or a
<<features-formats-requiring-sampler-ycbcr-conversion,multi-planar
format>>,cthen pname:bufferOffset must: be a multiple of the format's
format>>, then pname:bufferOffset must: be a multiple of the format's
element size
* [[VUID-VkBufferImageCopy-bufferOffset-01559]]
If the calling command's sname:VkImage parameter's format is a

View File

@ -2719,7 +2719,7 @@ If the descriptor type is ename:VK_DESCRIPTOR_TYPE_SAMPLER, the
pname:pImageInfo parameter is ignored and the immutable sampler is taken
from the push descriptor set layout in the pipeline layout.
If the descriptor type is ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
the pname:sampler member of the the pname:pImageInfo parameter is ignored
the pname:sampler member of the pname:pImageInfo parameter is ignored
and the immutable sampler is taken from the push descriptor set layout in
the pipeline layout.

View File

@ -364,8 +364,8 @@ Each extension which has such dependencies documents them in the
.Note
==================
The Specification does not currently include required extensions in Valid
Usage statements for individual commands and structures, although we may do
so in the future.
Usage statements for individual commands and structures, although it might
do so in the future.
Nonetheless, applications must: not use any extension functionality if
dependencies of that extension are not enabled.
==================

View File

@ -895,7 +895,7 @@ structure describe the following features:
order>>.
If this is ename:VK_TRUE,
ename:VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is treated the
same as ename:VK_ACCESS_COLOR_ATTACHMENT_READ_BIT and advanced blending
same as ename:VK_ACCESS_COLOR_ATTACHMENT_READ_BIT, and advanced blending
needs no additional synchronization over basic blending.
If this is ename:VK_FALSE, then memory dependencies are required to
guarantee order between two advanced blending operations that occur on

View File

@ -450,7 +450,7 @@ Shared library implementations must: use the default Application Binary
Interface (ABI) of the standard C compiler for the platform, or provide
customized API headers that cause application code to use the
implementation's non-default ABI.
An ABI in this context means the the size, alignment, and layout of C data
An ABI in this context means the size, alignment, and layout of C data
types; the procedure calling convention; and the naming convention for
shared library symbols corresponding to C functions.
Customizing the calling convention for a platform is usually accomplished by

View File

@ -605,7 +605,7 @@ endif::VK_KHR_maintenance2[]
ifdef::VK_KHR_maintenance2[]
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-01756]]
If rasterization is not disabled and pname:subpass uses a depth/stencil
attachment in pname:renderpass that has a layout of
attachment in pname:renderPass that has a layout of
ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL
// ifdef::VK_KHR_maintenance2[]
or ename:VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR
@ -615,7 +615,7 @@ ifdef::VK_KHR_maintenance2[]
ename:VK_FALSE
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-01757]]
If rasterization is not disabled and pname:subpass uses a depth/stencil
attachment in pname:renderpass that has a layout of
attachment in pname:renderPass that has a layout of
ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL
// ifdef::VK_KHR_maintenance2[]
or ename:VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR

View File

@ -1184,7 +1184,7 @@ As subpasses may: overlap or execute out of order with regards to other
subpasses unless a subpass dependency chain describes otherwise, the layout
transitions required between subpasses cannot: be known to an application.
Instead, an application provides the layout that each attachment must: be in
at the start and end of a renderpass, and the layout it must: be in during
at the start and end of a render pass, and the layout it must: be in during
each subpass it is used in.
The implementation then must: execute layout transitions between subpasses
in order to guarantee that the images are in the layouts required by each

View File

@ -553,7 +553,7 @@ include::../api/enums/VkAccessFlagBits.txt[]
* ename:VK_ACCESS_UNIFORM_READ_BIT specifies read access to a
<<descriptorsets-uniformbuffer, uniform buffer>>.
* ename:VK_ACCESS_INPUT_ATTACHMENT_READ_BIT specifies read access to an
<<renderpass, input attachment>> within a renderpass during fragment
<<renderpass, input attachment>> within a render pass during fragment
shading.
* ename:VK_ACCESS_SHADER_READ_BIT specifies read access to a
<<descriptorsets-storagebuffer, storage buffer>>,
@ -887,13 +887,13 @@ This order is determined as follows:
. The order in which commands were recorded to a command buffer on the
host, from first to last:
** For commands recorded outside a render pass, this includes all other
commands recorded outside a renderpass, including
commands recorded outside a render pass, including
flink:vkCmdBeginRenderPass and flink:vkCmdEndRenderPass commands; it
does not directly include commands inside a render pass.
** For commands recorded inside a render pass, this includes all other
commands recorded inside the same subpass, including the
flink:vkCmdBeginRenderPass and flink:vkCmdEndRenderPass commands that
delimit the same renderpass instance; it does not include commands
delimit the same render pass instance; it does not include commands
recorded to other subpasses.
<<fundamentals-queueoperation-command-types, Action and synchronization

View File

@ -12,7 +12,7 @@ ifdef::VK_NV_viewport_swizzle[]
* Viewport swizzle (see <<vertexpostproc-viewport-swizzle,Viewport
Swizzle>>)
endif::VK_NV_viewport_swizzle[]
* Flatshading (see <<vertexpostproc-flatshading,Flatshading>>).
* Flat shading (see <<vertexpostproc-flatshading>>).
* Primitive clipping, including client-defined half-spaces (see
<<vertexpostproc-clipping,Primitive Clipping>>).
* Shader output attribute clipping (see

View File

@ -11,7 +11,7 @@
<ul>
<li> The <a href="1.0/styleguide.html">Vulkan API and Documentation
Style Guide</a> defines mandatory and recommended practices
for writing and modigying Specifications, extensions,
for writing and modifying Specifications, extensions,
and reference page language. </li>
<li> The <a href="1.0/registry.html">Vulkan API Registry</a> document
describes the XML schema used in <tt>vk.xml</tt> in considerable