[Mesa-dev] [PATCH 1/6] gallium: document PK2H/UP2H

[Ilia Mirkin]

On Sun, Jan 3, 2016 at 7:51 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 03.01.2016 um 21:32 schrieb Ilia Mirkin:
>> On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>>>>> For the series (with the first point addressed either way,though a tgsi
>>>>>> exec implementation which should be trivial wouldn't hurt neither)
>>>>>> Reviewed-by: Roland Scheidegger <sroland at vmware.com>
>>>>>
>>>>> Thanks! I'll do a patch for that shortly (tgsi_exec). Unfortunately I
>>>>> won't be able to enable the cap since it will still use gallivm by
>>>>> default for vertices. I have a gallivm implementation as well, but it
>>>>> hits asserts on LLVM 3.5. I'm pretty sure I tested it at one point or
>>>>> another, but it must have been on another box with a more recent LLVM.
>>>>
>>>> Ah right. f16 conversion is pretty annoying indeed, though I'd hope the
>>>> helpers for that should work. In any case, I only really suggested that
>>>> because I'd thought it would be trivial, so if it's not I don't consider
>>>> that important...
>>>
>>> I'll send it out as a separate series, including my (semi?) broken
>>> gallivm impl and leave it to you to fix it if you care, or ignore if
>>> you don't. (I already have it, so might as well...) I understand
>>> neither how LLVM works, nor how gallivm uses LLVM, which isn't a great
>>> combination :)
>>
>> And of course the piglits expect out-of-bounds numbers to be
>> represented as infinities, instead of the clamped value
>
> This is, imho, a bug, they should allow both. Because round-towards-zero
> when converting is allowed by GL when converting floats to half, albeit
> round-to-nearest-even is preferred. And the former gets you the clamped
> values.
>
>> which is what util_float_to_half does :(
> Yep. The reason both the util and gallivm code do round-towards zero is
> that for such conversions GL allows both, but d3d10 is deeply unhappy if
> you do round-toward-nearest-even (for float to float conversions), at
> least for the clamp vs. infinite issue. As per the data conversion
> rules:
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd607323%28v=vs.85%29.aspx
> Albeit there's no specific half float conversion instructions in d3d10
> (but in d3d11), render target conversions etc. must honor these rules too.
> I suspect most hw can do both without too much fuzz (x86 f16c certainly
> can).

Take it up with people who aren't me :)

http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/lower_packing_builtins.cpp#n990

FWIW the f32 -> f16 opcode this maps to on nvc0 has the same
behaviour. Now it also has rounding mode flags which I don't set and
perhaps one of them would yield the behaviour that you're talking
about, but I don't know offhand how to get it. Curiously from the PTX
ISA docs: "Conversions to floating-point that are beyond the range of
floating-point numbers are represented with the maximum floating-point
value (IEEE 754 Inf for f32 and f64, and ~131,000 for f16)."

If you get the piglit tests changed, I guess I'll poke around.

  -ilia