[Mesa-dev] [PATCH] gallivm: unify sin and cos implementation

[Roland Scheidegger]

Am 21.08.2013 02:05, schrieb Roland Mainz:
> On Wed, Aug 21, 2013 at 1:45 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 21.08.2013 01:28, schrieb Roland Mainz:
>>> On Wed, Aug 21, 2013 at 1:12 AM,  <sroland at vmware.com> wrote:
>>>> From: Roland Scheidegger <sroland at vmware.com>
> [snip]
>>> Can you check whether the new code supports -nan correctly, please
>>> (-nan is used by scientific software... we learned that the hard way
>>> when we had to fix this in ksh93 for Sun) ?
>>>
>>
>> This code is built to adhere to graphics apis, usually d3d10 (because it
>> tends to be more strict than opengl/glsl).
>> As such there's no rules (I think) as far as propagating "the right nan"
>> concerns, and there's no distinction really between negative/positive
>> QNaNs/SNaNs. The is_finite will catch all kind of nans (plus infs,
>> obviously), but the output will always be the same NaN in this case,
>> sign bits etc. will be lost (though IIRC sign bit, while possible with
>> nan's, doesn't really have much meaning anyway).
> 
> Erm... the issue is (as Sun learned the hard way) that programmers may
> use -nan and nan explicitly to pass error conditions down the
> arithmetic chain without "littering" the "hot codepaths" with
> if()/else (instead at the end the result is tested for -nan/nan to see
> where the code approximately failed).

Maybe this is used in some computation packages. We do not (in any
place) guarantee "proper" propagation of NaNs, so all NaN payload may be
lost at any time (not just sign bit), but it will stay a NaN. This is in
accordance with d3d10 floating point rules, it may or may not be
compatible with opencl, pretty sure it is ok with glsl (which still
states today that it is ok if NaNs aren't supported at all, though if
they are I think they are sort of expected to follow "usual" rules). The
additional overhead we'd need to do for propagating payload of NaNs
through is simply not warranted for graphics (in fact even caring about
NaNs at all is a pain in the ass).

Roland