[Mesa-dev] [PATCH] radeonsi: compute the absolute value before RSQ

[Roland Scheidegger]

Am 05.01.2017 um 21:50 schrieb Samuel Pitoiset:
> 
> 
> On 01/05/2017 09:44 PM, Marek Olšák wrote:
>> On Thu, Jan 5, 2017 at 9:00 PM, Roland Scheidegger
>> <sroland at vmware.com> wrote:
>>> Am 05.01.2017 um 20:43 schrieb Samuel Pitoiset:
>>>>
>>>>
>>>> On 01/05/2017 06:49 PM, Roland Scheidegger wrote:
>>>>> Meh, I'm not really a big fan of such hacks. GPUs have support for
>>>>> NaNs
>>>>> since ages, and while glsl is lenient the point stands that
>>>>> returning a
>>>>> NaN is a more correct result, so doing extra work to get a wrong
>>>>> result
>>>>> doesn't look all that great to me.
>>>>> FWIW dx10 requires NaNs as results (for both sqrt and rsq). Maybe app
>>>>> specific quirks (if said apps can't be fixed) would be better...
>>>>> But well, it's your driver, so whatever floats your boat.
>>>>
>>>> I think the main idea here is to reduce the number of bug reports when
>>>> applications use D3D-style for RSQ/SQRT instead of what GLSL spec says.
>>>
>>> Well if someone ports from d3d10, he might well expect NaNs since d3d10
>>> guarantees you get a NaN there...
>>> (That said, with d3d10 NaNs will get converted to zeros on pixel shader
>>> export if the RT isn't a float type, I don't know what mesa drivers to
>>> there.)
>>> Not saying it wouldn't make sense doing such hackery at glsl level but
>>> imho it still should be a quirk.
>>
>> It looks like closed GL drivers always apply abs before rsq, so we
>> should do so too. The GLSL compiler seems like the correct place.
> 
> IIRC, NVIDIA blob does it as well.
Ok, it's difficult to argue against that...
"Everybody is actually doing it wrong so we must follow them or we'll
see bugs..." Pretty sure this is essentially some issue coming from a
time when gpus didn't have NaNs so everybody relied on result being
non-NaN and now because all drivers do it still noone notices they still
have bugs relying on that behavior.
Anyway, I'm fine with any solution as long as the abs behavior isn't
implied by the tgsi opcode...

Roland





> 
>>
>> Marek
>>