[Mesa-dev] [PATCH 0/8] llvmpipe: Fixes for PowerPC/big-endian machines

[Adhemerval Zanella]

On 11/28/2012 10:44 AM, Adhemerval Zanella wrote:
> On 11/27/2012 04:28 PM, Jose Fonseca wrote:
>> ----- Original Message -----
>>> Hi all,
>>>
>>> This set of patches fixes all the llvmpipe lp_test_* for PowerPC. The
>>> first five
>>> add Altivec intrinsics that fixes all arith testcases, while the
>>> remaining one
>>> deals mainly with big-endian memory loads and shift/mask algorithms.
>>>
>>> The first three are repost of previous patches that I included just
>>> for organization.
>>>
>>> [PATCH 1/8] PowerPC: Altivec pack/unpack intrisics
>>> [PATCH 2/8] PowerPC: Altivec vector max/min intrisics
>>> [PATCH 3/8] PowerPC: Altivec vector add/sub intrisics
>>> [PATCH 4/8] PowerPC: Altivec floating-point rounding
>>> [PATCH 5/8] PowerPC: clear Altivec NJ bit
>> D3D10 spec ( http://msdn.microsoft.com/en-us/library/windows/desktop/cc308050.aspx ) states that "Denorms are flushed to sign-preserved zero on input and output of any floating-point mathematical operation.".
>>
>> So we might actually need to go back on this.
> I added this denormal handling to fix two issues I noted in PPC tests:
>
> 1. lp_test_arit:
> fract(1.40129846e-45): ref = 1.40129846e-45, out = 0, precision = -0.000000 bits, FAIL
> fract(-1.40129846e-45): ref = 0.99999994, out = 0, precision = -0.000000 bits, FAIL
> fract(5.8799997e-39): ref = 5.8799997e-39, out = 0, precision = -0.000000 bits, FAIL
>
> [...]
>
> First one is in fact related on how the Altivec fused multiplication-add is being
> generated by LLVM (the addedum is not -0.0 to preseve signal, but just 0.0) and I'll
> correct it in the backend.

My first assumption was in fact incorrect, I recheck and it is due how the rounding
is done: the floor (vrim Altivec instruction) is rounding denormals to 0 if the NJ
bit is not set (default behavior). So for these tests PPC indeed need the NJ bit set.