On 24/01/2017 20:11, Matteo Bruni wrote:
2017-01-24 19:15 GMT+01:00 Ilia Mirkin <imir...@alum.mit.edu>:
On Tue, Jan 24, 2017 at 1:11 PM, Matteo Bruni <matteo.myst...@gmail.com> wrote:
2017-01-24 3:18 GMT+01:00 Ilia Mirkin <imir...@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@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
