[Mesa-dev] [PATCH 2/3] radeonsi: implement PK2H and UP2H opcodes

[Marek Olšák]

On Wed, Feb 3, 2016 at 5:37 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 03.02.2016 um 10:38 schrieb Michel Dänzer:
>> On 03.02.2016 18:29, Marek Olšák wrote:
>>> On Wed, Feb 3, 2016 at 10:19 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>>> On 03.02.2016 05:15, Marek Olšák wrote:
>>>>> On Sat, Jan 30, 2016 at 12:46 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>>>
>>>>>> Based on a gallivm patch by Ilia Mirkin.
>>>>>>
>>>>>> +8 piglit regressions due to precision issues
>>>>
>>>> You're saying this patch causes 8 piglit tests to fail? What are the
>>>> benefits we get in exchange for that?
>>>
>>> The tests are too strict and llvmpipe allegedly fails them too.
>>
>> Allegedly? You can easily test that. :)
> That's not so easy. I'm not even entirely sure they are really too strict.
> The glsl wording leaves something to be desired, with things such as
> "rounding mode is undefined" but yet it requires at least some
> operations to be "correctly rounded".
> FWIW the arb_shader_packing tests require either round-to-nearest-even
> or round-to-nearest-trunc (both with rounding not representable finite
> values to infinity), whereas llvmpipe does just trunc (which comes with
> round-to-max-finite). (There's also the question about fp16 denorms -
> llvmpipe will flush them to zero for pack, but handle them on unpack,
> again glsl doesn't really say anything about that...). However, I wasn't
> brave enough to actually enable it for llvmpipe at least for now...

A simple test that checks if the results are within reasonable bounds
should be enough in my opinion. We can't change the behavior of the
hardware instructions anyway.

The current radeonsi setting for fp16, fp32, and fp64 is:
- round to nearest even
- flush input and output denorms

(FLOAT_MODE in PGM registers, described in the GCN3 ISA document:
section 6.4, table 6.4, fp16 uses the fp64 setting IIRC)

Marek