parent
5436521608
commit
102de56f69
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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[]
|
||||
|
|
|
@ -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}
|
||||
|
|
Loading…
Reference in New Issue