Fix random grammar

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.
 

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, the fragment mask can be fetched with a call to
-from a shader, which returns a single code:uint where each subsequent 4 bit
+code:fragmentMaskFetchAMD, which returns a single code:uint where each
-specifies the color fragment index corresponding to the color sample,
+subsequent four bits specify the color fragment index corresponding to the
-starting from the least significant bit.
+color sample, starting from the least significant bit.
-For example, when 8 color samples are used, the color fragment index for
+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.
 

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
+Secondly, the extension allows the application to query which formats can be
-be used together with the new function prototypes introduced by the SPIR-V
+used together with the new function prototypes introduced by the SPIR-V
 extension.
 
 === New Object Types

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

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?

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.
 

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
+This allows the application to avoid stuttering, so the animation looks
-no stuttering.
+smooth to the user.
 
 This extension treats variable-refresh-rate (VRR) displays as if they are
 fixed-refresh-rate (FRR) displays.

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
+19) Should persistent mode for smart panels be enabled/disabled at swapchain
-chain creation time, or on a per-present basis.
+creation time, or on a per-present basis.
 
 *RESOLVED*: On a per-present basis.
 

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.

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.
 

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.
 

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.

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
+26) How can the client control the way the alpha channel of swapchain images
-images is treated by the presentation engine during compositing?
+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.
+server somehow, and ensure no other such references exist.
-Surfaces were not intended to be that heavy-weight.
+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)

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
+Furthermore, it allows incremental changes to such command buffers by
-manipulating only partial sections of a command stream, for example pipeline
+manipulating only partial sections of a command stream -- for example
-bindings.
+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
+total work (occlusion culling, classification to use specialized shaders,
-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
+Alternatives:
-VK_device_execute_commands VK_device_execute VK_device_created_commands
+`VK_gpu_commands`, `VK_execute_commands`, `VK_device_commands`,
-VK_device_recorded_commands VK_device_generated_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
+stext:ExecuteCommandSignature is a bit long. Maybe just
-actually more Vulkan nomenclature slink:VkIndirectCommandsLayoutNVX.
+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
+It is desirable for the application to reuse the list of objects and render
-with some kind override.
+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).

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.

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

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.
 

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

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.
 
 

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
 

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

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

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

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

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
     <<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

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.
 

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
+Usage statements for individual commands and structures, although it might
-so in the future.
+do so in the future.
 Nonetheless, applications must: not use any extension functionality if
 dependencies of that extension are not enabled.
 ==================

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

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

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

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

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
     <<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

doc/specs/vulkan/chapters/vertexpostproc.txt

@@ -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

out/index.html

@@ -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