[Mesa-dev] [PATCH 1/2] r600g: use ieee variants of multiplication instructions

[Axel Davy]

On 24/01/2017 20:11, Matteo Bruni wrote:
> 2017-01-24 19:15 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>:
>> On Tue, Jan 24, 2017 at 1:11 PM, Matteo Bruni <matteo.mystral at gmail.com> wrote:
>>> 2017-01-24 3:18 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>:
>>>> This matches the behavior of most other drivers, including nouveau.
>>> Doesn't this break all the applications depending on d3d9 NaN behavior
>>> (including, but not limited to, d3d9 games in Wine) on r600g?
>>>
>>> If I got this right, flipping around the two patches in this series
>>> and enabling the TGSI_PROPERTY_MUL_ZERO_WINS flag for OpenGL
>>> non-compute shaders (if that's not the case already) should avoid
>>> regressions.
>> This patch normalizes r600g wrt multiply handling with the other
>> DX10/11 hardware drivers. nv50, nvc0, si, and i965 all use the IEEE
>> behavior. I don't know for sure, but assume that nv30 and r300 have
>> the DX9 behavior natively without IEEE support.
>>
>> The next patch allows for the MUL_ZERO_WINS property to be used to get
>> the DX9 behavior, which st/nine will make use of.
> That doesn't help Wine or any "native" OpenGL application which
> happens to depend on the old behavior.
> Even if there are none of them (which doesn't sound right to me)
> applying this patch before 2/2 means that you are changing behavior
> for nine in this one patch and changing it back again with the next,
> which looks to me as something generally better avoided.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Bad apps that depend on the behaviour could be listed in drirc with a 
workaround to force them use the gl extension associated with the feature.


Yours,


Axel Davy