Merge pull request #644 from krOoze/fix_random_typos
Fix random grammar
This commit is contained in:
Jon Leech
GitHub
commit
cfa7e506ab
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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?
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -160,13 +160,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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
==================
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue