1// Copyright 2018-2024 The Khronos Group Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_KHR_spirv_1_4.adoc[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2019-04-01 11*IP Status*:: 12 No known IP claims. 13*Interactions and External Dependencies*:: 14 - Requires SPIR-V 1.4. 15*Contributors*:: 16 - Alexander Galazin, Arm 17 - David Neto, Google 18 - Jesse Hall, Google 19 - John Kessenich, Google 20 - Neil Henning, AMD 21 - Tom Olson, Arm 22 23=== Description 24 25This extension allows the use of SPIR-V 1.4 shader modules. 26SPIR-V 1.4's new features primarily make it an easier target for compilers 27from high-level languages, rather than exposing new hardware functionality. 28 29SPIR-V 1.4 incorporates features that are also available separately as 30extensions. 31SPIR-V 1.4 shader modules do not need to enable those extensions with the 32`OpExtension` opcode, since they are integral parts of SPIR-V 1.4. 33 34SPIR-V 1.4 introduces new floating point execution mode capabilities, also 35available via `SPV_KHR_float_controls`. 36Implementations are not required to support all of these new capabilities; 37support can be queried using 38slink:VkPhysicalDeviceFloatControlsPropertiesKHR from the 39`apiext:VK_KHR_shader_float_controls` extension. 40 41=== Promotion to Vulkan 1.2 42 43All functionality in this extension is included in core Vulkan 1.2, with the 44KHR suffix omitted. 45The original type, enum and command names are still available as aliases of 46the core functionality. 47 48include::{generated}/interfaces/VK_KHR_spirv_1_4.adoc[] 49 50=== Issues 51 521. 53Should we have an extension specific to this SPIR-V version, or add a 54version-generic query for SPIR-V version? SPIR-V 1.4 does not need any other 55API changes. 56 57*RESOLVED*: Just expose SPIR-V 1.4. 58 59Most new SPIR-V versions introduce optionally-required capabilities or have 60implementation-defined limits, and would need more API and specification 61changes specific to that version to make them available in Vulkan. 62ifdef::VK_VERSION_1_1[] 63For example, to support the subgroup capabilities added in SPIR-V 1.3 64required introducing slink:VkPhysicalDeviceSubgroupProperties to allow 65querying the supported group operation categories, maximum supported 66subgroup size, etc. 67endif::VK_VERSION_1_1[] 68While we could expose the parts of a new SPIR-V version that do not need 69accompanying changes generically, we will still end up writing extensions 70specific to each version for the remaining parts. 71Thus the generic mechanism will not reduce future spec-writing effort. 72In addition, making it clear which parts of a future version are supported 73by the generic mechanism and which cannot be used without specific support 74would be difficult to get right ahead of time. 75 762. 77Can different stages of the same pipeline use shaders with different SPIR-V 78versions? 79 80*RESOLVED*: Yes. 81 82Mixing SPIR-V versions 1.0-1.3 in the same pipeline has not been disallowed, 83so it would be inconsistent to disallow mixing 1.4 with previous versions. 84SPIR-V 1.4 does not introduce anything that should cause new difficulties 85here. 86 873. 88Must Vulkan extensions corresponding to SPIR-V extensions that were promoted 89to core in 1.4 be enabled in order to use that functionality in a SPIR-V 1.4 90module? 91 92*RESOLVED*: No, with caveats. 93 94The SPIR-V 1.4 module does not need to declare the SPIR-V extensions, since 95the functionality is now part of core, so there is no need to enable the 96Vulkan extension that allows SPIR-V modules to declare the SPIR-V extension. 97However, when the functionality that is now core in SPIR-V 1.4 is optionally 98supported, the query for support is provided by a Vulkan extension, and that 99query can only be used if the extension is enabled. 100 101This applies to any SPIR-V version; specifically for SPIR-V 1.4 this only 102applies to the functionality from `SPV_KHR_float_controls`, which was made 103available in Vulkan by `apiext:VK_KHR_shader_float_controls`. 104Even though the extension was promoted in SPIR-V 1.4, the capabilities are 105still optional in implementations that support `VK_KHR_spirv_1_4`. 106 107A SPIR-V 1.4 module does not need to enable `SPV_KHR_float_controls` in 108order to use the capabilities, so if the application has _a priori_ 109knowledge that the implementation supports the capabilities, it does not 110need to enable `apiext:VK_KHR_shader_float_controls`. 111However, if it does not have this knowledge and has to query for support at 112runtime, it must enable `apiext:VK_KHR_shader_float_controls` in order to 113use slink:VkPhysicalDeviceFloatControlsPropertiesKHR. 114 115=== Version History 116 117 * Revision 1, 2019-04-01 (Jesse Hall) 118 ** Internal draft versions 119