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

[Ian Romanick]

On 01/12/2016 05:41 PM, Matt Turner wrote:
> On Tue, Jan 12, 2016 at 4:10 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On Tue, Jan 12, 2016 at 3:52 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>>
>>> On Tue, Jan 12, 2016 at 3:35 PM, Jason Ekstrand <jason at jlekstrand.net>
>>> wrote:
>>>> This opcode simply takes a 32-bit floating-point value and reduces its
>>>> effective precision to 16 bits.
>>>> ---
>>>
>>> What's it supposed to do for values not representable in half-precision?
>>
>>
>> If they're in-range, round.  If they're out-of-range, the appropriate
>> infinity.
> 
> Are you sure that's the behavior hardware has? And by "are you sure" I
> mean "have you tested it"
> 
> The conversion table in the f32to16 documentation in the IVB PRM says:
> 
> single precision -> half precision
> ------------------------------------
> -finite -> -finite/-denorm/-0
> +finite -> +finite/+denorm/+0
> 
>> https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpQuantizeToF16
> 
>> Quantize a floating-point value to a what is expressible by a 16-bit floating-point value.
> 
> Erf, anyway,
> 
> ... and the "convert too-large values to inf" isn't the behavior of
> other languages like C [1] (and I don't think GLSL either, but I can't
> find anything on the matter i the spec) or OpenCL C [2].

Some background may either clarify or further muddy things.

Right now applications sprinkle mediump and lowp all over the place in
GLSL ES shaders.  Many vertex shader implementations, even on mobile
devices, do everything in single precision.  Many devices will only use
f16 part of the time because some instructions may not have f16
versions.  When we finally implement f16 in the i965 driver, we'll be in
this boat too.

As a result, people think that their mediump-decorated code is fine...
until it actually runs on a device that really does mediump.  Then they
report a bug to the vendor of that hardware.  Sound like a familiar
situation?

>From this problem the OpQuantizeToF16 SPRI-V instruction was born.  The
intention is that people could compile their code in a way that mediump
gives you mediump precision on every device.  While you probably
wouldn't want to ship such code, this at least makes it possible to test
it without having to find a device that will really do native mediump
calculations all the time.

IIRC, GLSL doesn't require Inf in mediump.  I don't recall what SPRI-V
says.  I believe that GLSL allows saturating to the maximum magnitude
representable value.  What we want is for an expression tree like

    OpQuantizeToF16(OpQuantizeToF16(x) + OpQuantizeToF16(y))

to produce the same value that 'x + y' would produce in "real" f16 mediump.

The SPRI-V +/-Inf requirement doesn't completely jive with my
recollection of the discussions... but there was a lot of
back-and-forth, and it was quite a few months ago at this point.  I
think we may have picked just one possible answer instead of allowing
both choices just for consistency.  I don't have any memory whether
anyone strongly wanted the +/-Inf behavior or if it was just a coin toss.

> 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.

> [1] C99 spec, 6.3.1.5 says "If the value being converted is outside
> the range of values that can be represented, the behavior is
> undefined."
> [2] OpenCL C 2.0 spec 6.2.3.3 says to refer to C99 spec section 6.3.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>