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