sync_up: Add meeting notes page for next week.

[libreriscv.git] / zfpacc_proposal.mdwn

diff --git a/zfpacc_proposal.mdwn b/zfpacc_proposal.mdwn
index 632ed10e1774112df67b4b40cc84d2e9affd9ccd..8b22582a5d984dacb72bb766a487a30045959e86 100644 (file)
--- a/zfpacc_proposal.mdwn
+++ b/zfpacc_proposal.mdwn
@@ -1,5 +1,13 @@
+
 # FP Accuracy proposal
 
+Credits:
+
+* Bruce Hoult
+* Allen Baum
+* Dan Petroski
+* Jacob Lifshay
+
 TODO: complete writeup
 
 * <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002400.html>
@@ -13,6 +21,20 @@ this proposal.  Only ULP (Unit in Last Place) of the instruction *result*
 is permitted to meet alternative accuracy requirements, whilst still
 retaining the instruction's requested format.
 
+This proposal is *only* suitable for adding pre-existing accuracy standards
+where it is clearly established, well in advance of applications being
+written that conform to that standard, that dealing with variations in
+accuracy across hardware implementations is the responsibility of the
+application writer.  This is the case for both Vulkan and OpenCL.
+
+This proposal is *not* suitable for inclusion of "de-facto" (proprietary)
+accuracy standards (historic IBM Mainframe vs Ahmdahl incompatibility)
+where there was no prior agreement or notification to applications
+writers that variations in accuracy across hardware implementations
+would occur.  In the unlikely event that they *are* ever to be included
+(n the future, rather than as a Custom Extension, then, unlike Vulkan
+and OpenCL, they must **only** be added as "bit-for-bit compatible".
+
 # Extension of FCSR
 
 Zfpacc would use some of the the reserved bits of FCSR.  It would be treated
@@ -91,6 +113,8 @@ The values for the field facc to include the following:
 | 0b100 | Vulkan  | Vulkan compliant    | 
 | 0b110 | Appx    | Machine Learning    
 
+(TODO: review alternative idea: ULP0.5, ULP1, ULP2, ULP4, ULP16)
+
 Notes: 
 
 * facc=0 to match current RISC-V behaviour, where these bits were formerly reserved and set to zero.
@@ -113,6 +137,12 @@ to allow selecting one of several accurate or fast modes:
 - fully-accurate-mode: correctly rounded in all cases
 - maybe more modes?
 
+extra mode suggestions:
+
+    it might be reasonable to add a mode saying you're prepared to accept
+    worse then 0.5 ULP accuracy, perhaps with a few options: 1, 2, 4,
+    16 or something like that.
+
 Question: should better accuracy than is requested be permitted? Example:
 Ahmdahl-370 issues.
 
@@ -136,6 +166,28 @@ Comments:
 
     <https://en.wikipedia.org/wiki/Minifloat>
 
+### function accuracy in standards (opencl, vulkan)
+
+[[resources]] for OpenCL and Vulkan
+
+Vulkan requires full ieee754 precision for all F/D instructions except for fdiv and fsqrt.
+
+<https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap40.html#spirvenv-precision-operation>
+
+Source is here:
+<https://github.com/KhronosGroup/Vulkan-Docs/blob/master/appendices/spirvenv.txt#L1172>
+
+OpenCL slightly different, suggest adding as an extra entry.
+
+<https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_Env.html#relative-error-as-ulps>
+
+Link, finds version 2.1 of opencl environment specification, table 8.4.1 however needs checking if it is the same as the above, which has "SPIRV" in it and is 2.2 not 2.1
+
+https://www.google.com/search?q=opencl+environment+specification
+
+2.1 superceded by 2.2
+<https://github.com/KhronosGroup/OpenCL-Docs/blob/master/env/numerical_compliance.asciidoc>
+
 ### Compliance
 
 Dan Petroski: