From b5866906716048504583b1913284761f5b4679dc Mon Sep 17 00:00:00 2001 From: Petr Kraus Date: Fri, 15 Dec 2017 21:01:02 +0100 Subject: [PATCH] Fix random grammar --- .../appendices/VK_AMD_rasterization_order.txt | 2 +- .../VK_AMD_shader_fragment_mask.txt | 10 +++--- .../VK_AMD_texture_gather_bias_lod.txt | 4 +-- .../VK_EXT_blend_operation_advanced.txt | 2 +- .../vulkan/appendices/VK_EXT_debug_marker.txt | 2 +- .../vulkan/appendices/VK_EXT_debug_report.txt | 4 +-- .../appendices/VK_GOOGLE_display_timing.txt | 4 +-- .../vulkan/appendices/VK_KHR_display.txt | 4 +-- .../appendices/VK_KHR_external_memory.txt | 4 +-- .../VK_KHR_external_memory_capabilities.txt | 2 +- .../appendices/VK_KHR_push_descriptor.txt | 2 +- .../vulkan/appendices/VK_KHR_surface.txt | 4 +-- .../vulkan/appendices/VK_KHR_swapchain.txt | 14 ++++---- .../VK_NVX_device_generated_commands.txt | 35 ++++++++++--------- .../appendices/VK_NV_clip_space_w_scaling.txt | 2 +- .../appendices/VK_NV_external_memory.txt | 2 +- .../VK_NV_external_memory_capabilities.txt | 2 +- .../VK_NV_external_memory_win32.txt | 2 +- .../VK_NV_geometry_shader_passthrough.txt | 4 +-- .../vulkan/appendices/VK_NV_glsl_shader.txt | 2 +- .../appendices/VK_NV_viewport_swizzle.txt | 4 +-- doc/specs/vulkan/appendices/glossary.txt | 2 +- .../vulkan/chapters/VK_KHR_surface/wsi.txt | 2 +- .../vulkan/chapters/VK_KHR_swapchain/wsi.txt | 6 ++-- doc/specs/vulkan/chapters/copies.txt | 4 +-- doc/specs/vulkan/chapters/descriptorsets.txt | 2 +- doc/specs/vulkan/chapters/extensions.txt | 4 +-- doc/specs/vulkan/chapters/features.txt | 2 +- doc/specs/vulkan/chapters/fundamentals.txt | 2 +- doc/specs/vulkan/chapters/pipelines.txt | 4 +-- doc/specs/vulkan/chapters/renderpass.txt | 2 +- doc/specs/vulkan/chapters/synchronization.txt | 6 ++-- doc/specs/vulkan/chapters/vertexpostproc.txt | 2 +- out/index.html | 2 +- 34 files changed, 77 insertions(+), 74 deletions(-) diff --git a/doc/specs/vulkan/appendices/VK_AMD_rasterization_order.txt b/doc/specs/vulkan/appendices/VK_AMD_rasterization_order.txt index 20781562..5abf3d69 100644 --- a/doc/specs/vulkan/appendices/VK_AMD_rasterization_order.txt +++ b/doc/specs/vulkan/appendices/VK_AMD_rasterization_order.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt b/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt index 6c5205af..def7e29a 100644 --- a/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt +++ b/doc/specs/vulkan/appendices/VK_AMD_shader_fragment_mask.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_AMD_texture_gather_bias_lod.txt b/doc/specs/vulkan/appendices/VK_AMD_texture_gather_bias_lod.txt index f6ef20b3..235e631a 100644 --- a/doc/specs/vulkan/appendices/VK_AMD_texture_gather_bias_lod.txt +++ b/doc/specs/vulkan/appendices/VK_AMD_texture_gather_bias_lod.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt b/doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt index 52441527..6b315c34 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt b/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt index b2a4054b..351a10c9 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_debug_marker.txt @@ -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? diff --git a/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt b/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt index b81eb6d0..3b0722d1 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_debug_report.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_GOOGLE_display_timing.txt b/doc/specs/vulkan/appendices/VK_GOOGLE_display_timing.txt index 701eb107..76ebf965 100644 --- a/doc/specs/vulkan/appendices/VK_GOOGLE_display_timing.txt +++ b/doc/specs/vulkan/appendices/VK_GOOGLE_display_timing.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_display.txt b/doc/specs/vulkan/appendices/VK_KHR_display.txt index e8503929..c3e6b514 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_display.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_display.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt b/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt index 6c2d80e0..e784fcee 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_external_memory.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_external_memory_capabilities.txt b/doc/specs/vulkan/appendices/VK_KHR_external_memory_capabilities.txt index 76c5e065..2fd2200d 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_external_memory_capabilities.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_external_memory_capabilities.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_push_descriptor.txt b/doc/specs/vulkan/appendices/VK_KHR_push_descriptor.txt index 2c3a21f0..576c45d2 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_push_descriptor.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_push_descriptor.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_surface.txt b/doc/specs/vulkan/appendices/VK_KHR_surface.txt index 45647cff..b6764639 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_surface.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_surface.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt b/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt index 69e852a6..f55a4b0f 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt @@ -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) diff --git a/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt b/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt index f1c20fa9..24ec32f1 100644 --- a/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt +++ b/doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt @@ -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). diff --git a/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt b/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt index 416d2404..ee27f557 100644 --- a/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt +++ b/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_NV_external_memory.txt b/doc/specs/vulkan/appendices/VK_NV_external_memory.txt index cf98efba..b21b6771 100644 --- a/doc/specs/vulkan/appendices/VK_NV_external_memory.txt +++ b/doc/specs/vulkan/appendices/VK_NV_external_memory.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_NV_external_memory_capabilities.txt b/doc/specs/vulkan/appendices/VK_NV_external_memory_capabilities.txt index 2096fd82..1a963fbb 100644 --- a/doc/specs/vulkan/appendices/VK_NV_external_memory_capabilities.txt +++ b/doc/specs/vulkan/appendices/VK_NV_external_memory_capabilities.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt b/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt index d00fb85a..84397ef8 100644 --- a/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt +++ b/doc/specs/vulkan/appendices/VK_NV_external_memory_win32.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt b/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt index 74ecfb17..583a61c3 100644 --- a/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt +++ b/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt @@ -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. diff --git a/doc/specs/vulkan/appendices/VK_NV_glsl_shader.txt b/doc/specs/vulkan/appendices/VK_NV_glsl_shader.txt index 24d931da..747fc82d 100644 --- a/doc/specs/vulkan/appendices/VK_NV_glsl_shader.txt +++ b/doc/specs/vulkan/appendices/VK_NV_glsl_shader.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt index 2b178aaf..7abaa69a 100644 --- a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt +++ b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt @@ -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 diff --git a/doc/specs/vulkan/appendices/glossary.txt b/doc/specs/vulkan/appendices/glossary.txt index dcbca6e6..4df07e0f 100644 --- a/doc/specs/vulkan/appendices/glossary.txt +++ b/doc/specs/vulkan/appendices/glossary.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt b/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt index 998be05a..52e6856d 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt b/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt index 0cccd0d2..f65bb4c5 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/copies.txt b/doc/specs/vulkan/chapters/copies.txt index 5c9e549a..526c8a6e 100644 --- a/doc/specs/vulkan/chapters/copies.txt +++ b/doc/specs/vulkan/chapters/copies.txt @@ -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 <>,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 diff --git a/doc/specs/vulkan/chapters/descriptorsets.txt b/doc/specs/vulkan/chapters/descriptorsets.txt index ed69ce12..3928e5cb 100644 --- a/doc/specs/vulkan/chapters/descriptorsets.txt +++ b/doc/specs/vulkan/chapters/descriptorsets.txt @@ -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. diff --git a/doc/specs/vulkan/chapters/extensions.txt b/doc/specs/vulkan/chapters/extensions.txt index 38277afc..6e477829 100644 --- a/doc/specs/vulkan/chapters/extensions.txt +++ b/doc/specs/vulkan/chapters/extensions.txt @@ -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. ================== diff --git a/doc/specs/vulkan/chapters/features.txt b/doc/specs/vulkan/chapters/features.txt index 6ecf576b..76ea2593 100644 --- a/doc/specs/vulkan/chapters/features.txt +++ b/doc/specs/vulkan/chapters/features.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/fundamentals.txt b/doc/specs/vulkan/chapters/fundamentals.txt index 90164f76..e7994b5e 100644 --- a/doc/specs/vulkan/chapters/fundamentals.txt +++ b/doc/specs/vulkan/chapters/fundamentals.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/pipelines.txt b/doc/specs/vulkan/chapters/pipelines.txt index 59acb27f..74914c4c 100644 --- a/doc/specs/vulkan/chapters/pipelines.txt +++ b/doc/specs/vulkan/chapters/pipelines.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/renderpass.txt b/doc/specs/vulkan/chapters/renderpass.txt index 2cdd3787..c81c17de 100644 --- a/doc/specs/vulkan/chapters/renderpass.txt +++ b/doc/specs/vulkan/chapters/renderpass.txt @@ -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 diff --git a/doc/specs/vulkan/chapters/synchronization.txt b/doc/specs/vulkan/chapters/synchronization.txt index fb9d3aee..427d3881 100644 --- a/doc/specs/vulkan/chapters/synchronization.txt +++ b/doc/specs/vulkan/chapters/synchronization.txt @@ -553,7 +553,7 @@ include::../api/enums/VkAccessFlagBits.txt[] * ename:VK_ACCESS_UNIFORM_READ_BIT specifies read access to a <>. * ename:VK_ACCESS_INPUT_ATTACHMENT_READ_BIT specifies read access to an - <> within a renderpass during fragment + <> within a render pass during fragment shading. * ename:VK_ACCESS_SHADER_READ_BIT specifies read access to a <>, @@ -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. <>) endif::VK_NV_viewport_swizzle[] - * Flatshading (see <>). + * Flat shading (see <>). * Primitive clipping, including client-defined half-spaces (see <>). * Shader output attribute clipping (see diff --git a/out/index.html b/out/index.html index 2670740d..a1678b5b 100644 --- a/out/index.html +++ b/out/index.html @@ -11,7 +11,7 @@
  • The Vulkan API and Documentation Style Guide defines mandatory and recommended practices - for writing and modigying Specifications, extensions, + for writing and modifying Specifications, extensions, and reference page language.
  • The Vulkan API Registry document describes the XML schema used in vk.xml in considerable