[Mesa-dev] [PATCH 1/2] nir: Add a fquantize2f16 opcode

[Jason Ekstrand]

On Wed, Jan 13, 2016 at 2:14 PM, Matt Turner <mattst88 at gmail.com> wrote:

> On Wed, Jan 13, 2016 at 1:46 PM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
> > On Wed, Jan 13, 2016 at 2:01 AM, Ian Romanick <idr at freedesktop.org>
> wrote:
> >> On 01/12/2016 05:41 PM, Matt Turner wrote:
> >> > Section 8.3.2 of the OpenCL C 2.0 spec is also relevant, but doesn't
> >> > touch directly on the issue at hand.
> >> >
> >> > I'm worried that what is specified is not implementable via a round
> >> > trip through half-precision, because it's not the behavior other
> >> > languages implement.
> >> >
> >> > If I had to guess, given the table in the IVB PRM and section 8.3.2,
> >> > out-of-range single-precision floats are converted to the
> >> > half-precision value with the largest magnitude.
> >>
> >> You are correct, we should test it to be sure what the hardware really
> >> does. This is not intended to be a performance operation. If we need to
> >> use a different, more expensive expansion to meet the requirements, we
> >> shouldn't lose any sleep over it.
> >
> >
> > I haven't looked at it in bit-for-bit detail, but I I did run it through
> a
> > set of tests which explicitly hits denorms and the out-of-bounds cases in
> > both directions.  The tests seem to indicate that the hardware does what
> the
> > opcode claims.
>
> I checked out the tests you mention, and none of the cases touch on
> what I'm saying (and this has nothing to do with denormal values). Let
> me explain again.
>

Right.  Thanks for looking at it.  I guess it only checks the explicit
infinity case.


> The largest representable value in half-precision is
>
>    65504 == 2.0**15 * (1.0 + 1023.0 / 2.0**10)
>
> and the distance between representable integers at this range is 32.
> Converting 65505.0f through 65519.0f (i.e., one less than half the
> interval more than the largest representable value) to half-precision
> should round to 65504.0. 65520.0f and larger should round to infinity.
>
> This is what piglit tests
> (generated_tests/gen_builtin_packing_tests.py) and since we pass those
> tests I believe this is what the hardware does.
>
> This is, unfortunately, *not* what the documentation you've cited
> says. I expect that that's an oversight more than intentional
> behavior. Maybe tomorrow we can figure out how to submit changes to
> the spec and test suite?
>

Yeah, we can look at that tomorrow.  The objective of the opcode is to get
the behavior that Ian mentioned where if you sprinkle enough of them in,
you can emulate half-float precision.  What happens if you do FLOAT_MAX +
FLOAT_MAX?  Maybe infinity is what's wanted.  If that's the case, then
we'll have to do some sort of absolute value range-check.  It doesn't have
to be efficient.
--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20160113/f8bb1f53/attachment.html>