[Mesa-dev] [PATCH 00/22] Expand get_range in minmax_pruning, V3

[Thomas Helland]

I couple months ago i posted a series for expanding the get_range
function in minmax_pruning with support for more operations.
So I've been hacking on this during my spare time in Christmas.
I've now gotten to a point where I think this is not getting us
anywhere, and I need some opinions from other devs to prove me wrong.

As it stands only a couple of these patches yield any results,
and IMHO only the first patch is merge-material until we can
confirm that this is actually gonna give is significant improvements.
The first patch gives noticeable improvements on shader-db since
we are no longer messing up our saturate-detection.

Patches up to patch 9 are quite small, and patch 5 yeilds
some benefit one some Dungeon Defenders shaders that do max(exp, 0).
These might be merge-material to, due to their small size.
However the benefits of patch 5 could easily be had with
a 10-line patch to opt_algebraic, and that's the only one showing
any benefit on my collection of shaders.

Patches 10-19 take on more complexity, with no apparent benefit.
I feel theres not adequate return on investement for the code to be 
sitting around bloating the codebase.

The last three patches are RFC only, as we at least need to rename
the file to something more generic before merging them.

There is still room for improvement, but I'm not sure its worth it.
Maybe someone can do a shader-db run that proves me wrong?
My shader-db is dominated by TF2, DOTA2, Portal,
Brutal Legend and Dungeon Defenders. Maybe non-Source-engine
games show some benefit from this series?

I'm not comfortable with how this might mess up our shaders.
It gets hard to verify that things end up complying to spec,
and that we are not doing something wrong.
Some lerp-instructions got removed in Brutal Legend
(it could be guaranteed that the operation would be saturated to 1),
and while I could tell it was likely that the pass was doing the
right thing, it was not easily confirmable. This worries me.

IMHO we need to do better for this to be worth it.
I added a print to the get_range function to gather some stats:
2 million calls are made to get_range on my shader-db run.
500'000 of these are expressions, 2'000 of these are unsupported.
350'000 of these are constants.
So our coverage in get_range is less than 50%.
Is there anything more we could get/know the range of?

Thomas Helland (22):
  glsl: Reorder optimization-passes
  glsl: Move common code to ir_constant_util.h
  glsl: Add a IS_CONSTANT macro
  glsl: Change to using switch-case in get_range
  glsl: Add sqrt, rsq, exp, exp2 to get_range
  glsl: Add sin, cos and sign to get_range
  glsl: Add saturate to get_range
  glsl: Add abs to get_range
  glsl: Add ir_unop_neg to get_range
  glsl: Add ir_binop_add to get_range
  glsl: Add ir_binop_mul to get_range
  glsl: Add ir_binop_sub to get_range
  glsl: Add ir_binop_pow to get_range
  glsl: Add ir_triop_fma to get_range
  glsl: Add ir_triop_lrp to get_range
  glsl: Add ir_binop_dot to get_range
  glsl: Add log and log2 to get_range
  glsl: Add ir_unop_rcp to get_range
  glsl: Add a saturate range optimization
  glsl: Optimize some cases of undefined behaviour.
  glsl: Add a range based comparison opt-pass
  glsl: Remove useless abs based on range analysis

 src/glsl/glsl_parser_extras.cpp |   2 +-
 src/glsl/ir_constant_util.h     | 110 +++++++++
 src/glsl/opt_algebraic.cpp      |  93 +-------
 src/glsl/opt_minmax.cpp         | 495 ++++++++++++++++++++++++++++++++++++++--
 4 files changed, 589 insertions(+), 111 deletions(-)
 create mode 100644 src/glsl/ir_constant_util.h

-- 
2.2.1