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

[lkcl]

On Monday, September 16, 2019 at 5:51:20 AM UTC+8, Jacob Lifshay wrote:

> 
> 
> All of the above isn't really necessary for GPU applications, since they never tried to achieve correct-rounding in the first place, however it is definitely needed on Unix platforms, since those generally try for correctly-rounded operations and users often assume the operations are reproducible.

This really is the key differentiator between the current GPU world and what we are doing here with the Libre RISCV SoC: sitting squarely in *both* worlds and being performance, power and price competitive *in* both worlds.

I like the idea that you suggested, Mitch, and if we were doing a pure GPU only, I would go for it 100%.

The problem with changing the accuracy on a per op basis (which would be fine on a GPU) is as Jacob points out: it would not meet IEEE754.

That in turn would relegate this initiative to being a perfect candidate for a CUSTOM extension, and the conversation on isa-dev ends there.

We are not proposing a custom extension.

We are proposing a transcendental extension for use in *all* of HPC, Embedded, 3D Hybrid *and* 3D Embedded worlds (all without *any* Vectorisation being a mandatory prerequisite for any of the same) where full integration into GNU libm, python-numpy, GNU gcc and LLVM is not only desirable it is welcomed and encouraged to br upstream right across the board for the benefit of the *entire* RISCV Community.

And, in turn, I anticipate that hardware vendors come forward and begin to help with that effort for their own commercial benefit and financial gain, such that no one single vendor including ourselves has to shoulder the cost of that development and ongoing maintenance.

As a *custom* extension none of those benefits which exist through collaboration on such a shared goal would be available to either ourselves or to anyone else.

The key words there being "shared goal".

Thus we *define* the requirements strictly to meet the potential *to* share, and thus by direct implication:

* being a custom extension is not an option and is never going to be an option
* meeting IEEE754 is mandatory AND
* meeting OpenCL and Vulkan minimum requirements is mandatory AND
* having the runtime option to choose between the two is clearly necessary AND
* having separate opcodes for deaccurified versions is an option but puts pressure on the opcode space hence Zfpacc as an alternative (neat) solution.

L.