diff --git a/COPYING.md b/COPYING.md index 23c84f25..aec62426 100644 --- a/COPYING.md +++ b/COPYING.md @@ -1,39 +1,74 @@ -The files in, and generated output documents from this Vulkan-Docs -project are under a mix of copyright and license statements. Refer to -the individual files for specific information. As a general -guideline: +COPYING.md for the KhronosGroup/Vulkan-Docs project +=================================================== -* The Vulkan Specification asciidoc sources, as well as other documentation - which we expect people may wish to regenerate and distributed in other - formats - such as the reference pages generated from the Specification - source - are under a Creative Commons Attribution 4.0 license. -** The specification sources have only recently (as of June 2017) been - placed under this license. We will now be able to accept pull requests on - Github, but there is a related Contribution License Agreement which - people proposing PRs to the Vulkan-Docs repository must execute as part - of opening the PR. -* Generated output documents, including the official Vulkan Specification - PDF and HTML documents, are under a proprietary Khronos license. See - https://www.khronos.org/registry/speccopyright.html . Only Specification - documents posted in the Vulkan Registry are official. -* The Vulkan headers, spec build tools, and spec and registry configuration - files are, for the most part, under the Apache 2 license. Some older files - are under BSD-like licenses which may eventually be updated to Apache 2 as - we have time. -* There may be some configuration files customized from material shipped - with the asciidoc and dblatex distributions. Such files continue under - their original copyrights. -* Some generated, transient files produced during the course of building - the specification, headers, or other targets may not have copyrights. - These are typically very short asciidoc fragments describing parts of - the Vulkan API, and are incorporated by reference into specification - or reference page builds. -* If something is missing a copyright statement and that poses an - *actual problem* for whatever you're doing, file an issue on GitHub - and we'll eventually correct it in some fashion. +# Licenses -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 changes in anything having to to with -copyrights and licensing. +The Vulkan-Docs project uses several licenses. + +* The source files (in asciidoctor and other formats) for the Vulkan + Specification, reference pages, and supporting documentation are licensed + under the Creative Commons Attribution 4.0 International License + ("CC-BY"). +* Header files, scripts, programs, XML files, and other tooling used or + generated as part of the build process is licensed under the Apache + License, Version 2.0. +* There are a few remaining configuration files and scripts adopted from + other open source projects, such as the 'optimize-pdf' script. Such files + continue under their original copyrights. +* Some generated, transient files produced during the course of building the + specification, headers, or other targets may not have copyrights. These + are typically very short asciidoc fragments describing parts of the Vulkan + API, and are incorporated by reference into specification or reference + page builds. + +Users outside Khronos who create and post Vulkan Specifications, whether +modified or not, should use the CC-BY license on the output documents (HTML, +PDF, etc.) they generate. + + +# Frequently Asked Questions + +Q: Why are the HTML and PDF Specifications posted on Khronos' website under +a license which is neither CC-BY nor Apache 2.0? + +A: The Specifications posted by Khronos in the Vulkan Registry are licensed +under the proprietary Khronos Specification License. Only these +Specifications are Ratified by the Khronos Board of Promoters, and therefore +they are the only Specifications covered by the Khronos Intellectual +Property Rights Policy. + + +Q: Does Khronos allow the creation and distribution of modified versions of +the Vulkan Specification, such as translations to other languages? + +A: Yes. Such modified Specifications, since they are not created by Khronos, +should be placed under the CC-BY license. If you believe your modifications +are of general interest, consider contributing them back by making a pull +request (PR) on the Vulkan-Docs project. + + +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 +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 +in a timely fashion. + + +Q: Can you change the license on your files so they're compatible with my +license? + +A: We've added an "Exceptions to the Apache 2.0 License" clause to the +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 +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 +changes in anything having to to with copyrights and licensing. diff --git a/appendices/memorymodel.txt b/appendices/memorymodel.txt index 55fe7c2f..e0471deb 100644 --- a/appendices/memorymodel.txt +++ b/appendices/memorymodel.txt @@ -153,7 +153,7 @@ Each atomic operation has a memory <> and a <>. Informally, the scope determines which other agents it is atomic with respect to, and the <> constrains -the ordering of other memory accesses. +its ordering against other memory accesses. Device atomic operations have explicit scopes and semantics. Each host atomic operation implicitly uses the code:CrossDevice scope, and uses a memory semantics equivalent to a C++ std::memory_order value of @@ -175,8 +175,9 @@ potentially-mutually-ordered and any of the following are true: * A is a device operation, B is a host operation, and the implementation supports concurrent host- and device-atomics. -NOTE: If two atomic operations are not mutually-ordered, then each must: be -synchronized against the other as if it were a non-atomic operation. +NOTE: If two atomic operations are not mutually-ordered, and if their sets of +memory locations overlap, then each must: be synchronized against the other +as if they were non-atomic operations. [[memory-model-scoped-modification-order]] == Scoped Modification Order @@ -184,6 +185,7 @@ synchronized against the other as if it were a non-atomic operation. For a given atomic operation A, all atomic operations that are mutually-ordered with A occur in an order known as A's _scoped modification order_. +A's scoped modification order relates no other operations. NOTE: Invocations outside the instance of A's memory scope may: observe the values at A's set of memory locations becoming visible to it in an order @@ -271,7 +273,7 @@ tessellation control shaders, which is the only execution model where output variables are shared between invocations. The memory semantics operand also optionally includes availability and -visibility flags, which apply availability and/or visibility operations as +visibility flags, which apply optional availability and visibility operations as described in <>. The availability/visibility flags are: @@ -310,8 +312,8 @@ definition. [[memory-model-synchronizes-with]] == Synchronizes-With -_Synchronizes-with_ is a relation between atomic operations and/or memory -barriers (aka fences on the host). +_Synchronizes-with_ is a relation between operations, where each operation +is either an atomic operation or a memory barrier (aka fence on the host). If A and B are atomic operations, then A synchronizes-with B if and only if all of the following are true: @@ -319,7 +321,8 @@ all of the following are true: * A performs a release operation * B performs an acquire operation * A and B are mutually-ordered - * B takes its value from the release sequence headed by A + * B reads a value written by A or by an operation in the release sequence + headed by A code:OpControlBarrier, code:OpMemoryBarrier, and code:OpMemoryNamedBarrier are _memory barrier_ instructions in SPIR-V. @@ -331,8 +334,10 @@ following are true: * there exists an atomic write X (with any memory semantics) * A is program-ordered before X * X and B are mutually-ordered - * B reads the value written by X (or the release sequence headed by X, if - X has release semantics) + * B reads a value written by X or by an operation in the release sequence + headed by X + ** If X is relaxed, it is still considered to head a hypothetical release + sequence for this rule * A and B are in the instance of each other's memory scopes * X's storage class is in A's semantics. @@ -343,7 +348,8 @@ following are true: * there exists an atomic read X (with any memory semantics) * X is program-ordered before B * X and A are mutually-ordered - * X reads the value written by A (or the release sequence headed by A) + * X reads a value written by A or by an operation in the release sequence + headed by A * A and B are in the instance of each other's memory scopes * X's storage class is in B's semantics. @@ -355,15 +361,17 @@ synchronizes-with B if all of the following are true: * there exists an atomic read Y (with any memory semantics) * Y is program-ordered before B * X and Y are mutually-ordered - * Y reads the value written by X (or the release sequence headed by X, if - X has release semantics) + * Y reads the value written by X or by an operation in the release sequence + headed by X + ** If X is relaxed, it is still considered to head a hypothetical release + sequence for this rule * A and B are in the instance of each other's memory scopes * X's and Y's storage class is in A's and B's semantics. ** NOTE: X and Y must have the same storage class, because they are mutually ordered. If A is a release barrier and B is an acquire barrier and C is a control -barrier (where A can optionally equal C and/or B can optionally equal C), +barrier (where A can optionally equal C and B can optionally equal C), then A synchronizes-with B if all of the following are true: * A is program-ordered before (or equals) C diff --git a/chapters/descriptorsets.txt b/chapters/descriptorsets.txt index 190df469..1359bd83 100644 --- a/chapters/descriptorsets.txt +++ b/chapters/descriptorsets.txt @@ -3876,6 +3876,15 @@ include::../api/protos/vkCmdPushConstants.txt[] * pname:pValues is an array of pname:size bytes containing the new push constant values. +[NOTE] +.Note +==== +As pname:stageFlags needs to include all flags the relevant push constant +ranges were created with, any flags that are not supported by the queue +family that the slink:VkCommandPool used to allocate pname:commandBuffer was +created on are ignored. +==== + .Valid Usage **** * [[VUID-vkCmdPushConstants-offset-01795]] diff --git a/chapters/features.txt b/chapters/features.txt index 62a53794..f49e650b 100644 --- a/chapters/features.txt +++ b/chapters/features.txt @@ -7242,6 +7242,10 @@ ifdef::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[] with a handle type included in the pname:handleTypes member for which mipmap image support is not required endif::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[] +ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[] + ** image pname:format is one of those listed in + <> +endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[] * pname:maxArrayLayers is the maximum number of array layers. * If pname:tiling is ename:VK_IMAGE_TILING_LINEAR, then pname:maxArrayLayers must: either be equal to 1 or be no less than diff --git a/chapters/fragops.txt b/chapters/fragops.txt index 02115bc6..17de4cbd 100644 --- a/chapters/fragops.txt +++ b/chapters/fragops.txt @@ -592,7 +592,8 @@ ifdef::VK_AMD_mixed_attachment_samples[] [[fragops-mixed-attachment-samples]] == Mixed attachment samples -Special rules apply to per-fragment operations when the number of samples of +When the +VK_AMD_mixed_attachment_samples+ extension is enabled, +special rules apply to per-fragment operations when the number of samples of the color attachments differs from the number of samples of the depth/stencil attachment used in a subpass. @@ -1266,16 +1267,14 @@ with one bit for each sample in the color attachment(s) for the subpass. If a bit in the color sample mask is 0, then blending and writing to the framebuffer are not performed for that sample. -ifndef::VK_NV_framebuffer_mixed_samples[] - -Each color sample is associated with a unique rasterization sample, and the +When the +VK_NV_framebuffer_mixed_samples+ extension is not enabled, +each color sample is associated with a unique rasterization sample, and the value of the coverage mask is assigned to the color sample mask. -endif::VK_NV_framebuffer_mixed_samples[] - ifdef::VK_NV_framebuffer_mixed_samples[] -If the pipeline's +When the +VK_NV_framebuffer_mixed_samples+ extension is enabled, +if the pipeline's slink:VkPipelineMultisampleStateCreateInfo::pname:rasterizationSamples is greater than one and the slink:VkAttachmentDescription::pname:samples of the color attachments is one, then the fragment's coverage is reduced from diff --git a/chapters/pipelines.txt b/chapters/pipelines.txt index 5865ce68..e1184efd 100644 --- a/chapters/pipelines.txt +++ b/chapters/pipelines.txt @@ -839,28 +839,29 @@ endif::VK_EXT_sample_locations[] pname:layout must: be <> with all shaders specified in pname:pStages -ifndef::VK_AMD_mixed_attachment_samples[] -ifndef::VK_NV_framebuffer_mixed_samples[] * [[VUID-VkGraphicsPipelineCreateInfo-subpass-00757]] - If pname:subpass uses color and/or depth/stencil attachments, then the + If neither the +VK_AMD_mixed_attachment_samples+ nor the + +VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if + pname:subpass uses color and/or depth/stencil attachments, then the pname:rasterizationSamples member of pname:pMultisampleState must: be the same as the sample count for those subpass attachments -endif::VK_NV_framebuffer_mixed_samples[] -endif::VK_AMD_mixed_attachment_samples[] ifdef::VK_AMD_mixed_attachment_samples[] * [[VUID-VkGraphicsPipelineCreateInfo-subpass-01505]] - If pname:subpass uses color and/or depth/stencil attachments, then the + If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and + if pname:subpass uses color and/or depth/stencil attachments, then the pname:rasterizationSamples member of pname:pMultisampleState must: equal the maximum of the sample counts of those subpass attachments endif::VK_AMD_mixed_attachment_samples[] ifdef::VK_NV_framebuffer_mixed_samples[] * [[VUID-VkGraphicsPipelineCreateInfo-subpass-01411]] - If pname:subpass has a depth/stencil attachment and depth test, stencil + If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and + if pname:subpass has a depth/stencil attachment and depth test, stencil test, or depth bounds test are enabled, then the pname:rasterizationSamples member of pname:pMultisampleState must: be the same as the sample count of the depth/stencil attachment * [[VUID-VkGraphicsPipelineCreateInfo-subpass-01412]] - If pname:subpass has any color attachments, then the + If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and + if pname:subpass has any color attachments, then the pname:rasterizationSamples member of pname:pMultisampleState must: be greater than or equal to the sample count for those subpass attachments endif::VK_NV_framebuffer_mixed_samples[] diff --git a/chapters/primsrast.txt b/chapters/primsrast.txt index 9415e8ff..ed8648c8 100644 --- a/chapters/primsrast.txt +++ b/chapters/primsrast.txt @@ -153,7 +153,8 @@ include::../api/structs/VkPipelineMultisampleStateCreateInfo.txt[] pname:minSampleShading must: be in the range [eq]#[0,1]# ifdef::VK_NV_framebuffer_mixed_samples[] * [[VUID-VkPipelineMultisampleStateCreateInfo-rasterizationSamples-01415]] - If the subpass has any color attachments and pname:rasterizationSamples + If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and + if the subpass has any color attachments and pname:rasterizationSamples is greater than the number of color samples, then pname:sampleShadingEnable must: be ename:VK_FALSE endif::VK_NV_framebuffer_mixed_samples[] @@ -183,24 +184,30 @@ Surviving fragments are processed by fragment shaders. Fragment shaders determine associated data for fragments, and can: also modify or replace their assigned depth values. -ifndef::VK_AMD_mixed_attachment_samples[] -ifndef::VK_NV_framebuffer_mixed_samples[] - -If the subpass for which this pipeline is being created uses color and/or +When the +VK_AMD_mixed_attachment_samples+ and ++VK_NV_framebuffer_mixed_samples+ extensions are not enabled, +if the subpass for which this pipeline is being created uses color and/or depth/stencil attachments, then pname:rasterizationSamples must: be the same as the sample count for those subpass attachments. -endif::VK_NV_framebuffer_mixed_samples[] -endif::VK_AMD_mixed_attachment_samples[] - ifdef::VK_AMD_mixed_attachment_samples[] -If the subpass for which this pipeline is being created uses color and/or +When the +VK_AMD_mixed_attachment_samples+ extension is enabled, +if the subpass for which this pipeline is being created uses color and/or depth/stencil attachments, then pname:rasterizationSamples must: be the same as the maximum of the sample counts of those subpass attachments. endif::VK_AMD_mixed_attachment_samples[] +ifdef::VK_NV_framebuffer_mixed_samples[] + +When the +VK_NV_framebuffer_mixed_samples+ extension is enabled, +pname:rasterizationSamples must: match the sample count of the depth/stencil +attachment if present, otherwise must: be greater than or equal to the sample +count of the color attachments, if present. + +endif::VK_NV_framebuffer_mixed_samples[] + If the subpass for which this pipeline is being created does not use color or depth/stencil attachments, pname:rasterizationSamples must: follow the rules for a <>. @@ -1267,13 +1274,14 @@ process for each fragment. If sample shading is enabled an implementation must: provide a minimum of [eq]#max({lceil} pname:minSampleShadingFactor {times} pname:totalSamples {rceil}, 1)# unique associated data for each fragment, where -pname:minSampleShadingFactor is the minimum fraction of sample shading and -pname:totalSamples is +pname:minSampleShadingFactor is the minimum fraction of sample shading. ifdef::VK_AMD_mixed_attachment_samples[] -the number of samples of the color attachments used in the subpass or, if -the subpass does not use any color attachments, +If the +VK_AMD_mixed_attachment_samples+ extension is enabled and the subpass +uses color attachments, pname:totalSamples is the number of samples of the +color attachments. +Otherwise, endif::VK_AMD_mixed_attachment_samples[] -the value of +pname:totalSamples is the value of slink:VkPipelineMultisampleStateCreateInfo::pname:rasterizationSamples specified at pipeline creation time. These are associated with the samples in an implementation-dependent manner. diff --git a/chapters/renderpass.txt b/chapters/renderpass.txt index e4a6eb6f..8dd704e7 100644 --- a/chapters/renderpass.txt +++ b/chapters/renderpass.txt @@ -868,19 +868,18 @@ attachment. ename:VK_ATTACHMENT_UNUSED must: have the same sample count ifdef::VK_AMD_mixed_attachment_samples[] * [[VUID-VkSubpassDescription-pColorAttachments-01506]] - All attachments in pname:pColorAttachments that are not + If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and + all attachments in pname:pColorAttachments that are not ename:VK_ATTACHMENT_UNUSED must: have a sample count that is smaller than or equal to the sample count of pname:pDepthStencilAttachment if it is not ename:VK_ATTACHMENT_UNUSED endif::VK_AMD_mixed_attachment_samples[] -ifndef::VK_AMD_mixed_attachment_samples[] -ifndef::VK_NV_framebuffer_mixed_samples[] * [[VUID-VkSubpassDescription-pDepthStencilAttachment-01418]] - If pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and + If neither the +VK_AMD_mixed_attachment_samples+ nor the + +VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if + pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and any attachments in pname:pColorAttachments are not ename:VK_ATTACHMENT_UNUSED, they must: have the same sample count -endif::VK_NV_framebuffer_mixed_samples[] -endif::VK_AMD_mixed_attachment_samples[] * [[VUID-VkSubpassDescription-None-00852]] If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any pipelines bound during the subpass must: not access those input @@ -1694,19 +1693,18 @@ corresponding subpass. ename:VK_ATTACHMENT_UNUSED must: have the same sample count ifdef::VK_AMD_mixed_attachment_samples[] * [[VUID-VkSubpassDescription2KHR-pColorAttachments-03070]] - All attachments in pname:pColorAttachments that are not + If the +VK_AMD_mixed_attachment_samples+ extension is enabled, + all attachments in pname:pColorAttachments that are not ename:VK_ATTACHMENT_UNUSED must: have a sample count that is smaller than or equal to the sample count of pname:pDepthStencilAttachment if it is not ename:VK_ATTACHMENT_UNUSED endif::VK_AMD_mixed_attachment_samples[] -ifndef::VK_AMD_mixed_attachment_samples[] -ifndef::VK_NV_framebuffer_mixed_samples[] * [[VUID-VkSubpassDescription2KHR-pDepthStencilAttachment-03071]] - If pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and + If neither the +VK_AMD_mixed_attachment_samples+ nor the + +VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if + pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and any attachments in pname:pColorAttachments are not ename:VK_ATTACHMENT_UNUSED, they must: have the same sample count -endif::VK_NV_framebuffer_mixed_samples[] -endif::VK_AMD_mixed_attachment_samples[] * [[VUID-VkSubpassDescription2KHR-None-03072]] If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any pipelines bound during the subpass must: not access those input diff --git a/chapters/textures.txt b/chapters/textures.txt index 33eded68..a7bfaedc 100644 --- a/chapters/textures.txt +++ b/chapters/textures.txt @@ -978,36 +978,44 @@ pname:chromaFilter is ename:VK_FILTER_NEAREST for explicit reconstruction. Due to the number of options, these formulae are expressed more concisely as follows: + -[width="30%",options="header",cols="5,1"] -|==== -| pname:xChromaOffset | δ~i~ -| etext:COSITED_EVEN | 0 -| etext:MIDPOINT | 0.5 -|==== -+ -[width="30%",options="header",cols="5,1"] -|==== -| pname:yChromaOffset | δ~j~ -| etext:COSITED_EVEN | 0 -| etext:MIDPOINT | 0.5 -|==== +[latexmath] ++++++ +\begin{aligned} + i_{RB} & = + \begin{cases} + 0.5 \times (i) & \textrm{If xChromaOffset = COSITED}\_\textrm{EVEN} \\ + 0.5 \times (i - 0.5) & \textrm{If xChromaOffset = MIDPOINT} + \end{cases}\\ + j_{RB} & = + \begin{cases} + 0.5 \times (j) & \textrm{If yChromaOffset = COSITED}\_\textrm{EVEN} \\ + 0.5 \times (j - 0.5) & \textrm{If yChromaOffset = MIDPOINT} + \end{cases}\\ + \\ + i_{floor} & = \lfloor i_{RB} \rfloor \\ + j_{floor} & = \lfloor j_{RB} \rfloor \\ + \\ + i_{frac} & = i_{RB} - i_{floor} \\ + j_{frac} & = j_{RB} - j_{floor} +\end{aligned} ++++++ + [latexmath] +++++ \begin{aligned} -\tau_{RB}'(i,j) = &\\ -&\tau_{RB}(\lfloor 0.5\times(i-\delta_i)\rfloor, \lfloor 0.5\times(j-\delta_j)\rfloor)[level] -&& \times (1 - (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor)) -&& \times (1 - (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor)) +\\ -&\tau_{RB}(1+\lfloor 0.5\times(i-\delta_i)\rfloor, \lfloor 0.5\times(j-\delta_j)\rfloor)[level] -&& \times (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor) -&& \times (1 - (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor)) +\\ -&\tau_{RB}(\lfloor 0.5\times(i-\delta_i)\rfloor, 1+\lfloor 0.5\times(j-\delta_j)\rfloor)[level] -&& \times (1 - (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor)) -&& \times (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor) +\\ -&\tau_{RB}(1+\lfloor 0.5\times(i-\delta_i)\rfloor, 1+\lfloor 0.5\times(j-\delta_j)\rfloor)[level] -&& \times (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor) -&& \times (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor) +\tau_{RB}'(i,j) = + & \tau_{RB}( i_{floor}, j_{floor})[level] + & \times & ( 1 - i_{frac} ) & + & \times & ( 1 - j_{frac} ) & + \\ + & \tau_{RB}( 1 + i_{floor}, j_{floor})[level] + & \times & ( i_{frac} ) & + & \times & ( 1 - j_{frac} ) & + \\ + & \tau_{RB}( i_{floor}, 1 + j_{floor})[level] + & \times & ( 1 - i_{frac} ) & + & \times & ( j_{frac} ) & + \\ + & \tau_{RB}( 1 + i_{floor}, 1 + j_{floor})[level] + & \times & ( i_{frac} ) & + & \times & ( j_{frac} ) & \end{aligned} +++++ diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h index f7d69ade..14f58b39 100644 --- a/include/vulkan/vulkan_core.h +++ b/include/vulkan/vulkan_core.h @@ -47,7 +47,7 @@ extern "C" { #define VK_NULL_HANDLE 0 - + #define VK_DEFINE_HANDLE(object) typedef struct object##_T* object; @@ -60,7 +60,7 @@ extern "C" { #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object; #endif #endif - + typedef uint32_t VkFlags; @@ -406,7 +406,7 @@ typedef enum VkStructureType { VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT = 1000158001, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT = 1000158002, VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT = 1000158003, - VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT = 1000158004, + VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT = 1000158004, VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT = 1000158005, VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT = 1000160000, VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT = 1000160001, diff --git a/xml/vk.xml b/xml/vk.xml index 74852603..c0b8e5cb 100644 --- a/xml/vk.xml +++ b/xml/vk.xml @@ -977,7 +977,7 @@ server. const void* pNext VkShaderModuleCreateFlags flags size_t codeSizeSpecified in bytes - const uint32_t* pCodeBinary code of size codeSize + const uint32_t* pCodeBinary code of size codeSize uint32_t bindingBinding number for this entry @@ -3564,7 +3564,7 @@ server. const uint64_t* pDrmFormatModifiers - VkStructureType sType + VkStructureType sType const void* pNext uint64_t drmFormatModifier uint32_t drmFormatModifierPlaneCount @@ -9367,7 +9367,7 @@ server. - +