Commit Graph

4 Commits

Author SHA1 Message Date
Marek Olšák
a052a9c277 glsl: handle int16 and uint16 types and add instructions for mediump
v2: add more changes to ir_validate.cpp

Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5002>
2020-06-02 20:01:18 +00:00
Neil Roberts
83e20139db glsl/opt_minmax: Add support for float16
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3929>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3929>
2020-03-09 16:31:08 +00:00
Timothy Arceri
1edc53a66b glsl: fix opt_minmax redundancy checks against baserange
Marking operations as redundant if they are equal to the base
range is fine when the tree structure is something like this:

        max
      /     \
     max     b
    /   \
   3    max
       /   \
      3     a

But the opt falls apart with a tree like this:

        max
     /       \
    max     max
   /   \   /   \
  3    a   b    3

The problem is that both branches are treated the same: descending in
the left branch will prune the constant, and then descending the right
branch will prune the constant there as well, because limits[0] wasn't
updated to take the change on the left branch into account, and so we
still get [3,\infty) as baserange.

In order to fix the bug we just disable the marking of redundant expressions
when they match the baserange.

NIR algebraic opt will clean up the first tree for anyway, hopefully
other backends are smart enough to do this also.

Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
2017-01-07 21:46:36 +11:00
Emil Velikov
eb63640c1d glsl: move to compiler/
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Acked-by: Jose Fonseca <jfonseca@vmware.com>
2016-01-26 16:08:33 +00:00