Merge pull request #845 from MrVallentin/typos

Fixed misspellings

COPYING.md

@@ -52,7 +52,7 @@ Q: Can I contribute changes to the Vulkan Specification?
 A: Yes, by opening a PR on the KhronosGroup/Vulkan-Docs Github project. You
 must execute a click-through Contributor License Agreement, which brings
 your changes under the umbrella of the Khronos IP policy. We welcome
-feedback and proposed changes, but will not neccessarily accept all such
+feedback and proposed changes, but will not necessarily accept all such
 changes. Please keep PRs focused on solving a single problem; more ambitious
 PRs that try to solve multiple problems, or touch many parts of the
 Specification at once, are difficult for the Vulkan Working Group to review
@@ -67,7 +67,7 @@ copyright on vk.xml, to make it more compatible with GPL-licensed software,
 such as externally-generated language bindings. This seems to have addressed
 the problems we're aware of. It is possible we could extend the Exception
 Clause to other Apache-licensed files in the project, or otherwise
-accomodate new needs of external projects; but working with the different
+accommodate new needs of external projects; but working with the different
 Khronos member company IP lawyers to make license changes is a very slow
 process, constrained by the Khronos Member Agreement and IP Policy as well
 as by individual company concerns about their IP. Do not expect rapid

ChangeLog.txt

@@ -4448,7 +4448,7 @@ Change log for February 25, 2015 Vulkan 1.0.4 spec update:
     <<samplers,Samplers>> chapter (internal issue 134).
   * Fix "Input Attachement" GLSL example to use correct syntax (internal
     issue 135).
-  * Update XML schema and documentation to accomodate recently added
+  * Update XML schema and documentation to accommodate recently added
     attributes for validity. Add some introductory material describing
     design choices and pointing to the public repository to file issues.
   * Put include of validity in the core spec extensions chapter on its

appendices/VK_EXT_hdr_metadata.txt

@@ -9,7 +9,7 @@ include::meta/VK_EXT_hdr_metadata.txt[]
 
 This extension defines two new structures and a function to assign SMPTE
 (the Society of Motion Picture and Television Engineers) 2086 metadata and
-CTA (Consumer Technology Assocation) 861.3 metadata to a swapchain.
+CTA (Consumer Technology Association) 861.3 metadata to a swapchain.
 The metadata includes the color primaries, white point, and luminance range
 of the mastering display, which all together define the color volume that
 contains all the possible colors the mastering display can produce.

appendices/VK_EXT_image_drm_format_modifier.txt

@@ -44,7 +44,7 @@ Some exceptions are etext:DRM_FORMAT_MOD_LINEAR (which is not
 vendor-specific); etext:DRM_FORMAT_MOD_NONE (which is an alias of
 etext:DRM_FORMAT_MOD_LINEAR due to historical accident); and
 etext:DRM_FORMAT_MOD_INVALID (which does not represent a tiling format).
-The _modifier's_ vendor prefix consists of the 8 most signficant bits.
+The _modifier's_ vendor prefix consists of the 8 most significant bits.
 The canonical list of _modifiers_ and vendor prefixes is found in
 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h[`drm_fourcc.h`]
 in the Linux kernel source.

appendices/VK_KHR_external_memory.txt

@@ -209,7 +209,7 @@ APIs.
 Earlier APIs implemented interop at a higher level, and this necessitated
 entirely separate sharing APIs for images and buffers.
 To co-exist and interoperate with those APIs, the Vulkan external sharing
-mechanism must accomodate their model.
+mechanism must accommodate their model.
 However, if it can be agreed that memory-based sharing is the more desirable
 and forward-looking design, legacy interoperation considerations can be
 considered another reason to favor memory-based sharing: While native and

appendices/VK_KHR_external_semaphore.txt

@@ -66,7 +66,7 @@ state if valid usage rules were violated.
 However, this could cause security concerns when using imported semaphores,
 as it would require the importing application to trust the exporting
 application to ensure the state is valid.
-Requiring this level of trust is undesireable for many potential use cases.
+Requiring this level of trust is undesirable for many potential use cases.
 
 2) Must implementations validate external handles the application provides
 as input to semaphore state import operations?

appendices/VK_KHR_shared_presentable_image.txt

@@ -101,7 +101,7 @@ ename:VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR.
 *RESOLVED*: After acquiring the shared presentable image, the application
 must transition it to the ename:VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout
 prior to it being used.
-After this intial transition, any image usage that was requested during
+After this initial transition, any image usage that was requested during
 swapchain creation can: be performed on the image without layout transitions
 being performed.
 

appendices/boilerplate.txt

@@ -97,7 +97,7 @@ With these macros, a Vulkan function declaration takes the form of:
 VKAPI_ATTR <return_type> VKAPI_CALL <command_name>(<command_parameters>);
 ----------------------------------------
 
-Additionaly, a Vulkan function pointer type declaration takes the form of:
+Additionally, a Vulkan function pointer type declaration takes the form of:
 
 [source,c++]
 ----------------------------------------

