[Mesa-dev,v2,3/3] nir: handle double-precision in fexp2 and flog2

Submitted by Iago Toral Quiroga on May 20, 2016, 7:55 a.m.

Details

Message ID 1463730904-30731-3-git-send-email-itoral@igalia.com
State New
Headers show
Series "Series without cover letter" ( rev: 1 ) in Mesa

Not browsing as part of any series.

Commit Message

Iago Toral Quiroga May 20, 2016, 7:55 a.m.
These are not supported by the fp64 spec though, so they are not really
necessary. There are, however, other cases of opcodes that are not
supported by fp64 and where we have provied a double-precision
implementation anyway. Previous discussion in the mailing list suggested
that we might want to do these if they were easy to provide.
---

If we finally decide against this, we should probably remove double-precision
handling in sin/cos and pow too.

 src/compiler/nir/nir_opcodes.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Patch hide | download patch | download mbox

diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 15066c2..9915499 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -163,8 +163,8 @@  unop("fsat", tfloat, ("bit_size == 64 ? " +
 unop("frcp", tfloat, "bit_size == 64 ? 1.0 / src0 : 1.0f / src0")
 unop("frsq", tfloat, "bit_size == 64 ? 1.0 / sqrt(src0) : 1.0f / sqrtf(src0)")
 unop("fsqrt", tfloat, "bit_size == 64 ? sqrt(src0) : sqrtf(src0)")
-unop("fexp2", tfloat, "exp2f(src0)")
-unop("flog2", tfloat, "log2f(src0)")
+unop("fexp2", tfloat, "bit_size == 64 ? exp2(src0) : exp2f(src0)")
+unop("flog2", tfloat, "bit_size == 64 ? log2(src0) : log2f(src0)")
 unop_convert("f2i", tint32, tfloat32, "src0") # Float-to-integer conversion.
 unop_convert("f2u", tuint32, tfloat32, "src0") # Float-to-unsigned conversion
 unop_convert("d2i", tint32, tfloat64, "src0") # Double-to-integer conversion.

Comments

On Fri, May 20, 2016 at 12:55 AM, Iago Toral Quiroga <itoral@igalia.com> wrote:
> These are not supported by the fp64 spec though, so they are not really
> necessary. There are, however, other cases of opcodes that are not
> supported by fp64 and where we have provied a double-precision
> implementation anyway. Previous discussion in the mailing list suggested
> that we might want to do these if they were easy to provide.
> ---
>
> If we finally decide against this, we should probably remove double-precision
> handling in sin/cos and pow too.

Ian, Jason: I've read the other thread, but I don't understand why
we'd want these.