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

[Ilia Mirkin]

On Tue, Jan 24, 2017 at 2:11 PM, Matteo Bruni <matteo.mystral at gmail.com> 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.

IMHO this patch should go in irrespective of the second patch. The
IEEE behavior on multiplies is what all the other hw drivers do.
Having one driver do one thing and every other driver do another thing
is not a great situation to be in. The second patch is a nicety for
st/nine and any future GL extensions that can make use of the
functionality.

  -ilia