chapters/VK_KHR_surface/wsi.txt

@@ -258,7 +258,7 @@ endif::VK_NN_vi_surface[]
 
 == Surface Queries
 
-The capabilities of a swapchain targetting a surface are the intersection of
+The capabilities of a swapchain targeting a surface are the intersection of
 the capabilities of the WSI platform, the native window or display, and the
 physical device.
 The resulting capabilities can be obtained with the queries listed below in

chapters/features.txt

@@ -6443,7 +6443,7 @@ include::../api/structs/VkDrmFormatModifierPropertiesListEXT.txt[]
   * pname:sType is the type of this structure.
   * pname:pNext is `NULL` or a pointer to an extension-specific structure.
   * pname:drmFormatModifierCount is an inout parameter related to the number
-    of modifiers compatible with the pname:format, as descibed below.
+    of modifiers compatible with the pname:format, as described below.
   * pname:pDrmFormatModifierProperties is either `NULL` or an array of
     slink:VkDrmFormatModifierPropertiesEXT structures.
 

chapters/fundamentals.txt

@@ -843,7 +843,7 @@ type.
 [NOTE]
 .Note
 ====
-This language is intended to accomodate cases such as "`hidden`" extensions
+This language is intended to accommodate cases such as "`hidden`" extensions
 known only to driver internals, or layers enabling extensions without
 knowledge of the application, without allowing return of values not defined
 by any extension.
@@ -1080,7 +1080,7 @@ endif::VK_KHR_swapchain[]
   * ename:VK_ERROR_FRAGMENTED_POOL A pool allocation has failed due to
     fragmentation of the pool's memory.
     This must: only be returned if no attempt to allocate host or device
-    memory was made to accomodate the new allocation.
+    memory was made to accommodate the new allocation.
 ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
     This should: be returned in preference to
     ename:VK_ERROR_OUT_OF_POOL_MEMORY, but only if the implementation is
@@ -1113,7 +1113,7 @@ endif::VK_NV_glsl_shader[]
 ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
   * ename:VK_ERROR_OUT_OF_POOL_MEMORY A pool memory allocation has failed.
     This must: only be returned if no attempt to allocate host or device
-    memory was made to accomodate the new allocation.
+    memory was made to accommodate the new allocation.
     If the failure was definitely due to fragmentation of the pool,
     ename:VK_ERROR_FRAGMENTED_POOL should: be returned instead.
 endif::VK_VERSION_1_1,VK_KHR_maintenance1[]

chapters/pipelines.txt

@@ -43,7 +43,7 @@ ifdef::VK_NV_mesh_shader[]
 *Mesh Shading*
 
 When using the <<mesh,_mesh shading_>> pipeline input primitives are not
-assembled implicitly, but explictly through the (<<shaders-mesh,Mesh
+assembled implicitly, but explicitly through the (<<shaders-mesh,Mesh
 Shader>>).
 The work on the mesh pipeline is initiated by the application
 <<drawing-mesh-shading,drawing>> a set of mesh tasks.

chapters/synchronization.txt

@@ -2693,7 +2693,7 @@ to one or more of the following:
 
   * Returning ename:VK_ERROR_INITIALIZATION_FAILED from the command which
     resulted in the violation.
-  * Losing the logical device on which the violation occured immediately or
+  * Losing the logical device on which the violation occurred immediately or
     at a future time, resulting in a ename:VK_ERROR_DEVICE_LOST error from
     subsequent commands, including the one causing the violation.
   * Continuing execution of the violating command or operation as if the
@@ -3335,7 +3335,7 @@ When fname:vkCmdWaitEvents is submitted to a queue, it defines a memory
 dependency between prior event signal operations on the same queue or the
 host, and subsequent commands.
 fname:vkCmdWaitEvents must: not be used to wait on event signal operations
-occuring on other queues.
+occurring on other queues.
 
 The first synchronization scope only includes event signal operations that
 operate on members of pname:pEvents, and the operations that happened-before

registry.txt

@@ -1084,7 +1084,7 @@ be implemented against.
     sufficient contact information to reach the contact such as individual
     name together with Github username (`@username`), Khronos internal
     Gitlab username (`gitlab:@username`) if no public Github contact is
-    avaliable, or other contact information. If not present, this can be
+    available, or other contact information. If not present, this can be
     taken from the corresponding tag:tag attribute just like attr:author.
   * attr:type - required if the attr:supported attribute is not
     `'disabled'`. Must be either `'device'` or `'instance'`, if present.

style/extensions.txt

@@ -452,7 +452,7 @@ Changes for extensions include (but may not be limited to) the following:
      made significant direct contributions to this extension.
   * Each extension's appendix file is automatically included from
     `appendices/extensions.txt` via code generated from `vk.xml`.
-    It is no longer neccessary to explicit include the appendices.
+    It is no longer necessary to explicit include the appendices.
   * Extensions usually make significant additions and changes to the Vulkan
     specification.
     They often add an entirely new chapter, or a new section of an existing