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

[Jacob Lifshay]

On Sun, Sep 15, 2019, 11:52 'Mitchalsup' via RISC-V ISA Dev <
isa-dev at groups.riscv.org> wrote:

>
>
> Mitch Alsup
> MitchAlsup at aol.com
>
>
> -----Original Message-----
> From: lkcl <luke.leighton at gmail.com>
> To: RISC-V ISA Dev <isa-dev at groups.riscv.org>
> Cc: luke.leighton <luke.leighton at gmail.com>; libre-riscv-dev <
> libre-riscv-dev at lists.libre-riscv.org>
> Sent: Sun, Sep 15, 2019 9:23 am
> Subject: Re: [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log)
> proposal
>
> On Sunday, September 15, 2019 at 1:41:53 PM UTC+8, Jacob Lifshay wrote:
> > Note that Vulkan and RISC-V conformance are at different levels of the
> software/hardware stack: Vulkan requires API-level conformance whereas
> RISC-V requires ISA-level conformance, the Vulkan driver is free to
> translate as needed or even implement some features entirely in software,
> not everything needs to be implemented in hardware.
>
> Very important point, thank you for raising it.
>
> For the *hardware* instructions - and this includes FDIV which is
> *already* in RV - an OpenGL Khronos Compliant system would be
> performance-uncompetitive under normal market forces.
>
> Put in the bluntest and clearest terms: complying with RISCV Standards
> actually *destroys* the chances of a product's competitive commercial
> adoption in the OpenCL market!
>
> Software compliance with Khronos, the issue is moot, because (a) software
> can adapt and (b) nobody expects software to have the same performance as
> hardware.
>
> It is therefore *only* the instructions that happen to be in IEEE754,
> *and* hapoen to be in OpenCL *and* happen to have non IEEE754 accuracy
> requirements in OpenCL *and* there are market forces that compel vendors to
> want to compete on hardware acceleration....
>
> The Graphics compilers I know of take x/y and convert it into x×(1/y).
> This converts FDIV into RCP and
> FMUL. RCP is not in IEEE 754, and at this point it does not matter what
> the accuracy of FMUL ends up
> being (RCP is the accuracy killer).
>
> So, if the applications want accuracy, it uses FDIV, and if it wants
> speed, it uses RCP and FMUL.
>
> Note: RCP can be fully pipelined (easily in SP, not so easily in DP).
> FMUL is always pipelined in High Perf implementations.
>
> But this is illustrating the point I made earlier:: FDIV is required to
> have accuracy, RCP+FMUL is not.
> RCP is a different OpCode than FDIV and in this way you have avoided
> shooting yourself in the foot.
>
> Perhaps all that is needed is to describe LN2 and EXP2 as having
> graphics-useful accuracy,
> leaving LN2P1 and EXP2P1 as full accuracy instructions. In this way you
> are not having to have
> multiple instructions of the same flavor, each with different accuracies,
> but you have high speed
> versions and high accuracy versions.
>

I would argue that correctly-rounded log2 and exp2 instructions are still
necessary, since they do round differently than the hypothetical log2p1 and
exp2m1 (which are not currently being proposed, logp1 and expm1 are
instead, which are base e log and exp rather than base 2; log2p1 and exp2m1
are not in the C standard but logp1 and expm1 are).

Jacob