diff --git a/COPYING.md b/COPYING.md index c5454487..a542522c 100644 --- a/COPYING.md +++ b/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 diff --git a/ChangeLog.txt b/ChangeLog.txt index 7708b642..563a69a9 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -4448,7 +4448,7 @@ Change log for February 25, 2015 Vulkan 1.0.4 spec update: <> 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 diff --git a/appendices/VK_EXT_hdr_metadata.txt b/appendices/VK_EXT_hdr_metadata.txt index ee5b3065..72a152a2 100644 --- a/appendices/VK_EXT_hdr_metadata.txt +++ b/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. diff --git a/appendices/VK_EXT_image_drm_format_modifier.txt b/appendices/VK_EXT_image_drm_format_modifier.txt index 1814b186..2d22ff21 100644 --- a/appendices/VK_EXT_image_drm_format_modifier.txt +++ b/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. diff --git a/appendices/VK_KHR_external_memory.txt b/appendices/VK_KHR_external_memory.txt index 724a8625..9ca8696a 100644 --- a/appendices/VK_KHR_external_memory.txt +++ b/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 diff --git a/appendices/VK_KHR_external_semaphore.txt b/appendices/VK_KHR_external_semaphore.txt index 05455b52..e7ee60c9 100644 --- a/appendices/VK_KHR_external_semaphore.txt +++ b/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? diff --git a/appendices/VK_KHR_shared_presentable_image.txt b/appendices/VK_KHR_shared_presentable_image.txt index 5e51b16e..c1b504dc 100644 --- a/appendices/VK_KHR_shared_presentable_image.txt +++ b/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. diff --git a/appendices/boilerplate.txt b/appendices/boilerplate.txt index bcf1cb6d..aacd6f7a 100644 --- a/appendices/boilerplate.txt +++ b/appendices/boilerplate.txt @@ -97,7 +97,7 @@ With these macros, a Vulkan function declaration takes the form of: VKAPI_ATTR VKAPI_CALL (); ---------------------------------------- -Additionaly, a Vulkan function pointer type declaration takes the form of: +Additionally, a Vulkan function pointer type declaration takes the form of: [source,c++] ---------------------------------------- diff --git a/chapters/VK_KHR_surface/wsi.txt b/chapters/VK_KHR_surface/wsi.txt index ad22f516..53319ed3 100644 --- a/chapters/VK_KHR_surface/wsi.txt +++ b/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 diff --git a/chapters/features.txt b/chapters/features.txt index 34f04237..08c8d842 100644 --- a/chapters/features.txt +++ b/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. diff --git a/chapters/fundamentals.txt b/chapters/fundamentals.txt index 440047dd..467344f2 100644 --- a/chapters/fundamentals.txt +++ b/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[] diff --git a/chapters/pipelines.txt b/chapters/pipelines.txt index 7993174f..aced2ee1 100644 --- a/chapters/pipelines.txt +++ b/chapters/pipelines.txt @@ -43,7 +43,7 @@ ifdef::VK_NV_mesh_shader[] *Mesh Shading* When using the <> pipeline input primitives are not -assembled implicitly, but explictly through the (<>). The work on the mesh pipeline is initiated by the application <> a set of mesh tasks. diff --git a/chapters/synchronization.txt b/chapters/synchronization.txt index 7d376f89..11087217 100644 --- a/chapters/synchronization.txt +++ b/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 diff --git a/registry.txt b/registry.txt index 4cc1d4a4..34ee1b76 100644 --- a/registry.txt +++ b/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. diff --git a/style/extensions.txt b/style/extensions.txt index 192d5b89..fc350468 100644 --- a/style/extensions.txt +++ b/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