summaryrefslogtreecommitdiffstats
path: root/doc/specs/vulkan/appendices
diff options
context:
space:
mode:
Diffstat (limited to 'doc/specs/vulkan/appendices')
-rw-r--r--doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt4
-rw-r--r--doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt29
-rw-r--r--doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt53
3 files changed, 44 insertions, 42 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 f6b9701..5244152 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 642b759..416d240 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 f299f00..e55a05d 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.