[Mesa-dev] RFC: Supporting mediump in NIR

Fri May 15 10:32:44 PDT 2015

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.
--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