[libre-riscv-dev] [isa-dev] FP reciprocal sqrt extension proposal

Guy Lemieux glemieux at vectorblox.com
Thu Jul 11 22:14:27 BST 2019


Dan, I'm not talking about the original sqrt, i'm talking about rsqrt
(reciprocal).

Regular sqrt is used many many different ways.

Reciprocal sqrt adds an implicit division. Usually, it is implemented
as its own function (not by doing separate sqrt followed by divide),
often with an initial lookup table and Newton-Raphson iteration to get
the rest of the bits correct. However, if it is treated as separate
sqrt followed by divide, you can get a/sqrt(b) without doing the extra
1/sqrt(a) lookup table.

As for 1/sqrt(a+b), maybe I'll follow Andrew W's note that IEEE rules
are just weird, eg +0 and -0 and drop the suggestion. (Although, the
anarchist in me wants to say that handling those special cases needs
to be done in software anyways, so even more advantage to putting it
all in hardware!)

Guy

On Thu, Jul 11, 2019 at 1:58 PM Dan Petrisko <petrisko at cs.washington.edu> wrote:
>>
>> might there be more performance value in making it dual-operand to make better use of available read ports, eg:
>>
>> a/sqrt(b)
>>   or
>>
>> 1/sqrt(a+b)
>
>
> The FSQRT instruction in the base F extension is only single-operand.  However, from a quick skim I don't see any commentary as to why that was chosen that as opposed to something analogous to your suggestion, Guy.  Presumably, it's because the extra arithmetic complexity outweighs the wasted read port. (and it's not much of a waste, since that read can be gated).
>
> Perhaps someone who was involved in the original decision could weigh in?
>
> Best,
> Dan Petrisko
>
> On Thu, Jul 11, 2019 at 4:42 PM Guy Lemieux <glemieux at vectorblox.com> wrote:
>>
>> 1/sqrt(a) is a single-operand instruction.
>>
>> might there be more performance value in making it dual-operand to make better use of available read ports, eg:
>>
>> a/sqrt(b)
>>   or
>> 1/sqrt(a+b)
>>
>> both are common forms of usage. i suppose these could be formed by chaining, but if that’s the case there’s little need for rsqrt if you have both div and sqrt.
>>
>> guy
>>
>>
>> On Thu, Jul 11, 2019 at 10:25 AM Bill Huffman <huffman at cadence.com> wrote:
>>>
>>> Avoiding doing both a square root and a divide to get this is a
>>> worthwhile goal.   I do wonder if it's better to have a slightly looser
>>> accuracy requirement.  The instruction can be considerably faster if
>>> it's required to be within 1-ulp than if it's required to be correctly
>>> rounded.  On the other hand, that means different implementations get
>>> different answers, which is not so good.
>>>
>>>        Bill
>>>
>>> On 7/11/19 3:45 AM, Jacob Lifshay wrote:
>>> >
>>> >
>>> > I propose a Zfrsqrt extension that consists of the frsqrt.s, frsqrt.d,
>>> > frsqrt.q, and frsqrt.h instructions, where the 32-bit, 64-bit,
>>> > 128-bit, and 16-bit versions require the corresponding F, D, Q, etc.
>>> > extensions.
>>> > If only the F and Zfrsqrt extensions are supported, then only the
>>> > frsqrt.s instruction is supported.
>>> > If only the F, D, and Zfrsqrt extensions are supported, then only the
>>> > frsqrt.s and the frsqrt.d instructions are supported. Likewise for
>>> > frsqrt.q and frsqrt.h requiring the corresponding extensions enabled.
>>> >
>>> > The operation implemented by frsqrt.* is a correctly-rounded
>>> > implementation of the IEEE 754-2008 rSqrt operation, with all the
>>> > usual FP rounding modes supported.
>>> >
>>> > For the encoding, I think using an encoding similar to both the
>>> > fsqrt.* and fdiv.* encodings is a good idea, since frsqrt is similar
>>> > to both fdiv and fsqrt; Therefore, as an initial proposal, I think
>>> > using a funct7 value of 0111100 and the rest of the instruction
>>> > identical to fsqrt is a good idea, since, as far as I'm aware, that
>>> > doesn't conflict with anything currently.
>>> >
>>> > We (libre-riscv.org) are currently planning on implementing frsqrt in
>>> > our libre GPU, since frsqrt is a common operation in 3D graphics (used
>>> > for vector normalization, among other things).
>>> >
>>> > Comments, modifications, etc. welcome.
>>> >
>>> > Jacob Lifshay
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe at groups.riscv.org.
>>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/bb41761b-4fc4-f636-cf77-c0dd216d41b2%40cadence.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe at groups.riscv.org.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CALo5CZx5KmeO28yDRmX5t3QkprE0qP7wshiCE1f784La7R0HfA%40mail.gmail.com.



More information about the libre-riscv-dev mailing list