[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal
luke.leighton at gmail.com
Sun Aug 11 10:49:54 BST 2019
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:
* 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):
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
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
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
* 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
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
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
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
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.
More information about the libre-riscv-dev