Safe Haskell | None |
---|---|
Language | Haskell2010 |
Name
VK_KHR_spirv_1_4 - device extension
VK_KHR_spirv_1_4
- Name String
VK_KHR_spirv_1_4
- Extension Type
- Device extension
- Registered Extension Number
- 237
- Revision
- 1
- Extension and Version Dependencies
- Requires Vulkan 1.1
- Requires
VK_KHR_shader_float_controls
- Deprecation state
- Promoted to Vulkan 1.2
- Contact
Other Extension Metadata
- Last Modified Date
- 2019-04-01
- IP Status
- No known IP claims.
- Interactions and External Dependencies
- Requires SPIR-V 1.4.
- Promoted to Vulkan 1.2 Core
- Contributors
- Alexander Galazin, Arm
- David Neto, Google
- Jesse Hall, Google
- John Kessenich, Google
- Neil Henning, AMD
- Tom Olson, Arm
Description
This extension allows the use of SPIR-V 1.4 shader modules. SPIR-V 1.4’s new features primarily make it an easier target for compilers from high-level languages, rather than exposing new hardware functionality.
SPIR-V 1.4 incorporates features that are also available separately as
extensions. SPIR-V 1.4 shader modules do not need to enable those
extensions with the OpExtension
opcode, since they are integral parts
of SPIR-V 1.4.
SPIR-V 1.4 introduces new floating point execution mode capabilities,
also available via SPV_KHR_float_controls
. Implementations are not
required to support all of these new capabilities; support can be
queried using
PhysicalDeviceFloatControlsPropertiesKHR
from the VK_KHR_shader_float_controls
extension.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
Issues
- Should we have an extension specific to this SPIR-V version, or add a version-generic query for SPIR-V version? SPIR-V 1.4 doesn’t need any other API changes.
RESOLVED: Just expose SPIR-V 1.4.
Most new SPIR-V versions introduce optionally-required capabilities or
have implementation-defined limits, and would need more API and
specification changes specific to that version to make them available in
Vulkan. For example, to support the subgroup capabilities added in
SPIR-V 1.3 required introducing
PhysicalDeviceSubgroupProperties
to allow querying the supported group operation categories, maximum
supported subgroup size, etc. While we could expose the parts of a new
SPIR-V version that don’t need accompanying changes generically, we’ll
still end up writing extensions specific to each version for the
remaining parts. Thus the generic mechanism won’t reduce future
spec-writing effort. In addition, making it clear which parts of a
future version are supported by the generic mechanism and which can’t be
used without specific support would be difficult to get right ahead of
time.
- Can different stages of the same pipeline use shaders with different SPIR-V versions?
RESOLVED: Yes.
Mixing SPIR-V versions 1.0-1.3 in the same pipeline has not been disallowed, so it would be inconsistent to disallow mixing 1.4 with previous versions.. SPIR-V 1.4 does not introduce anything that should cause new difficulties here.
- Must Vulkan extensions corresponding to SPIR-V extensions that were promoted to core in 1.4 be enabled in order to use that functionality in a SPIR-V 1.4 module?
RESOLVED: No, with caveats.
The SPIR-V 1.4 module does not need to declare the SPIR-V extensions, since the functionality is now part of core, so there is no need to enable the Vulkan extension that allows SPIR-V modules to declare the SPIR-V extension. However, when the functionality that is now core in SPIR-V 1.4 is optionally supported, the query for support is provided by a Vulkan extension, and that query can only be used if the extension is enabled.
This applies to any SPIR-V version; specifically for SPIR-V 1.4 this
only applies to the functionality from SPV_KHR_float_controls
, which
was made available in Vulkan by VK_KHR_shader_float_controls
. Even
though the extension was promoted in SPIR-V 1.4, the capabilities are
still optional in implementations that support VK_KHR_spirv_1_4
.
A SPIR-V 1.4 module doesn’t need to enable SPV_KHR_float_controls
in
order to use the capabilities, so if the application has a priori
knowledge that the implementation supports the capabilities, it doesn’t
need to enable VK_KHR_shader_float_controls
. However, if it doesn’t
have this knowledge and has to query for support at runtime, it must
enable VK_KHR_shader_float_controls
in order to use
PhysicalDeviceFloatControlsPropertiesKHR
.
Version History
Revision 1, 2019-04-01 (Jesse Hall)
- Internal draft versions
See Also
No cross-references are available
Document Notes
For more information, see the Vulkan Specification
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.
Documentation
type KHR_SPIRV_1_4_SPEC_VERSION = 1 Source #
pattern KHR_SPIRV_1_4_SPEC_VERSION :: forall a. Integral a => a Source #
type KHR_SPIRV_1_4_EXTENSION_NAME = "VK_KHR_spirv_1_4" Source #
pattern KHR_SPIRV_1_4_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #