Vulkan-Docs/appendices/VK_KHR_shader_float_control...

// Copyright (c) 2014-2019 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
Change log for January 05, 2019 Vulkan 1.1.97 spec update: * Update release number to 97. Public Issues: * Add a special case to the <<renderpass-compatibility, Render Pass Compatibility>> rules allowing single-subpass renderpasses to be compatible even if they have different resolve attachment references (public issue 835). * Fix the miss shader binding table record address rule in the <<shader-binding-table-indexing-rules, Miss Shaders>> section to index by code:missIndex, not code:sbtOffset (public issue 875). Internal Issues: * Add a missing anchor to the elink:VkSamplerCreateFlagBits language (internal issue 1483). * Add missing implicit valid usage include for slink:VkHdrMetadataEXT and corresponding `noautovalidity` attributes in `vk.xml` for the externally-defined metadata properties (internal issue 1514). * Remove restrictions on the `mask` parameter of SPIR-V's code:OpGroupNonUniformXor in the <<spirvenv-module-validation, Validation Rules within a Module>> appendix (internal merge request 2971). * Restore `noautovalidity` attribute for slink:VkPipelineViewportWScalingStateCreateInfoNV::pname:pViewportWScalings in `vk.xml` (internal merge request 2975). * Update copyright dates on Khronos-copyrighted files to 2019 (internal merge request 2980). New Extensions: * `VK_KHR_depth_stencil_resolve` * `VK_EXT_buffer_device_address` * `VK_EXT_memory_budget` * `VK_EXT_memory_priority` * `VK_EXT_validation_features` 2019-01-06 03:40:12 +00:00			`// Copyright (c) 2014-2019 Khronos Group. This work is licensed under a`
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` 2018-12-03 10:41:34 +00:00			`// 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`