Problem
I am interested in portable Vulkan support for correctly-rounded floating-point divide and square-root operations.
The recently published SPV_INTEL_rounded_divide_sqrt extension appears to provide the SPIR-V functionality needed for this use case. It permits FPRoundingMode on OpFDiv and square-root instructions and specifies correctly-rounded semantics.
The extension also states that there is nothing that would prohibit its use with Shader SPIR-V.
However, this capability is not currently exposed by the Vulkan SPIR-V environment.
Use case
The primary use case is deterministic numerical computation in Vulkan compute shaders.
For example, a deterministic physics simulation may require a small number of scalar divisions inside an iterative solver to produce identical results across different GPU vendors.
Most floating-point arithmetic can already be made sufficiently deterministic using Vulkan's existing floating-point controls, but division and square root remain problematic because Vulkan's baseline accuracy requirements do not require correctly-rounded results.
Implementing these operations entirely in software using integer arithmetic is possible, but substantially more expensive and defeats the purpose of hardware floating-point support.
A per-instruction mechanism is particularly attractive because applications could request correctly-rounded behavior only for the operations where it is needed.
Questions
-
Is there any existing work to make SPV_INTEL_rounded_divide_sqrt usable from the Vulkan execution environment?
-
Is promotion of this functionality to a cross-vendor extension such as SPV_KHR_rounded_divide_sqrt being considered?
-
If not, would such a promotion be the preferred path for adding portable correctly-rounded divide and square-root functionality to Vulkan?
-
Would the SPIR-V working group prefer to retain the existing combined divide/sqrt capability, or is there value in exposing divide and square root independently for implementations where hardware support differs?
I am also preparing a Vulkan proposal describing the corresponding Vulkan feature/property exposure and would appreciate guidance on the preferred SPIR-V direction before finalizing that API.
Problem
I am interested in portable Vulkan support for correctly-rounded floating-point divide and square-root operations.
The recently published
SPV_INTEL_rounded_divide_sqrtextension appears to provide the SPIR-V functionality needed for this use case. It permitsFPRoundingModeonOpFDivand square-root instructions and specifies correctly-rounded semantics.The extension also states that there is nothing that would prohibit its use with Shader SPIR-V.
However, this capability is not currently exposed by the Vulkan SPIR-V environment.
Use case
The primary use case is deterministic numerical computation in Vulkan compute shaders.
For example, a deterministic physics simulation may require a small number of scalar divisions inside an iterative solver to produce identical results across different GPU vendors.
Most floating-point arithmetic can already be made sufficiently deterministic using Vulkan's existing floating-point controls, but division and square root remain problematic because Vulkan's baseline accuracy requirements do not require correctly-rounded results.
Implementing these operations entirely in software using integer arithmetic is possible, but substantially more expensive and defeats the purpose of hardware floating-point support.
A per-instruction mechanism is particularly attractive because applications could request correctly-rounded behavior only for the operations where it is needed.
Questions
Is there any existing work to make
SPV_INTEL_rounded_divide_sqrtusable from the Vulkan execution environment?Is promotion of this functionality to a cross-vendor extension such as
SPV_KHR_rounded_divide_sqrtbeing considered?If not, would such a promotion be the preferred path for adding portable correctly-rounded divide and square-root functionality to Vulkan?
Would the SPIR-V working group prefer to retain the existing combined divide/sqrt capability, or is there value in exposing divide and square root independently for implementations where hardware support differs?
I am also preparing a Vulkan proposal describing the corresponding Vulkan feature/property exposure and would appreciate guidance on the preferred SPIR-V direction before finalizing that API.