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