Skip to content
Permalink
Browse files

Change log for March 11, 2019 Vulkan 1.1.103 spec update:

  * Update release number to 103.

Public Issues:

  * Remove (unnecessary) scoped modification order case from the memory
    model <<memory-model-location-ordered, location-ordered>> definition
    (public pull request 924).
  * Add an <<memory-model-acyclicity, acyclicity>> axiom to the memory model
    (public pull request 927).

Internal Issues:

  * Fix reversed logic of slink:VkFormatProperties discussion of multi-plane
    formats and ename:VK_FORMAT_FEATURE_DISJOINT_BIT (internal issue 1493).
  * Clarify how slink:VkImageStencilUsageCreateInfoEXT works, including new
    valid usage statements for flink:vkCmdClearDepthStencilImage, and the
    <<copies, Common Operation>> section of the Copy Commands chapter
    (internal issue 1565).
  * Update <<spirvenv-precision-operation, Precision and Operation of SPIR-V
    Instructions>> section to require that denorms be preserved by several
    instructions that don't perform any mathematical operations (internal
    issue 1584).
  * Remove duplicate valid usage statement from flink:vkAcquireNextImageKHR
    (internal merge request 3062).
  • Loading branch information...
oddhack committed Mar 11, 2019
1 parent 61f3b23 commit 4ad4fd17161efd9bfd1125c0c9d17db6fb276216
@@ -8,6 +8,35 @@ public pull requests that have been accepted.

-----------------------------------------------------

Change log for March 11, 2019 Vulkan 1.1.103 spec update:

* Update release number to 103.

Public Issues:

* Remove (unnecessary) scoped modification order case from the memory
model <<memory-model-location-ordered, location-ordered>> definition
(public pull request 924).
* Add an <<memory-model-acyclicity, acyclicity>> axiom to the memory model
(public pull request 927).

Internal Issues:

* Fix reversed logic of slink:VkFormatProperties discussion of multi-plane
formats and ename:VK_FORMAT_FEATURE_DISJOINT_BIT (internal issue 1493).
* Clarify how slink:VkImageStencilUsageCreateInfoEXT works, including new
valid usage statements for flink:vkCmdClearDepthStencilImage, and the
<<copies, Common Operation>> section of the Copy Commands chapter
(internal issue 1565).
* Update <<spirvenv-precision-operation, Precision and Operation of SPIR-V
Instructions>> section to require that denorms be preserved by several
instructions that don't perform any mathematical operations (internal
issue 1584).
* Remove duplicate valid usage statement from flink:vkAcquireNextImageKHR
(internal merge request 3062).

-----------------------------------------------------

Change log for March 3, 2019 Vulkan 1.1.102 spec update:

* Update release number to 102.
@@ -115,7 +115,7 @@ VERBOSE =
# ADOCOPTS options for asciidoc->HTML5 output

NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 102
PATCHVERSION = 103
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else
@@ -789,14 +789,14 @@ will still be visible-to Y.
[[memory-model-acyclicity]]
== Acyclicity

_Reads-from_ is a relation between operations, where the first operation is a
write, the second operation is a read, and the second operation reads the
_Reads-from_ is a relation between operations, where the first operation is
a write, the second operation is a read, and the second operation reads the
value written by the first operation.
_From-reads_ is a relation between operations, where the first operation is a
read, the second operation is a write, and the first operation reads a value
written earlier than the second operation in the second operation's scoped
modification order (or the first operation reads from the initial value, and
the second operation is any write to the same locations).
_From-reads_ is a relation between operations, where the first operation is
a read, the second operation is a write, and the first operation reads a
value written earlier than the second operation in the second operation's
scoped modification order (or the first operation reads from the initial
value, and the second operation is any write to the same locations).

Then the implementation must: guarantee that no cycles exist in the union of
the following relations:
@@ -813,13 +813,14 @@ sequences of operations can't violate causality.
=== Scoped Modification Order Coherence

Let A and B be mutually-ordered atomic operations, where A is
location-ordered before B.
Then the following rules are a consequence of acyclicity:

* If A and B are both reads and A does not read the initial value, then the
write that A takes its value from must: be earlier in its own scoped
modification order than (or the same as) the write that B takes its value
from (no cycles between location-order, reads-from, and from-reads).
location-ordered before B. Then the following rules are a consequence of
acyclicity:

