Fix some quotes and apostrophes
This commit is contained in:
Petr Kraus
parent
2f5bc66d7a
commit
0920ab5e7c
|
|
@ -6,9 +6,9 @@ include::meta/VK_EXT_discard_rectangles.txt[]
|
|||
- Daniel Koch, NVIDIA
|
||||
- Jeff Bolz, NVIDIA
|
||||
|
||||
This extension provides additional orthogonally aligned "discard rectangles"
|
||||
specified in framebuffer-space coordinates that restrict rasterization of
|
||||
all points, lines and triangles.
|
||||
This extension provides additional orthogonally aligned "`discard
|
||||
rectangles`" specified in framebuffer-space coordinates that restrict
|
||||
rasterization of all points, lines and triangles.
|
||||
|
||||
From zero to an implementation-dependent limit (specified by
|
||||
pname:maxDiscardRectangles) number of discard rectangles can be operational
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ This extension defines a set of utility functions for use with the
|
|||
|
||||
=== Issues
|
||||
|
||||
1) Should this extension add an explicit "WaitForVsync" API or a fence
|
||||
1) Should this extension add an explicit "`WaitForVsync`" API or a fence
|
||||
signaled at vsync that the application can wait on?
|
||||
|
||||
*RESOLVED*: A fence.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,8 @@ include::meta/VK_EXT_swapchain_colorspace.txt[]
|
|||
space and applies a linear OETF.
|
||||
** ename:VK_COLOR_SPACE_ADOBERGB_NONLINEAR_EXT - supports the AdobeRGB
|
||||
color space and applies the Gamma 2.2 OETF.
|
||||
** ename:VK_COLOR_SPACE_PASS_THROUGH_EXT - color components used "as is".
|
||||
** ename:VK_COLOR_SPACE_PASS_THROUGH_EXT - color components used "`as
|
||||
is`".
|
||||
Intended to allow application to supply data for color spaces not
|
||||
described here.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ flink:vkBindImageMemory that allow multiple bindings to be performed at
|
|||
once, and are extensible.
|
||||
|
||||
This extension also introduces ename:VK_IMAGE_CREATE_ALIAS_BIT_KHR, which
|
||||
allows "identical" images that alias the same memory to interpret the
|
||||
allows "`identical`" images that alias the same memory to interpret the
|
||||
contents consistently, even across image layout changes.
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -296,7 +296,7 @@ Since etext:MIRROR_NONE must be a bit in the bitmask rather than a bitmask
|
|||
with no values set, allowing more than one bit to be set in the bitmask
|
||||
would make it possible to describe undefined transforms such as
|
||||
etext:VK_MIRROR_NONE_BIT | etext:VK_MIRROR_HORIZONTAL_BIT, or a transform
|
||||
that includes both "`no mirroring`" and "`horizontal mirroring
|
||||
that includes both "`no mirroring`" and "`horizontal mirroring`"
|
||||
simultaneously.
|
||||
Therefore, it is desirable to allow specifying all supported mirroring
|
||||
transforms using only one bit.
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ include::meta/VK_NV_clip_space_w_scaling.txt[]
|
|||
- Kedarnath Thangudu, NVIDIA
|
||||
|
||||
Virtual Reality (VR) applications often involve a post-processing step to
|
||||
apply a "barrel" distortion to the rendered image to correct the
|
||||
"pincushion" distortion introduced by the optics in a VR device.
|
||||
apply a "`barrel`" distortion to the rendered image to correct the
|
||||
"`pincushion`" distortion introduced by the optics in a VR device.
|
||||
The barrel distorted image has lower resolution along the edges compared to
|
||||
the center.
|
||||
Since the original image is rendered at high resolution, which is uniform
|
||||
|
|
|
|||
|
|
@ -8,10 +8,10 @@ include::meta/VK_NV_framebuffer_mixed_samples.txt[]
|
|||
This extension allows multisample rendering with a raster and depth/stencil
|
||||
sample count that is larger than the color sample count.
|
||||
Rasterization and the results of the depth and stencil tests together
|
||||
determine the portion of a pixel that is "covered".
|
||||
determine the portion of a pixel that is "`covered`".
|
||||
It can be useful to evaluate coverage at a higher frequency than color
|
||||
samples are stored.
|
||||
This coverage is then "reduced" to a collection of covered color samples,
|
||||
This coverage is then "`reduced`" to a collection of covered color samples,
|
||||
each having an opacity value corresponding to the fraction of the color
|
||||
sample covered.
|
||||
The opacity can optionally be blended into individual color samples.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ This extension adds support for the following SPIR-V extension in Vulkan:
|
|||
|
||||
Geometry shaders provide the ability for applications to process each
|
||||
primitive sent through the graphics pipeline using a programmable shader.
|
||||
However, one common use case treats them largely as a "passthrough".
|
||||
However, one common use case treats them largely as a "`passthrough`".
|
||||
In this use case, the bulk of the geometry shader code simply copies inputs
|
||||
from each vertex of the input primitive to corresponding outputs in the
|
||||
vertices of the output primitive.
|
||||
|
|
@ -144,7 +144,7 @@ void main()
|
|||
In this shader, the inputs code:gl_Position, code:Inputs.texcoord, and
|
||||
code:Inputs.baseColor are simply copied from the input vertex to the
|
||||
corresponding output vertex.
|
||||
The only "interesting" work done by the geometry shader is computing and
|
||||
The only "`interesting`" work done by the geometry shader is computing and
|
||||
emitting a code:gl_Layer value for the primitive.
|
||||
|
||||
The following geometry shader, using this extension, is equivalent:
|
||||
|
|
|
|||
|
|
@ -20,11 +20,10 @@ single-pass cubemap rendering (broadcasting a primitive to multiple faces
|
|||
and reorienting the vertex position for each face) and voxel rasterization.
|
||||
The per-viewport component remapping and negation provided by the swizzle
|
||||
allows application code to re-orient three-dimensional geometry with a view
|
||||
the "Issues" section below.
|
||||
along any of the *X*, *Y*, or *Z* axes.
|
||||
If a perspective projection and depth buffering is required, [eq]#1/W#
|
||||
buffering should be used, as described in the single-pass cubemap rendering
|
||||
example in
|
||||
example in the "`Issues`" section below.
|
||||
|
||||
|
||||
=== New Object Types
|
||||
|
|
|
|||
|
|
@ -328,7 +328,7 @@ This macro controls calling conventions for MSVC-style compilers.
|
|||
|
||||
// @refBegin VKAPI_PTR Vulkan function pointer calling conventions
|
||||
|
||||
dname:VKAPI_PTR is a macro placed between the '(' and '*' in Vulkan API
|
||||
dname:VKAPI_PTR is a macro placed between the "`(`" and "`*`" in Vulkan API
|
||||
function pointer declarations.
|
||||
This macro also controls calling conventions, and typically has the same
|
||||
definition as dname:VKAPI_ATTR or dname:VKAPI_CALL, depending on the
|
||||
|
|
|
|||
|
|
@ -376,9 +376,9 @@ Executable State (Command Buffer)::
|
|||
See also Initial State and Recording State.
|
||||
|
||||
Execution Dependency::
|
||||
A dependency that guarantees that certain pipeline stages' work for a
|
||||
A dependency that guarantees that certain pipeline stages`' work for a
|
||||
first set of commands has completed execution before certain pipeline
|
||||
stages' work for a second set of commands begins execution.
|
||||
stages`' work for a second set of commands begins execution.
|
||||
This is accomplished via pipeline barriers, subpass dependencies,
|
||||
events, or implicit ordering operations.
|
||||
|
||||
|
|
@ -464,9 +464,9 @@ Framebuffer Attachment::
|
|||
One of the image views used in a framebuffer.
|
||||
|
||||
Framebuffer Coordinates::
|
||||
A coordinate system in which adjacent pixels' coordinates differ by 1 in
|
||||
x and/or y, with [eq]#(0,0)# in the upper left corner and pixel centers
|
||||
at half-integers.
|
||||
A coordinate system in which adjacent pixels`' coordinates differ by 1
|
||||
in x and/or y, with [eq]#(0,0)# in the upper left corner and pixel
|
||||
centers at half-integers.
|
||||
|
||||
Framebuffer-Space::
|
||||
Operating with respect to framebuffer coordinates.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ include::../validity/protos/vkSetHdrMetadataEXT.txt[]
|
|||
--
|
||||
include::../api/structs/VkXYColorEXT.txt[]
|
||||
Chromaticity coordinates x and y are as specified in CIE 15:2004
|
||||
"Calculation of chromaticity coordinates" (Section 7.3) and are limited to
|
||||
"`Calculation of chromaticity coordinates`" (Section 7.3) and are limited to
|
||||
between 0 and 1 for real colors for the mastering display.
|
||||
|
||||
--
|
||||
|
|
|
|||
|
|
@ -346,8 +346,8 @@ include::../../validity/structs/VkDisplayModeCreateInfoKHR.txt[]
|
|||
--
|
||||
|
||||
Applications that wish to present directly to a display must: select which
|
||||
layer, or "plane" of the display they wish to target, and a mode to use with
|
||||
the display.
|
||||
layer, or "`plane`" of the display they wish to target, and a mode to use
|
||||
with the display.
|
||||
Each display supports at least one plane.
|
||||
The capabilities of a given mode and plane combination are determined by
|
||||
calling:
|
||||
|
|
@ -407,7 +407,7 @@ possible positions and sizes may: be used to specify the region within the
|
|||
presentable images that source pixels will be read from when creating a
|
||||
swapchain on the specified display mode and plane.
|
||||
|
||||
Vendors may: also support mapping the presentable images' content to a
|
||||
Vendors may: also support mapping the presentable images`' content to a
|
||||
subset or superset of the visible region in the specified display mode.
|
||||
This is expressed by returning pname:minDstPosition, pname:maxDstPosition,
|
||||
pname:minDstExtent and pname:maxDstExtent values that indicate a range of
|
||||
|
|
|
|||
|
|
@ -247,7 +247,7 @@ accumulate.
|
|||
|
||||
In this situation, trimming a command pool may: be useful to return unused
|
||||
memory back to the system, returning the total outstanding memory allocated
|
||||
by the pool back to a more "average" value.
|
||||
by the pool back to a more "`average`" value.
|
||||
|
||||
Implementations utilize many internal allocation strategies that make it
|
||||
impossible to guarantee that all unused memory is released back to the
|
||||
|
|
@ -259,13 +259,13 @@ a bulk allocation would prevent that allocation from being freed, even if
|
|||
only a small proportion of the bulk allocation is in use.
|
||||
|
||||
In most cases trimming will result in a reduction in allocated but unused
|
||||
memory, but it does not guarantee the "ideal" behaviour.
|
||||
memory, but it does not guarantee the "`ideal`" behaviour.
|
||||
|
||||
Trimming may: be an expensive operation, and should: not be called
|
||||
frequently.
|
||||
Trimming should: be treated as a way to relieve memory pressure after
|
||||
application-known points when there exists enough unused memory that the
|
||||
cost of trimming is "worth" it.
|
||||
cost of trimming is "`worth`" it.
|
||||
====
|
||||
|
||||
include::../validity/protos/vkTrimCommandPoolKHR.txt[]
|
||||
|
|
|
|||
|
|
@ -48,8 +48,8 @@ This is generally discouraged, as it increases the probability of
|
|||
incompatibilities with new extensions.
|
||||
The validation layers wrap handles in order to track the proper use and
|
||||
destruction of each object.
|
||||
See the <<LoaderAndValidationLayers, "Vulkan Loader Specification and
|
||||
Architecture Overview">> document for additional information.
|
||||
See the <<LoaderAndValidationLayers, "`Vulkan Loader Specification and
|
||||
Architecture Overview`">> document for additional information.
|
||||
|
||||
[open,refpage='vkEnumerateInstanceLayerProperties',desc='Returns up to requested number of global layer properties',type='protos']
|
||||
--
|
||||
|
|
@ -215,8 +215,8 @@ extension authors should: add support for their extensions to the Khronos
|
|||
validation layers.
|
||||
This is especially important for new commands whose parameters have been
|
||||
wrapped by the validation layers.
|
||||
See the <<LoaderAndValidationLayers, "Vulkan Loader Specification and
|
||||
Architecture Overview">> document for additional information.
|
||||
See the <<LoaderAndValidationLayers, "`Vulkan Loader Specification and
|
||||
Architecture Overview`">> document for additional information.
|
||||
|
||||
[open,refpage='vkEnumerateInstanceExtensionProperties',desc='Returns up to requested number of global extension properties',type='protos']
|
||||
--
|
||||
|
|
|
|||
|
|
@ -458,8 +458,8 @@ defining <<boilerplate-platform-specific-calling-conventions,calling
|
|||
convention macros>> appropriately in +vk_platform.h+.
|
||||
|
||||
On platforms where Vulkan is provided as a shared library, library symbols
|
||||
beginning with 'vk' and followed by a digit or uppercase letter are reserved
|
||||
for use by the implementation.
|
||||
beginning with "`vk`" and followed by a digit or uppercase letter are
|
||||
reserved for use by the implementation.
|
||||
Applications which use Vulkan must: not provide definitions of these
|
||||
symbols.
|
||||
This allows the Vulkan shared library to be updated with additional symbols
|
||||
|
|
@ -1108,9 +1108,9 @@ Hopefully it can: be tightened up considerably.
|
|||
====
|
||||
endif::editing-notes[]
|
||||
|
||||
We require simply that numbers' floating-point parts contain enough bits and
|
||||
that their exponent fields are large enough so that individual results of
|
||||
floating-point operations are accurate to about 1 part in 10^5^.
|
||||
We require simply that numbers`' floating-point parts contain enough bits
|
||||
and that their exponent fields are large enough so that individual results
|
||||
of floating-point operations are accurate to about 1 part in 10^5^.
|
||||
The maximum representable magnitude for all floating-point values must: be
|
||||
at least 2^32^.
|
||||
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ as described <<fxvertex-input-extraction,below>>.
|
|||
| four-component vector | 0 or unspecified | (x, y, z, w)
|
||||
|====
|
||||
|
||||
Components indicated by `o' are available for use by other input variables
|
||||
Components indicated by "`o`" are available for use by other input variables
|
||||
which are sourced from the same attribute, and if used, are either filled
|
||||
with the corresponding component from the input format (if present), or the
|
||||
default value.
|
||||
|
|
@ -165,7 +165,7 @@ The code:Component decoration must: not be used with matrix types.
|
|||
| mat4 | four-component vector | i, i+1, i+2, i+3 | (x, y, z, w), (x, y, z, w), (x, y, z, w), (x, y, z, w)
|
||||
|====
|
||||
|
||||
Components indicated by `o' are available for use by other input variables
|
||||
Components indicated by "`o`" are available for use by other input variables
|
||||
which are sourced from the same attribute, and if used, are either filled
|
||||
with the corresponding component from the input (if present), or the default
|
||||
value.
|
||||
|
|
@ -226,9 +226,9 @@ component of 1 or 3.
|
|||
| four-component vector | i | unspecified | (x, y, z, w), (x, y, z, w)
|
||||
|====
|
||||
|
||||
Components indicated by `o' are available for use by other input variables
|
||||
Components indicated by "`o`" are available for use by other input variables
|
||||
which are sourced from the same attribute.
|
||||
Components indicated by `-' are not available for input variables as there
|
||||
Components indicated by "`-`" are not available for input variables as there
|
||||
are no default values provided for 64-bit data types, and there is no data
|
||||
provided by the input format.
|
||||
|
||||
|
|
|
|||
|
|
@ -33,8 +33,8 @@ commands as well; if this is done, then applications that use only the core
|
|||
Vulkan commands have no need to use fname:vkGetInstanceProcAddr.
|
||||
|
||||
The table below defines the various use cases for
|
||||
fname:vkGetInstanceProcAddr and expected return value ("fp" is function
|
||||
pointer) for each case.
|
||||
fname:vkGetInstanceProcAddr and expected return value ("`fp`" is "`function
|
||||
pointer`") for each case.
|
||||
|
||||
The returned function pointer is of type tlink:PFN_vkVoidFunction, and must
|
||||
be cast to the type of the command being queried.
|
||||
|
|
|
|||
|
|
@ -752,7 +752,7 @@ resources.
|
|||
[[interfaces-resources-layout-std140]]
|
||||
*Standard Uniform Buffer Layout*
|
||||
|
||||
The 'base alignment' of the type of an code:OpTypeStruct member of is
|
||||
The _base alignment_ of the type of an code:OpTypeStruct member of is
|
||||
defined recursively as follows:
|
||||
|
||||
* A scalar of size [eq]#N# has a base alignment of [eq]#N#.
|
||||
|
|
@ -771,7 +771,7 @@ defined recursively as follows:
|
|||
|
||||
ifdef::VK_KHR_relaxed_block_layout[]
|
||||
|
||||
A member is defined to 'improperly straddle' if either of the following are
|
||||
A member is defined to _improperly straddle_ if either of the following are
|
||||
true:
|
||||
|
||||
* It is a vector with total size less than or equal to 16 bytes, and has
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ Pages`" or "`Registry`", to help us triage and assign them appropriately.
|
|||
Unfortunately, GitHub does not currently let users who do not have write
|
||||
access to the repository set GitHub labels on issues.
|
||||
In the meantime, they can: be added to the title line of the issue set in
|
||||
brackets, e.g. ''[Specification]''.
|
||||
brackets, e.g. "`[Specification]`".
|
||||
|
||||
|
||||
[[introduction-terminology]]
|
||||
|
|
|
|||
|
|
@ -1113,9 +1113,9 @@ A view-global dependency between two multiview subpasses acts like a set of
|
|||
the source and destination.
|
||||
Thus, it is a more compact representation which also makes clear the
|
||||
commonality and reuse that is present between views in a subpass.
|
||||
This interpretation motivates the answers to questions like "when does the
|
||||
load op apply" - it is on the first use of each view of an attachment, as if
|
||||
each view were a separate attachment.
|
||||
This interpretation motivates the answers to questions like "`when does the
|
||||
load op apply`" - it is on the first use of each view of an attachment, as
|
||||
if each view were a separate attachment.
|
||||
====
|
||||
|
||||
endif::VK_KHX_multiview[]
|
||||
|
|
|
|||
|
|
@ -3812,7 +3812,7 @@ report a value of one.
|
|||
.Note
|
||||
====
|
||||
Despite its name, pname:bufferImageGranularity is really a granularity
|
||||
between "linear" and "non-linear" resources.
|
||||
between "`linear`" and "`non-linear`" resources.
|
||||
====
|
||||
|
||||
Given resourceA at the lower memory offset and resourceB at the higher
|
||||
|
|
|
|||
|
|
@ -629,7 +629,7 @@ slink:VkSamplerYcbcrConversionCreateInfoKHR::pname:components).
|
|||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
For example, an "YUVA" 32-bit format comprising four 8-bit channels can be
|
||||
For example, an "`YUVA`" 32-bit format comprising four 8-bit channels can be
|
||||
implemented as ename:VK_FORMAT_R8G8B8A8_UNORM with a component mapping:
|
||||
|
||||
* pname:components.a = ename:VK_COMPONENT_SWIZZLE_IDENTITY
|
||||
|
|
|
|||
|
|
@ -524,7 +524,7 @@ ifdef::implementation-guide[]
|
|||
|
||||
****
|
||||
This section is Informative.
|
||||
It is included to aid in implementors' understanding of sparse resources.
|
||||
It is included to aid in implementors`' understanding of sparse resources.
|
||||
|
||||
.Device Virtual Address
|
||||
|
||||
|
|
|
|||
|
|
@ -304,8 +304,8 @@ the boundary of the clip volume.
|
|||
This clipping produces a value, [eq]#0 {leq} t {leq} 1#, for each clipped
|
||||
vertex.
|
||||
If the coordinates of a clipped vertex are [eq]#**P**# and the original
|
||||
vertices' coordinates are [eq]#**P**~1~# and [eq]#**P**~2~#, then [eq]#t# is
|
||||
given by
|
||||
vertices`' coordinates are [eq]#**P**~1~# and [eq]#**P**~2~#, then [eq]#t#
|
||||
is given by
|
||||
|
||||
:: [eq]#**P** = t **P**~1~ {plus} (1-t) **P**~2~#.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue