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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
