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

[Roland Scheidegger]

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

Roland