* If A and B are both reads and A does not read the initial value, then
the write that A takes its value from must: be earlier in its own scoped
modification order than (or the same as) the write that B takes its
value from (no cycles between location-order, reads-from, and
from-reads).
* If A is a read and B is a write and A does not read the initial value,
then A must: take its value from a write earlier than B in B's scoped
modification order (no cycles between location-order, scope modification
@@ -831,8 +832,9 @@ Then the following rules are a consequence of acyclicity:
modification order (no cycles between location-order and scoped
modification order).
* If A is a write and B is a read-modify-write and B reads the value
written by A, then B comes immediately after A in A's scoped modification
order (no cycles between scoped modification order and from-reads).
written by A, then B comes immediately after A in A's scoped
modification order (no cycles between scoped modification order and
from-reads).

[[memory-model-shader-io]]
== Shader I/O
@@ -934,26 +934,6 @@ endif::VK_NV_cooperative_matrix[]
[[spirvenv-precision-operation]]
== Precision and Operation of SPIR-V Instructions

ifndef::VK_KHR_shader_float_controls[]
The following rules apply to both single and double-precision floating point
instructions:

* Positive and negative infinities and positive and negative zeros are
generated as dictated by <<ieee-754,IEEE 754>>, but subject to the
precisions allowed in the following table.
* Dividing a non-zero by a zero results in the appropriately signed
<<ieee-754,IEEE 754>> infinity.
* Any denormalized value input into a shader or potentially generated by
any instruction in a shader may: be flushed to 0.
* The rounding mode cannot: be set, and results will be <<Correctly
Rounded>>, as described below.
* [eq]##NaN##s may: not be generated.
Instructions that operate on a [eq]#NaN# may: not result in a [eq]#NaN#.
* Support for signaling [eq]##NaN##s is optional: and exceptions are never
raised.
endif::VK_KHR_shader_float_controls[]

ifdef::VK_KHR_shader_float_controls[]
The following rules apply to half, single, and double-precision floating
point instructions:

@@ -966,6 +946,24 @@ point instructions:
are never raised.
Signaling [eq]##NaN## may: be converted to quiet [eq]##NaN##s values by
any floating point instruction.
* The following instructions must: not flush denormalized values:
code:OpConstant, code:OpConstantComposite, code:OpSpecConstant,
code:OpSpecConstantComposite, code:OpLoad, code:OpStore, code:OpBitcast,
code:OpPhi, code:OpSelect, code:OpFunctionCall, code:OpReturnValue,
code:OpVectorExtractDynamic, code:OpVectorInsertDynamic,
code:OpVectorShuffle, code:OpCompositeConstruct,
code:OpCompositeExtract, code:OpCompositeInsert, code:OpCopyMemory,
code:OpCopyObject.
ifndef::VK_KHR_shader_float_controls[]
* Any denormalized value input into a shader or potentially generated by
any instruction in a shader (except those listed above) may: be flushed
to 0.
* The rounding mode cannot: be set, and results will be <<Correctly
Rounded>>, as described below.
* [eq]##NaN##s may: not be generated.
Instructions that operate on a [eq]#NaN# may: not result in a [eq]#NaN#.
endif::VK_KHR_shader_float_controls[]
ifdef::VK_KHR_shader_float_controls[]
* By default, the implementation may: perform optimizations on half,
single, or double-precision floating-point instructions respectively
that ignore sign of a zero, or assume that arguments and results are not
@@ -986,12 +984,13 @@ point instructions:
This execution mode must: also be respected by code:OpLoad except for
loads from the code:Input storage class in the fragment shader stage
with the floating-point result type.
Other SPIR-V instruction may: also respect the
Other SPIR-V instructions may: also respect the
code:SignedZeroInfNanPreserve execution mode.
* Denormalized values are supported.
** By default, any half, single, or double-precision denormalized value
input into a shader or potentially generated by any instruction or any
extended instructions for GLSL in a shader may: be flushed to zero.
input into a shader or potentially generated by any instruction (except
those listed above) or any extended instructions for GLSL in a shader
may: be flushed to zero.
** If the entry point is declared with the code:DenormFlushToZero
execution mode then for the affected instuctions the denormalized
result must: be flushed to zero and the denormalized operands may: be
@@ -1000,15 +999,14 @@ point instructions:
values with smaller bit width and interpreting those values as
floating-point numbers must: be flushed to zero.
** The following core SPIR-V instructions must: respect the
code:DenormFlushToZero execution mode: code:OpSpecConstantOp (except
when the opcode is code:OpQuantizeToF16), code:OpFConvert,
code:OpFNegate, code:OpFAdd, code:OpFSub, code:OpFMul, code:OpFDiv,
code:OpFRem, code:OpFMod, code:OpVectorTimesScalar,
code:OpMatrixTimesScalar, code:OpVectorTimesMatrix,
code:OpMatrixTimesVector, code:OpMatrixTimesMatrix,
code:OpOuterProduct, code:OpDot; and the following extended
instructions for GLSL: code:Round, code:RoundEven, code:Trunc,
code:FAbs, code:Floor, code:Ceil, code:Fract, code:Radians,
code:DenormFlushToZero execution mode: code:OpSpecConstantOp (with
opcode code:OpFConvert), code:OpFConvert, code:OpFNegate, code:OpFAdd,
code:OpFSub, code:OpFMul, code:OpFDiv, code:OpFRem, code:OpFMod,
code:OpVectorTimesScalar, code:OpMatrixTimesScalar,
code:OpVectorTimesMatrix, code:OpMatrixTimesVector,
code:OpMatrixTimesMatrix, code:OpOuterProduct, code:OpDot; and the
following extended instructions for GLSL: code:Round, code:RoundEven,
code:Trunc, code:FAbs, code:Floor, code:Ceil, code:Fract, code:Radians,
code:Degrees, code:Sin, code:Cos, code:Tan, code:Asin, code:Acos,
code:Atan, code:Sinh, code:Cosh, code:Tanh, code:Asinh, code:Acosh,
code:Atanh, code:Atan2, code:Pow, code:Exp, code:Log, code:Exp2,
@@ -1018,16 +1016,12 @@ point instructions:
code:UnpackHalf2x16, code:UnpackDouble2x32, code:Length, code:Distance,
code:Cross, code:Normalize, code:FaceForward, code:Reflect,
code:Refract, code:NMin, code:NMax, code:NClamp.
Other SPIR-V instruction may: also respect the code:DenormFlushToZero
execution mode.
Other SPIR-V instructions (except those excluded above) may: also flush
denormalized values.
** The following core SPIR-V instructions must: respect the
code:DenormPreserve execution mode: code:OpPhi, code:OpSelect,
code:OpReturnValue, code:OpVectorExtractDynamic,
code:OpVectorInsertDynamic, code:OpVectorShuffle,
code:OpCompositeConstruct, code:OpCompositeExtract,
code:OpCompositeInsert, code:OpCopyObject, code:OpTranspose,
code:OpStore, code:OpSpecConstantOp, code:OpFConvert, code:OpFNegate,
code:OpFAdd, code:OpFSub, code:OpFMul, code:OpVectorTimesScalar,
code:DenormPreserve execution mode: code:OpTranspose,
code:OpSpecConstantOp, code:OpFConvert, code:OpFNegate, code:OpFAdd,
code:OpFSub, code:OpFMul, code:OpVectorTimesScalar,
code:OpMatrixTimesScalar, code:OpVectorTimesMatrix,
code:OpMatrixTimesVector, code:OpMatrixTimesMatrix,
code:OpOuterProduct, code:OpDot, code:OpFOrdEqual, code:OpFUnordEqual,
@@ -1040,11 +1034,7 @@ point instructions:
code:FMax, code:FClamp, code:FMix, code:Fma, code:PackHalf2x16,
code:PackDouble2x32, code:UnpackHalf2x16, code:UnpackDouble2x32,
code:NMin, code:NMax, code:NClamp.
This execution mode must: also be respected by code:OpLoad except for
loads from the code:Input storage class in the fragment shader stage
with the floating-point result type.
Other SPIR-V instruction may: also respect the code:DenormPreserve
execution mode.
Other SPIR-V instructions may: also preserve denorm values.
endif::VK_KHR_shader_float_controls[]

The precision of double-precision instructions is at least that of single
@@ -942,9 +942,6 @@ succeeds, which the other physical device(s) can: wait upon.
pname:deviceMask must: be a valid device mask
* [[VUID-VkAcquireNextImageInfoKHR-deviceMask-01291]]
pname:deviceMask must: not be zero
* [[VUID-VkAcquireNextImageInfoKHR-semaphore-01804]]
pname:semaphore and pname:fence must: not both be equal to
dlink:VK_NULL_HANDLE.
****

include::../../validity/structs/VkAcquireNextImageInfoKHR.txt[]
@@ -148,9 +148,31 @@ ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
The <<resources-image-format-features,format features>> of pname:image
must: contain ename:VK_FORMAT_FEATURE_TRANSFER_DST_BIT.
endif::VK_VERSION_1_1,VK_KHR_maintenance1[]
ifndef::VK_EXT_separate_stencil_usage[]
* [[VUID-vkCmdClearDepthStencilImage-image-00009]]
pname:image must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag
endif::VK_EXT_separate_stencil_usage[]
ifdef::VK_EXT_separate_stencil_usage[]
* [[VUID-vkCmdClearDepthStencilImage-pRanges-02658]]
If any element of pname:pRanges.aspect includes
ename:VK_IMAGE_ASPECT_STENCIL_BIT, and pname:image was created with
<<VkImageStencilUsageCreateInfoEXT,separate stencil usage>>,
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT must: have been included in the
slink:VkImageStencilUsageCreateInfoEXT::pname:stencilUsage used to
create pname:image
* [[VUID-vkCmdClearDepthStencilImage-pRanges-02659]]
If any element of pname:pRanges.aspect includes
ename:VK_IMAGE_ASPECT_STENCIL_BIT, and pname:image was not created with
<<VkImageStencilUsageCreateInfoEXT,separate stencil usage>>,
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT must: have been included in the
slink:VkImageCreateInfo::pname:usage used to create pname:image
* [[VUID-vkCmdClearDepthStencilImage-pRanges-02660]]
If any element of pname:pRanges.aspect includes
ename:VK_IMAGE_ASPECT_DEPTH_BIT, ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT
must: have been included in the slink:VkImageCreateInfo::pname:usage
used to create pname:image
endif::VK_EXT_separate_stencil_usage[]
* [[VUID-vkCmdClearDepthStencilImage-image-00010]]
If pname:image is non-sparse then it must: be bound completely and
contiguously to a single sname:VkDeviceMemory object
@@ -50,14 +50,48 @@ ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
* Destination images must: have ename:VK_FORMAT_FEATURE_TRANSFER_DST_BIT
in their <<resources-image-format-features,format features>>.
endif::VK_VERSION_1_1,VK_KHR_maintenance1[]
* Source images must: have been created with the
ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage bit enabled and destination
images must: have been created with the
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT usage bit enabled.
* Source buffers must: have been created with the
ename:VK_BUFFER_USAGE_TRANSFER_SRC_BIT usage bit enabled and destination
buffers must: have been created with the
ename:VK_BUFFER_USAGE_TRANSFER_DST_BIT usage bit enabled.
ifdef::VK_EXT_separate_stencil_usage[]

This comment has been minimized.

Copy link
@krOoze

krOoze Mar 11, 2019

Contributor

Probably should be ifndef.

* Source images must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT set in
slink:VkImageCreateInfo::pname:usage
* Destination images must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT set in
slink:VkImageCreateInfo::pname:usage
endif::VK_EXT_separate_stencil_usage[]
ifdef::VK_EXT_separate_stencil_usage[]
* If the stencil aspect of source image is accessed, and the source image
was not created with <<VkImageStencilUsageCreateInfoEXT,separate stencil
usage>>, the source image must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT set in
slink:VkImageCreateInfo::pname:usage
* If the stencil aspect of destination image is accessed, and the
destination image was not created with
<<VkImageStencilUsageCreateInfoEXT,separate stencil usage>>, the
destination image must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT set in
slink:VkImageCreateInfo::pname:usage
* If the stencil aspect of source image is accessed, and the source image
was created with <<VkImageStencilUsageCreateInfoEXT,separate stencil
usage>>, the source image must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT set in
slink:VkImageStencilUsageCreateInfoEXT::pname:stencilUsage
* If the stencil aspect of destination image is accessed, and the
destination image was created with
<<VkImageStencilUsageCreateInfoEXT,separate stencil usage>>, the
destination image must: have been created with
ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT set in
slink:VkImageStencilUsageCreateInfoEXT::pname:stencilUsage
* If non-stencil aspects of a source image are accessed, the source image
must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT set
in slink:VkImageCreateInfo::pname:usage
* If non-stencil aspects of a source image are accessed, the source image
must: have been created with ename:VK_IMAGE_USAGE_TRANSFER_DST_BIT set
in slink:VkImageCreateInfo::pname:usage
endif::VK_EXT_separate_stencil_usage[]

All copy commands are treated as "`transfer`" operations for the purposes of
synchronization barriers.
@@ -2096,8 +2096,8 @@ If pname:format is a block-compressed format, then pname:bufferFeatures
must: not support any features for the format.

ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
If pname:format is a multi-plane format then pname:linearTilingFeatures and
pname:optimalTilingFeatures must: not contain
If pname:format is not a multi-plane format then pname:linearTilingFeatures
and pname:optimalTilingFeatures must: not contain
ename:VK_FORMAT_FEATURE_DISJOINT_BIT.
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]

0 comments on commit 4ad4fd1

Please sign in to comment.
You can’t perform that action at this time.