1// Copyright 2014-2021 The Khronos Group, Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_KHR_shader_float_controls.txt[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2018-09-11 11*Interactions and External Dependencies*:: 12 - Promoted to Vulkan 1.2 Core 13 - This extension requires 14 {spirv}/KHR/SPV_KHR_float_controls.html[`SPV_KHR_float_controls`] 15*IP Status*:: 16 No known IP claims. 17*Contributors*:: 18 - Alexander Galazin, Arm 19 - Jan-Harald Fredriksen, Arm 20 - Jeff Bolz, NVIDIA 21 - Graeme Leese, Broadcom 22 - Daniel Rakos, AMD 23 24=== Description 25 26The `VK_KHR_shader_float_controls` extension enables efficient use of 27floating-point computations through the ability to query and override the 28implementation's default behavior for rounding modes, denormals, signed 29zero, and infinity. 30 31=== Promotion to Vulkan 1.2 32 33All functionality in this extension is included in core Vulkan 1.2, with the 34KHR suffix omitted. 35The original type, enum and command names are still available as aliases of 36the core functionality. 37 38include::{generated}/interfaces/VK_KHR_shader_float_controls.txt[] 39 40=== New SPIR-V Capabilities 41 42 * <<spirvenv-capabilities-table-DenormPreserve,code:DenormPreserve>> 43 * <<spirvenv-capabilities-table-DenormFlushToZero,code:DenormFlushToZero>> 44 * <<spirvenv-capabilities-table-SignedZeroInfNanPreserve,code:SignedZeroInfNanPreserve>> 45 * <<spirvenv-capabilities-table-RoundingModeRTE,code:RoundingModeRTE>> 46 * <<spirvenv-capabilities-table-RoundingModeRTZ,code:RoundingModeRTZ>> 47 48=== Issues 49 501) Which instructions must flush denorms? 51 52*RESOLVED*: Only floating-point conversion, floating-point arithmetic, 53floating-point relational (except code:OpIsNaN, code:OpIsInf), and 54floating-point GLSL.std.450 extended instructions must flush denormals. 55 562) What is the denorm behavior for intermediate results? 57 58*RESOLVED*: When a SPIR-V instruction is implemented as a sequence of other 59instructions: 60 61 * in the code:DenormFlushToZero execution mode, the intermediate 62 instructions may flush denormals, the final result of the sequence must: 63 not be denormal. 64 * in the code:DenormPreserve execution mode, denormals must be preserved 65 throughout the whole sequence. 66 673) Do denorm and rounding mode controls apply to code:OpSpecConstantOp? 68 69*RESOLVED*: Yes, except when the opcode is code:OpQuantizeToF16. 70 714) The SPIR-V specification says that code:OpConvertFToU and 72code:OpConvertFToS unconditionally round towards zero. 73Do the rounding mode controls specified through the execution modes apply to 74them? 75 76*RESOLVED*: No, these instructions unconditionally round towards zero. 77 785) Do any of the "`Pack`" GLSL.std.450 instructions count as conversion 79instructions and have the rounding mode applied? 80 81*RESOLVED*: No, only instructions listed in "`section 3.32.11. 82Conversion Instructions`" of the SPIR-V specification count as conversion 83instructions. 84 856) When using inf/nan-ignore mode, what is expected of code:OpIsNan and 86code:OpIsInf? 87 88*RESOLVED*: These instructions must always accurately detect inf/nan if it 89is passed to them. 90 91 92[[VK_KHR_shader_controls_v4_incompatibility]] 93=== Version 4 API incompatibility 94 95The original versions of `VK_KHR_shader_float_controls` shipped with 96booleans named "`separateDenormSettings`" and 97"`separateRoundingModeSettings`", which at first glance could have indicated 98"`they can all be set independently, or not`". 99However the spec language as written indicated that the 32-bit value could 100always be set independently, and only the 16- and 64-bit controls needed to 101be the same if these values were ename:VK_FALSE. 102 103As a result of this slight disparity, and lack of test coverage for this 104facet of the extension, we ended up with two different behaviors in the 105wild, where some implementations worked as written, and others worked based 106on the naming. 107As these are hard limits in hardware with reasons for exposure as written, 108it was not possible to standardise on a single way to make this work within 109the existing API. 110 111No known users of this part of the extension exist in the wild, and as such 112the Vulkan WG took the unusual step of retroactively changing the once 113boolean value into a tri-state enum, breaking source compatibility. 114This was however done in such a way as to retain ABI compatibility, in case 115any code using this did exist; with the numerical values 0 and 1 retaining 116their original specified meaning, and a new value signifying the additional 117"`all need to be set together`" state. 118If any applications exist today, compiled binaries will continue to work as 119written in most cases, but will need changes before the code can be 120recompiled. 121 122 123=== Version History 124 125 * Revision 4, 2019-06-18 (Tobias Hector) 126 - Modified settings restrictions, see 127 <<VK_KHR_shader_controls_v4_incompatibility, Version 4 API 128 incompatibility>> 129 * Revision 3, 2018-09-11 (Alexander Galazin) 130 - Minor restructuring 131 * Revision 2, 2018-04-17 (Alexander Galazin) 132 - Added issues and resolutions 133 * Revision 1, 2018-04-11 (Alexander Galazin) 134 - Initial draft 135