From 102de56f69efc0a840668db245f935672edaf94d Mon Sep 17 00:00:00 2001 From: Petr Kraus Date: Fri, 27 Oct 2017 01:33:31 +0200 Subject: [PATCH] Fix random math incl. two unparsable latexmath blocks --- .../VK_EXT_blend_operation_advanced.txt | 4 +- .../appendices/VK_NV_clip_space_w_scaling.txt | 29 +++++----- .../appendices/VK_NV_viewport_swizzle.txt | 53 ++++++++++--------- .../vulkan/chapters/VK_KHR_surface/wsi.txt | 11 ++-- doc/specs/vulkan/chapters/copies.txt | 4 +- doc/specs/vulkan/chapters/descriptorsets.txt | 4 +- doc/specs/vulkan/chapters/features.txt | 4 +- doc/specs/vulkan/chapters/interfaces.txt | 4 +- doc/specs/vulkan/chapters/textures.txt | 8 +-- 9 files changed, 60 insertions(+), 61 deletions(-) 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 f6b9701f..52441527 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt @@ -53,9 +53,9 @@ according to the pname:srcPremultiplied and pname:dstPremultiplied members of slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT. If a color is considered non-premultiplied, the (R,G,B) color components are multiplied by the alpha component prior to blending. -For non-premultiplied color components in the range eq#[0,1]#, the +For non-premultiplied color components in the range [eq]#[0,1]#, the corresponding premultiplied color component would have values in the range -eq#[0 {times} A, 1 {times} A]#. +[eq]#[0 {times} A, 1 {times} A]#. Many of these advanced blending equations are formulated where the result of blending source and destination colors with partial coverage have three 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 642b7599..416d2404 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 @@ -18,27 +18,28 @@ to the final post-processed image. This extension provides a mechanism to render VR scenes at a non-uniform resolution, in particular a resolution that falls linearly from the center towards the edges. -This is achieved by scaling the "w" coordinate of the vertices in the clip -space before perspective divide. -The clip space "w" coordinate of the vertices can: be offset as of a -function of "x" and "y" coordinates as follows: +This is achieved by scaling the [eq]#w# coordinate of the vertices in the +clip space before perspective divide. +The clip space [eq]#w# coordinate of the vertices can: be offset as of a +function of [eq]#x# and [eq]#y# coordinates as follows: - w' = w + Ax + By +[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 Cartesian coordinate system. Each viewport is set to the dimension of the image, but is scissored to the quadrant it represents. -The application should specify A and B coefficients of the w-scaling -equation above, that have the same value, but different signs, for each of -the viewports. -The signs of A and B should match the signs of X and Y for the quadrant that -they represent such that the value of "w'" will always be greater than or -equal to the original "w" value for the entire image. -Since the offset to "w", (Ax + By), is always positive and increases with -the absolute values of "x" and "y", the effective resolution will fall off -linearly from the center of the image to its edges. +The application should specify [eq]#A# and [eq]#B# coefficients of the +[eq]#w#-scaling equation above, that have the same value, but different +signs, for each of the viewports. +The signs of [eq]#A# and [eq]#B# should match the signs of [eq]#x# and +[eq]#y# for the quadrant that they represent such that the value of [eq]#w'# +will always be greater than or equal to the original [eq]#w# value for the +entire image. +Since the offset to [eq]#w#, ([eq]#Ax + By#), is always positive, and +increases with the absolute values of [eq]#x# and [eq]#y#, the effective +resolution will fall off linearly from the center of the image to its edges. === 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 f299f007..e55a05d8 100644 --- a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt +++ b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt @@ -20,10 +20,10 @@ single-pass cubemap rendering (broadcasting a primitive to multiple faces and reorienting the vertex position for each face) and voxel rasterization. The per-viewport component remapping and negation provided by the swizzle allows application code to re-orient three-dimensional geometry with a view -along any of the X, Y, or Z axes. -If a perspective projection and depth buffering is required, 1/W buffering -should be used, as described in the single-pass cubemap rendering example in the "Issues" section below. +along any of the *X*, *Y*, or *Z* axes. +If a perspective projection and depth buffering is required, [eq]#1/W# +buffering should be used, as described in the single-pass cubemap rendering example in === New Object Types @@ -74,8 +74,8 @@ rendering to a cubemap. In this example, the application would attach a cubemap texture to a layered FBO where the six cube faces are treated as layers. Vertices are sent through the vertex shader without applying a projection -matrix, where the gl_Position output is (x,y,z,1) and the center of the -cubemap is at (0,0,0). +matrix, where the code:gl_Position output is [eq]#(x,y,z,1)# and the center +of the cubemap is at [eq]#(0,0,0)#. With unextended Vulkan, one could have a conventional instanced geometry shader that looks something like the following: @@ -184,39 +184,40 @@ not need to be modified as part of this coordinate transformation. Note that while the rotate() operation in the regular geometry shader above could include an arbitrary post-rotation projection matrix, the viewport swizzle does not support arbitrary math. -To get proper projection, 1/W buffering should be used. +To get proper projection, [eq]#1/W# buffering should be used. To do this: 1. -Program the viewport swizzles to move the pre-projection W eye coordinate -(typically 1.0) into the Z coordinate of the swizzle output and the eye -coordinate component used for depth into the W coordinate. -For example, the viewport corresponding to the +Z face might use a swizzle -of (+X, -Y, +W, +Z). -The Z normalized device coordinate computed after swizzling would then be -z'/w' = 1/Z_eye. +Program the viewport swizzles to move the pre-projection [eq]#W# eye +coordinate (typically 1.0) into the [eq]#Z# coordinate of the swizzle output +and the eye coordinate component used for depth into the [eq]#W# coordinate. +For example, the viewport corresponding to the [eq]#+Z# face might use a +swizzle of [eq]#(+X, -Y, +W, +Z)#. +The [eq]#Z# normalized device coordinate computed after swizzling would then +be [eq]#z'/w' = 1/Z~eye~#. 2. On NVIDIA implementations supporting floating-point depth buffers with -values outside [0,1], prevent unwanted near plane clipping by enabling +values outside [eq]#[0,1]#, prevent unwanted near plane clipping by enabling DEPTH_CLAMP. Ensure that the depth clamp doesn't mess up depth testing by programming the -depth range to very large values, such as minDepthBounds=-z, -maxDepthBounds=+z), where z == 2^127. -It should be possible to use IEEE infinity encodings also (0xFF800000 for --INF, 0x7F800000 for +INF). +depth range to very large values, such as [eq]#pname:minDepthBounds=-z#, +[eq]#pname:maxDepthBounds=+z#, where [eq]#z = 2^127^#. +It should be possible to use IEEE infinity encodings also (`0xFF800000` for +`-INF`, `0x7F800000` for `+INF`). Even when near/far clipping is disabled, primitives extending behind the eye -will still be clipped because one or more vertices will have a negative W -coordinate and fail X/Y clipping tests. +will still be clipped because one or more vertices will have a negative +[eq]#W# coordinate and fail [eq]#X#/[eq]#Y# clipping tests. -On other implementations, scale X, Y, and Z eye coordinates so that vertices -on the near plane have a post-swizzle W coordinate of 1.0. -For example, if the near plane is at Z_eye = 1/256, scale X, Y, and Z by -256. +On other implementations, scale [eq]#X#, [eq]#Y#, and [eq]#Z# eye +coordinates so that vertices on the near plane have a post-swizzle [eq]#W# +coordinate of 1.0. +For example, if the near plane is at [eq]#Z~eye~ = 1/256#, scale [eq]#X#, +[eq]#Y#, and [eq]#Z# by 256. 3. -Adjust depth testing to reflect the fact that 1/W values are large near the -eye and small away from the eye. +Adjust depth testing to reflect the fact that [eq]#1/W# values are large +near the eye and small away from the eye. Clear the depth buffer to zero (infinitely far away) and use a depth test of GREATER instead of LESS. diff --git a/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt b/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt index 9e996113..c48ba550 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_surface/wsi.txt @@ -821,7 +821,7 @@ E = (\frac{c_1 + c_2 \times L^{m_1}}{1 + c_3 \times L^{m_1}})^{m_2} \] +++++++++++++++++++ - where: +where: latexmath:[m_1 = 2610 / 4096 \times \frac{1}{4} = 0.1593017578125] + latexmath:[m_2 = 2523 / 4096 \times 128 = 78.84375] + @@ -843,12 +843,9 @@ E & = \end{aligned} +++++++++++++++++++ -latexmath:[L \text{ - is the signal normalized by the reference white -level}] + -latexmath:[r \text{ - is the reference white level and has a signal value of -0.5}] + -latexmath:[a = 0.17883277 \text{ and } b = 0.28466892 \text{, and } c = -0.55991073] +[eq]#_L_# -- is the signal normalized by the reference white level + +[eq]#_r_# -- is the reference white level and has a signal value of 0.5 + +[eq]#_a_ = 0.17883277# and [eq]#_b_ = 0.28466892# and [eq]#_c_ = 0.55991073# === Adobe RGB (1998) OETF diff --git a/doc/specs/vulkan/chapters/copies.txt b/doc/specs/vulkan/chapters/copies.txt index f4cb2b5f..2a694172 100644 --- a/doc/specs/vulkan/chapters/copies.txt +++ b/doc/specs/vulkan/chapters/copies.txt @@ -1310,11 +1310,11 @@ pname:layerCount layers are blitted to the destination image. Slices in the source region bounded by pname:srcOffsets[0].pname:z and pname:srcOffsets[1].pname:z are copied to slices in the destination region bounded by pname:dstOffsets[0].pname:z and pname:dstOffsets[1].pname:z. -For each destination slice, a source z coordinate is linearly interpolated +For each destination slice, a source *z* coordinate is linearly interpolated between pname:srcOffsets[0].pname:z and pname:srcOffsets[1].pname:z. If the pname:filter parameter is ename:VK_FILTER_LINEAR then the value sampled from the source image is taken by doing linear filtering using the -interpolated z coordinate. +interpolated *z* coordinate. If pname:filter parameter is ename:VK_FILTER_NEAREST then value sampled from the source image is taken from the single nearest slice (with undefined rounding mode). diff --git a/doc/specs/vulkan/chapters/descriptorsets.txt b/doc/specs/vulkan/chapters/descriptorsets.txt index 0457e75f..de993899 100644 --- a/doc/specs/vulkan/chapters/descriptorsets.txt +++ b/doc/specs/vulkan/chapters/descriptorsets.txt @@ -1799,8 +1799,8 @@ structure, as specified below. [[descriptorsets-updates-consecutive, consecutive binding updates]] If the pname:dstBinding has fewer than pname:descriptorCount array elements remaining starting from pname:dstArrayElement, then the remainder will be -used to update the subsequent binding - pname:dstBinding+1 starting at array -element zero. +used to update the subsequent binding - [eq]#pname:dstBinding+1# starting at +array element zero. If a binding has a pname:descriptorCount of zero, it is skipped. This behavior applies recursively, with the update affecting consecutive bindings as needed to update all pname:descriptorCount descriptors. diff --git a/doc/specs/vulkan/chapters/features.txt b/doc/specs/vulkan/chapters/features.txt index 18efa9c5..d8538b04 100644 --- a/doc/specs/vulkan/chapters/features.txt +++ b/doc/specs/vulkan/chapters/features.txt @@ -3403,8 +3403,8 @@ ifdef::VK_KHR_sampler_ycbcr_conversion[] plane 1, and a 16-bit R component in each 16-bit word of plane 2. The horizontal and vertical dimensions of the R and B planes are halved relative to the image dimensions, and each R and B component is shared - with the G components for which latexmath:[\lfloor i_G \times 0.5\ - rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B + with the G components for which latexmath:[\lfloor i_G \times 0.5 + \rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R]. The location of each plane when this image is in linear layout can be determined via vkGetImageSubresourceLayout, using diff --git a/doc/specs/vulkan/chapters/interfaces.txt b/doc/specs/vulkan/chapters/interfaces.txt index 03768a83..90687bc9 100644 --- a/doc/specs/vulkan/chapters/interfaces.txt +++ b/doc/specs/vulkan/chapters/interfaces.txt @@ -1172,9 +1172,9 @@ the code:Output storage class. + The variable decorated with code:FragStencilRefEXT must: be declared as a scalar integer value. -Only the least significant [eq]#s# bits of the integer value of the variable +Only the least significant *s* bits of the integer value of the variable decorated with code:FragStencilRefEXT are considered for stencil testing, -where [eq]#s# is the number of bits in the stencil framebuffer attachment, +where *s* is the number of bits in the stencil framebuffer attachment, and higher order bits are discarded. endif::VK_EXT_shader_stencil_export[] diff --git a/doc/specs/vulkan/chapters/textures.txt b/doc/specs/vulkan/chapters/textures.txt index 0f6748ab..ea228ef3 100644 --- a/doc/specs/vulkan/chapters/textures.txt +++ b/doc/specs/vulkan/chapters/textures.txt @@ -1707,7 +1707,7 @@ The LOD parameter [eq]#{lambda}# is computed as follows: \begin{aligned} \lambda_{base}(x,y) & = \begin{cases} - shaderOp.Lod & \text{(from optional: SPIR-V operand)} \\ + shaderOp.Lod & \text{(from optional SPIR-V operand)} \\ \log_2 \left ( \frac{\rho_{max}}{N} \right ) & \text{otherwise} \end{cases} \\ \lambda'(x,y) & = \lambda_{base} + \mathbin{clamp}(sampler.bias + shaderOp.bias,-maxSamplerLodBias,maxSamplerLodBias) \\ @@ -1729,13 +1729,13 @@ where: sampler.bias & = mipLodBias & \text{(from sampler descriptor)} \\ shaderOp.bias & = \begin{cases} - Bias & \text{(from optional: SPIR-V operand)} \\ + Bias & \text{(from optional SPIR-V operand)} \\ 0 & \text{otherwise} \end{cases} \\ sampler.lod_{min} & = minLod & \text{(from sampler descriptor)} \\ shaderOp.lod_{min} & = \begin{cases} - MinLod & \text{(from optional: SPIR-V operand)} \\ + MinLod & \text{(from optional SPIR-V operand)} \\ 0 & \text{otherwise} \end{cases} \\ \\ @@ -1760,7 +1760,7 @@ computed based on the LOD parameter, as follows: \begin{aligned} d_{l} = \begin{cases} - nearest(d'), & \text{mipmapMode is VK_SAMPLER_MIPMAP_MODE_NEAREST} \\ + nearest(d'), & \text{mipmapMode is VK\_SAMPLER\_MIPMAP\_MODE\_NEAREST} \\ d', & \text{otherwise} \end{cases} \end{aligned}