[Mesa-dev] [counter-RFC 0/3] Add a concept of a bit-size to NIR

Jason Ekstrand jason at jlekstrand.net
Fri May 15 10:26:46 PDT 2015


WARNING: This is possibly the hackiest thing I've ever sent to the list.
I've been meaning to type it up properly but have never gotten around to
it.  When Topi sent his series this morning, I decided that it would be
worth dropping my thoughts on the list so that we can have something of a
comparison.  These three patches are very skeliton but they should show
approximately where my ideas are going.

You've been warned.  Proceed at your own risk! :-)

The idea I've had kicking around my brain to handle things like fp64 in NIR
is to add a concept of "bit size" that is similar to the number of
channels.  This is distinctly different than simply adding new types but I
believe it comes with a number of advantages:

 1) Less type explosion.  Having a typeless IR is great and all, but it
    can lead to something of an explosion of types when you start to throw
    in 16-bit and 64-bit variants of everything.  To top it all off, we may
    start having to support 8, 16, and 64-bit integers and then it'll get
    really bad.

 5) You can still have explicitly sized opcodes such as fsin by simply
    setting the type to 'float32'.  If it's something more universal like
    fmul, you use the unsized 'float' type.

 2) The bit-size is baked into the register or SSA value.  This one is
    important.  One of the problems of baking the bit-size into the type is
    that now you have to solve the problem of how 64-bit types relate to
    registers and SSA values?  Do they take up 1 slot or 2?  Does a
    half-float take up half a slot?  If everything still takes up 1 slot,
    how do you know what size a register actually is?  When you bake the
    bit-size into the register or SSA value, all these questions go away
    and you're forced to use explicit packing operations and casts.

 3) The bit-size is easily ignorable.  Have a backend that can't do fp16
    but NIR is automatically giving it to you when you for mediump?  You
    can just harmlessly ignore it.  This doesn't work for fp64 or other
    integer types, but it's nice for fp16 for now.

 4) We don't have to re-write opt_algebraic to add all of the 16-bit and
    64-bit optimizations.  They come for free as long as we make nir_search
    bit-size aware.

Disadvantages:

 1) Things that used to only have to care about the instruction opcode now
    have to care about the bit-size.  For instance, the constant-folding
    stuff now has to jump through some more hoops.

 2) Dealing with bit-sizes can be confusing because it's encoded in the
    destination as well as, possibly, the type.  However, a lot of things
    will only care about one or the other so it shouldn't be a big deal.

 3) I've only compile-tested what is less than half an implementation.  I
    have no idea how all this will work out in practice.

Things left currently unresolved in the patches I sent:

 1) Do we want to have a bit_size field on various instructions or just
    determine it from the destination?  For ALU instructions, leaving it
    alone seems to work OK but it might not be as good for intrinsics.  I'm
    not really sure what I think.

 2) We need to figure out how we want to handle it in constant folding.  I
    think we can just add some stuff to the auto-gen to switch on the
    destination's bit-size and go from there.

 3) What about things where we want 16-bit and 32-bit versions but not
    64-bit?  There are a lot of things that aren't allowed for fp64 such as
    transcendentals but they may be ok for fp16.  As it stands, we would
    still need two opcodes: fsin32 and fsin16.

I'm sure thare's a lot more to throw around but this should be enough to
get us started.
--Jason

Jason Ekstrand (3):
  nir: s/nir_type_unsigned/nir_type_uint
  nir: Add explicitly sized types
  nir: Add a bit_size to nir_register and nir_ssa_def

 src/glsl/nir/glsl_to_nir.cpp             |  2 +-
 src/glsl/nir/nir.c                       |  2 +
 src/glsl/nir/nir.h                       | 24 +++++++++-
 src/glsl/nir/nir_constant_expressions.py |  4 +-
 src/glsl/nir/nir_opcodes.py              | 78 ++++++++++++++++----------------
 src/glsl/nir/nir_search.c                |  4 +-
 src/glsl/nir/nir_validate.c              | 43 ++++++++++++++++--
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp |  4 +-
 8 files changed, 110 insertions(+), 51 deletions(-)

-- 
2.4.0



More information about the mesa-dev mailing list