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

[Matt Turner]

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.

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?

(And thanks to Chad for writing a significantly better quality test
than what I found from Khronos)