diff options
author | Jason Ekstrand <jason.ekstrand@intel.com> | 2016-05-05 16:38:25 -0700 |
---|---|---|
committer | Jason Ekstrand <jason.ekstrand@intel.com> | 2016-05-11 11:44:35 -0700 |
commit | f1dcc7976a17f4da7235d05dbe8adbf18d323d7d (patch) | |
tree | 6f545aa591946405f5c40198670daebde3c63733 /.mailmap | |
parent | 47f01e538ad575d3f2b02e747905e7ab9dd3a9bb (diff) | |
download | external_mesa3d-f1dcc7976a17f4da7235d05dbe8adbf18d323d7d.zip external_mesa3d-f1dcc7976a17f4da7235d05dbe8adbf18d323d7d.tar.gz external_mesa3d-f1dcc7976a17f4da7235d05dbe8adbf18d323d7d.tar.bz2 |
i965: Stop splitting fma() prior to optimization
According to the GLSL spec, if the user uses the fma() intrinsic to
generate a precise-consumed value, and you have it in your hardware, you
shouldn't split it. For a while now, we've been splitting all ffma's
up-front and then planned to fuse them later which isn't valid. Correctly
handling the GLSL behaviour fixes rendering corruptions in Tomb Raider.
The only reason why doing this possibly helped before was for ARB programs
which is handled by the previous commit.
Shader-db results on Haswell:
total instructions in shared programs: 7560300 -> 7561510 (0.02%)
instructions in affected programs: 56265 -> 57475 (2.15%)
helped: 86
HURT: 291
The only shaders in the database that are affected are from "Shadow of
Mordor" which is the first app in our database to use fma(). We could, at
some point in the future, split inexact ffma opcodes which would fix the
shader-db regressions since Shadow of Mordor doesn't ues precise. However,
this fixes a bug now and and the shader-db impact is fairly small.
Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions