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

[Jose Fonseca]

On 03/02/16 17:01, Marek Olšák wrote:
> 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.

I totally agree.

I said similar things to Roland internally.

Even if with llvmpipe there's nothing we can't change, I don't think 
it's worth our time fine tuning things that are poorly specced, or well 
specced but loosely implemented in practice.

The piglit tests should foremost veryfy that things work reasonably.

And IF we really care for precise rounding, we should have a separate 
test/subtest that checks just for that (so that nobody loses any sleep 
if it fails.)

Jose