[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal

[lkcl]

so let's do a quick recap, ratcheting the "disbelief and pissed-off-ness" 
down a notch or five, and also have the expectation that people will read 
the CRNHQ resource and bring a desire to work *together* rather than 
*against* this proposal.  a reminder:

https://www.crnhq.org/cr-kit/#power


* the proposal is based on a trigonometric and transcendental subset of the 
Industry-proven OpenCL "extended" SPIR-V opcodes, ratified by the Khronos 
Group and implemented for decades in hardware that is backed by 
multi-billion dollar Corporations such as NVidia, AMD, Intel and others.

the full list is here and (thank you to a private offline response, it is 
important to emphasise that *only* opcodes from this list are being and 
always have been part of the proposal):

https://www.khronos.org/registry/spir-v/specs/unified1/OpenCL.ExtendedInstructionSet.100.html

if evaluators and contributors to this proposal have not read that list, 
they need to do so.  half_* refers to FP16 opcodes.  fast_* refers to 
"reduced accuracy" opcodes.

* thanks to Dan's input, the "fast_*" OpenCL opcodes need *not* be added as 
separate and distinct RISC-V opcodes: a special "accuracy mode" field in 
FCSR can be flipped, and the hardware can (if it chooses to) route the 
opcode's processing to a separate, faster unit (or perform early-out on an 
existing one).

this meets the elegant "RISC" design criteria in a neat and extensible way 
that does not pollute the (pressurised) RISC-V opcode space in the truly 
dreadful way that e.g. SIMD does in other architectures.

* the proposal has been pre-vetted by extremely experienced Standards 
writers, familiar with the crucial need to "get it right first time", and 
the pre-vetting process has *already* excluded functions such as CORDIC, 
SLERP, LERP, as well as excluding user feature-requests for POSITs from 
this proposal.

we expect other participants in this process to respect the competence and 
experience of all other participants, that each of us brings something to 
the table that others might lack, and to *NOT* try to "win", "score points" 
or "make others look bad".  efforts to do so are a public embarrassment and 
undermine the chances of successful long-term adoption of RISC-V in new and 
innovative areas that require huge ongoing long-term collaboration by many 
stakeholders *including those that are not and cannot be part of the RISC-V 
Foundation*.

* there is *no* public documentation on how to go about proposing 
extensions, so it is necessary to be *patient* and *collaborative* - 
working *together* - to work out how to gain and guage the level of "trust" 
that a Standard has to have.

[dictating that process by stating, without discussion or consultation, 
"quantitative analysis is demanded" and then walking away is not going to 
work.
in particular, it fails to meet the required standard of "Reasonable" 
behaviour by Trademark Holders, thus leaving the Trademark Holders 
vulnerable to weakening of the Trademark or, if it continues persistently 
and consistently, outright invalidation.]

* power-performance and meeting pre-existing Industry Standards is the 
Absolute King of the 3D world - both in the embedded space as well as the 
high-end markets.

anything that compromises power, performance or conformance to Industry 
Standards is an AUTOMATIC fail.  this because 3D Shader Engines are 
complex, will contain Trade secrets that it is unreasonable to expect to be 
revealed, and are in *binary* form, conforming to the Vulkan API in the 
"SPIR-V" Intermediate Representation.

analysis of proprietary shader algorithms, developed by *third party 
adopters* of the Vulkan API, is both impractical, unreasonable, pointless 
and misleading.

anything that fails to meet the requirements of Vulkan (which includes 
OpenCL) is just absolutely not going to cut it.

* the amount of effort required to duplicate work that has been *already 
carried out* by the multi-billion-dollar-backed Khronos Group, to meet the 
expectation to provide "quantitative analysis" is both completely 
unreasonable and completely unnecessary.

as a proven Industry Standard, whilst blind "rubber-stamping" is clearly 
just as unacceptable, the Khronos Group's list of OpenCL opcodes *is* the 
canonical list that is required - in some form - to meet demanding industry 
expectations.

thus we need an *alternative* method of providing the expected and 
absolutely critical "trust" that has to be met.

due to the massive level of pre-existing adoption of the OpenCL opcodes and 
their *pre-existing* acceptance world-wide, through the prevalent 
world-wide use of the Vulkan API, we can effectively "bypass" the "usual" 
process of carrying out "quantitative analysis" because, quite simply, if 
that analysis does not conclude that the OpenCL opcodes be in, resulting in 
failure of Khronos Conformance tests (not RISC-V Conformance tests: 
*Khronos* Conformance tests), or compromising of power and performance, it 
doesn't matter what the academic papers say, the product *will* be a 
flat-out automatic failure.

thus, also, by the same logic, that conformance to the *Khronos* tests is a 
hard requirement, any "additions" such as POSITs, and any "nice to have" 
functions (CORDIC, triple-operand normalisation 1/(x^2+y^2+z^2) for 
example) are *also* completely pointless and have (as mentioned above), 
*already been excluded from the proposal*.


i will leave that with you for a few days to think about and evaluate, 
particularly as to how to go about participating in this process in an 
inclusive and "non-combatative" fashion where *all* of us bring our 
expertise to the table, and respect and appreciate *all* of the other 
contributors for doing so.

3D and OpenCL is a ridiculously challenging area that goes well beyond what 
an ordinary desktop, server or other "normal" CPU needs to do.  working 
together and *listening* to what all participants have to say, and 
constructively valuing and including their input, is how we meet the 
principle on which RISC-V is supposed to be founded: learning from the 
lessons of past ISA development.  *not* by one Company dominating and 
strangling the process, through its employees telling everyone how it's 
going to be.

l.