On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 74
> +++++++++---------------------------
> 1 file changed, 18 insertions(+), 56 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 365231e..9f303d5 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2097,28 +2097,27 @@ fs_visitor::opt_algebraic()
> bool progress = false;
>
> foreach_block_and_inst(block, fs_inst, inst, cfg) {
> - switch (inst->opcode) {
> - case BRW_OPCODE_MOV:
> - if (inst->src[0].file != IMM)
> - break;
> -
> - if (inst->saturate) {
> - if (inst->dst.type != inst->src[0].type)
> - assert(!"unimplemented: saturate mixed types");
> + /* We don't want to do any float algebraic optimizations in the backend
> + * because they aren't bit-for-bit safe and the backend doesn't know
> + * when a value is declared precise or invariant.
Does this fix anything? I have a hard time believing single-precision
floating-point addition is more or less precise on the GPU than it is
on the CPU. Perhaps modulo denorm flushing rules.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
