[Mesa-dev] RFC: Supporting mediump in NIR

Fri May 15 10:56:22 PDT 2015

On Fri, May 15, 2015 at 10:32:44AM -0700, Jason Ekstrand wrote:
> Hey Topi!  Thanks for working on this!
> 
> I've been meaning to do something for fp16 and fp64 in NIR for a while
> and just haven't gotten to it.  I just sent out three "patches" laying
> out how I was intending to do it.  I put "patches" in quotes because
> they're so half-baked they barely compile.  It's what I could get
> typed up in the hour or two before breakfast.
> 
> I am not at all trying to say that the explisit types mechanism isn't
> what we want.  I'm still undecided for the moment because both
> mechanisms have their merits.  I just wanted to throw both out there
> so that we can have a proper discussion.

Initially your approach looks really tempting. I like the simplicity
and the fact that we don't need to explicitly duplicate things -
most likely we need less test cases for corner cases. I would probably
continue the discussion there.

> --Jason
> 
> On Fri, May 15, 2015 at 2:39 AM, Topi Pohjolainen
> <topi.pohjolainen at intel.com> wrote:
> > I wanted to kick-off discussion on how to support floating point
> > precision qualifiers in NIR. This is purely on optimization for
> > GLES where one can reduce the number of GPU cycles. At the moment
> > the compiler discards the qualifiers early when abstract syntax
> > tree (AST) is transformed into intermediate presentation (IR).
> >
> > Iago added the initial support to IR in order to check that the
> > stages agree on the precision. Naturally I started by rebasing his
> > work on master (I dropped the actual checking part as it didn't
> > automatically fit into master). I realized that it isn't sufficient
> > to have the precision tracked in ir_variable alone. When the IR
> > is further translated into NIR the precision is needed in ir_rvalue
> > as well when NIR decides which opcode to use.
> > Iago's patch isn't needed for the solution here afterall, I just
> > included it to for context sake.
> >
> > Now, there are number of implementation alternatives, I think, both
> > in AST/IR as well is in NIR. I thought I play with one approach to
> > provide something "real" to aid the decision making regarding the
> > architecture.
> 
> And I just sent something that's definitely not real.  It's not even "real"...
> 
> > I thought that despite fp16 (medium precision float) isn't really a
> > proper type in glsl, it would clearer if it were one internally in
> > the compiler though. I kept thinking fp64 and how I would introduce
> > that into NIR.
> > The first step was to do pretty much the same as what Dave Airlie
> > did for doubles (fp64) in the compiler frontend.
> >
> > Then in NIR I decided to introduce new opcodes for half floats
> > instead of modifying the existing float instructions to carry
> > additional information about the precision.
> >
> > I would guess that there are drivers that are not really interested
> > on this and hence we should means for the drivers to tell if the
> > precision is to be taken into account or not. One natural place
> > would be in patch number nine. This is just one example of details
> > missing in the proposal - these patches are only meant to give a
> > rough idea how the approach chosen would look like.
> >
> > Iago Toral Quiroga (1):
> >   glsl: Add tracking for GLSL precision qualifiers
> >
> > Topi Pohjolainen (15):
> >   glsl: Add half float type
> >   mesa: Add half float uniform support
> >   glsl: Add half float type generation
> >   glsl: Allow half float type to be used where-ever float is supported
> >   glsl: Add support for half floats in optimization passes
> >   glsl: Add ubo lowering support for half floats
> >   glsl: Add support for half float loop control
> >   glsl/ast: Use half float type for medium and low precisions
> >   nir: Introduce half float opcodes
> >   nir: Consider float precision when deciding between int/float
> >   nir: Consider float precision when deciding between int/float: part2
> >   nir: Consider float precision when deciding between uint/int/float
> >   nir: Consider float precision when deciding between uint/float
> >   nir: Consider float precision when deciding opcode
> >   nir: Consider float precision when deciding opcode: part 2
> >
> >  src/glsl/ast_to_hir.cpp                        |  29 ++-
> >  src/glsl/builtin_type_macros.h                 |  16 ++
> >  src/glsl/builtin_types.cpp                     |  31 +++
> >  src/glsl/glsl_types.cpp                        |  50 ++++-
> >  src/glsl/glsl_types.h                          |  29 ++-
> >  src/glsl/ir.h                                  |  13 ++
> >  src/glsl/ir_clone.cpp                          |   1 +
> >  src/glsl/ir_print_visitor.cpp                  |   1 +
> >  src/glsl/ir_validate.cpp                       |  36 ++--
> >  src/glsl/link_uniform_initializers.cpp         |   2 +
> >  src/glsl/loop_controls.cpp                     |   1 +
> >  src/glsl/lower_ubo_reference.cpp               |  12 +-
> >  src/glsl/nir/glsl_to_nir.cpp                   | 258 +++++++++++--------------
> >  src/glsl/nir/nir.h                             |   2 +
> >  src/glsl/nir/nir_constant_expressions.py       |   8 +-
> >  src/glsl/nir/nir_lower_io.c                    |   1 +
> >  src/glsl/nir/nir_opcodes.py                    |  78 +++++++-
> >  src/glsl/opt_algebraic.cpp                     |  11 +-
> >  src/glsl/opt_constant_propagation.cpp          |   1 +
> >  src/glsl/opt_minmax.cpp                        |   2 +
> >  src/mesa/drivers/dri/i965/brw_fs.cpp           |   1 +
> >  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |   1 +
> >  src/mesa/drivers/dri/i965/brw_shader.cpp       |   1 +
> >  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |   1 +
> >  src/mesa/main/uniform_query.cpp                |   5 +-
> >  src/mesa/program/ir_to_mesa.cpp                |   3 +
> >  26 files changed, 413 insertions(+), 181 deletions(-)
> >
> > --
> > 1.9.3
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev