Skip to content
Permalink
Browse files

Change log for December 3, 2018 Vulkan 1.1.95 spec update:

  * Update release number to 95.

Public Issues:

  * Fix valid usage and XML issues found in public issues 789 and 790 for
    the `VK_EXT_debug_utils` extension (public pull request 794).
  * Replace references to `VK_NV_dedicated_allocation` with links to the
    corresponding slink:slink:VkMemoryDedicatedRequirements and
    slink:slink:VkMemoryDedicatedAllocateInfo structures in the description
    of elink:VkExternalMemoryFeatureFlagBits (public issue 801).
  * Fix miscellaneous minor markup and spelling issues in
    `VK_NV_ray_tracing` extension (public pull request 860).
  * Remove "returnedonly" from XML for
    slink:VkPhysicalDeviceInlineUniformBlockFeaturesEXT and
    slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR (public issue 862).

Internal Issues:

  * Add to the description of the
    <<features-limits-maxComputeSharedMemorySize,
    pname:maxCompureSharedMemorySize>> feature to state the shared variables
    should be packed at least as tightly as std430 (internal issue 1386).
  * Fix and clarify various references to image and image view usage in
    flink:vkCmdBindShadingRateImageNV, flink:vkCmdBeginRenderPass, and
    slink:VkImageStencilUsageCreateInfoEXT (internal issue 1432).
  * Require that the slink:VkImage mipmap chain match the Android hardware
    buffer mipmap chain for slink:VkMemoryAllocateInfo (internal issue
    1479).
  * Fix the definition of slink:VkSwapchainCreateInfoKHR valid usage
    statement 01778 (Vulkan-ValidationLayers!15)
  * Fix descriptions of <<interfaces-builtin-variables-launchid,
    code:LaunchIDNV>> and <<interfaces-builtin-variables-launchsize,
    code:LaunchSizeNV>> to code:uvec3.

New Extensions:

  * `VK_KHR_shader_float16_int8`
  * `VK_KHR_shader_float_controls`
  • Loading branch information...
oddhack committed Dec 3, 2018
1 parent f5ae29c commit ef29cea94bba541fe1ec9ffc33f65af1268bacad
@@ -115,7 +115,7 @@ VERBOSE =
# ADOCOPTS options for asciidoc->HTML5 output

NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 94
PATCHVERSION = 95
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else
@@ -0,0 +1,53 @@
// Copyright (c) 2014-2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/

include::meta/VK_KHR_shader_float16_int8.txt[]

*Last Modified Date*::
2018-03-07
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- This extension interacts with `<<VK_KHR_8bit_storage>>`
- This extension interacts with `<<VK_KHR_16bit_storage>>`
- This extension interacts with `<<VK_KHR_shader_float_controls>>`
*Contributors*::
- Alexander Galazin, Arm
- Jan-Harald Fredriksen, Arm
- Jeff Bolz, NVIDIA
- Graeme Leese, Broadcom
- Daniel Rakos, AMD

=== Description

The `VK_KHR_shader_float16_int8` extension allows use of 16-bit
floating-point types and 8-bit integer types in shaders for arithmetic
operations.

It introduces two new optional features pname:shaderFloat16 and
pname:shaderInt8 which directly map to the code:Float16 and the code:Int8
SPIR-V capabilities.
The `VK_KHR_shader_float16_int8` extension also specifies precision
requirements for half-precision floating-point SPIR-V operations.
This extension doesn't enable use of 8-bit integer types or 16-bit
floating-point types in any <<interfaces-iointerfaces, shader input and
output interfaces>> and therefore doesn't supersede the
`<<VK_KHR_8bit_storage>>` or `<<VK_KHR_16bit_storage>>` extensions.

=== New Enum Constants

* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR

=== New Structures

* slink:VkPhysicalDeviceFloat16Int8FeaturesKHR

=== New Functions

* None

=== Version History
* Revision 1, 2018-03-07 (Alexander Galazin)
- Initial draft
@@ -0,0 +1,102 @@
// Copyright (c) 2014-2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/

include::meta/VK_KHR_shader_float_controls.txt[]

*Last Modified Date*::
2018-09-11
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- This extension requires
https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_float_controls.html[`SPV_KHR_float_controls`]
*Contributors*::
- Alexander Galazin, Arm
- Jan-Harald Fredriksen, Arm
- Jeff Bolz, NVIDIA
- Graeme Leese, Broadcom
- Daniel Rakos, AMD

=== Description

The `VK_KHR_shader_float_controls` extension enables efficient use of
floating-point computations through the ability to query and override the
implementation's default behavior for rounding modes, denormals, signed
zero, and infinity.

=== New Enum Constants

* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR

=== New Enums

* None

=== New Structures

* slink:VkPhysicalDeviceFloatControlsPropertiesKHR

=== New Functions

* None

=== New SPIR-V Capabilities

* <<spirvenv-capabilities-table-shaderfloatcontrols,code:DenormPreserve>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:DenormFlushToZero>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:SignedZeroInfNanPreserve>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:RoundingModeRTE>>
* <<spirvenv-capabilities-table-shaderfloatcontrols,code:RoundingModeRTZ>>

=== Issues

1) Which instructions must flush denorms?

*RESOLVED*: Only floating-point conversion, floating-point arithmetic,
floating-point relational (except code:OpIsNaN, code:OpIsInf), and
floating-point GLSL.std.450 extended instructions must flush denormals.

2) What is the denorm behavior for intermediate results?

*RESOLVED*: When a SPIR-V instruction is implemented as a sequence of other
instructions:
- in the code:DenormFlushToZero execution mode the intermediate
instructions may flush denormals, the final result of the sequence must:
not be denormal.
- in the code:DenormPreserve execution mode denormals must be preserved
throughout the whole sequence.

3) Do denorm and rounding mode controls apply to code:OpSpecConstantOp?

*RESOLVED*: Yes, except when the opcode is code:OpQuantizeToF16.

4) The SPIR-V specification says that code:OpConvertFToU and
code:OpConvertFToS unconditionally round towards zero.
Do the rounding mode controls specified through the execution modes apply to
them?

*RESOLVED*: No, these instructions unconditionally round towards zero.

5) Do any of the "Pack" GLSL.std.450 instructions count as conversion
instructions and have the rounding mode apply?

*RESOLVED*: No, only instructions listed in the section "3.32.11.
Conversion Instructions" of the SPIR-V specification count as conversion
instructions.

6) When using inf/nan-ignore mode, what is expected of code:OpIsNan and
code:OpIsInf?

*RESOLVED*: These instructions must always accurately detect inf/nan if it
is passed to them.

=== Version History

* Revision 3, 2018-09-11 (Alexander Galazin)
- Minor restructuring
* Revision 2, 2018-04-17 (Alexander Galazin)
- Added issues and resolutions
* Revision 1, 2018-04-11 (Alexander Galazin)
- Initial draft

0 comments on commit ef29cea

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