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

[Roland Scheidegger]

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

Roland



> 
> 
>> The benefit is that we'll get v_cvt_f32_f16 and v_cvt_f16_f32 instead
>> of emulation with integer instructions. They are GLSL 4.00 intrinsics.
> 
> Sounds good. Maybe add something along those lines to the commit log,
> but either way,
> 
> Reviewed-by: Michel Dänzer <michel.daenzer at amd.com>
> 
>