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

[lkcl]

On Friday, August 9, 2019 at 3:09:26 AM UTC+8, Allen Baum wrote:
> Regarding the statement:
>   As with frm, an implementation can choose to support any permutation of dynamic fam-instruction pairs. 
> It will illegal-instruction trap upon executing an unsupported fam-instruction pair.
> Putting my compliance hat on (I have to do that a lot), this works only if 
>  - the reference model is capable of being configured to trapon any permutation of illegal opcodes, OR 
>  - the compliance framework can load and properly execute abitrary (vendor supplied) emulation routines 
>  -- and they get exactly the same answer as the reference model.
> 
> 
> 
> This is all mot if you don't want to use the RISC-V trademark, or the platform doesn't requirement whatever is non-compliant, of course (which isn't flippant - its then a custom extension that may work perfectly well for some custom appllication).

Absolutely, agreed.

The weird thing here is that Zftrans/Ztrig*/Zfacc are for a wide and diverse range of implementors, covering:

* Hybrid CPU/GPUs. Aside from the Libre RISCV SoC, Pixilica's well attended SIGGRAPH 2019 BoF was a Hybrid proposal that had a huge amount of interest, because of the flexibility

https://s2019.siggraph.org/presentation/?id=bof_191&sess=sess590

Here, paradoxically, both IEEE754 compliance *and* Khronos conformance are required in order to meet customer expectations.

Just these requirements alone - the fact that the compiler toolchains (and software libraries such as GNU libm) will have enormous public distribution - excludes them from "custom" status.

* UNIX platform only.  This platform ends up indirectly benefitting from a speed boost on hardware that has support for the proposed Zf exts.

* Low power low performance cost sensitive embedded 3D. Typically 1024x768 resolution. Even here, implementors can benefit hugely from collaboration and industry wide standardisation.

Again, even in Embedded 3D, "custom" ie not appropriate as it sends the wrong message. They will use the exact same publicly available widely distributed UPSTREAM compiler toolchains and software resources as the UNIX and 3dUNIX platforms, just dialled back with Zfacc.


What does *not* need standardisation is proprietary GPUs. Mass volume products with their own proprietary binary-only-distributed implementation of OpenGL, Vulkan, and OpenCL.

Such implementors would definitely qualify for "custom" status.

It is critical to understand that this proposal is NOT designed for their needs. They might benefit from it, however unless they come forward (with associated cheque book to cover the cost of including their needs in the proposals) I'm not going to spend time or energy on them.

I've had enough of proprietary GPUs and the adverse impact proprietary libaries has on software development, reliability and the environment [1].

L.

[1] http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develop-open-source-graphics-drivers-1649632.html