[Mesa-dev] RFC: Supporting mediump in NIR

[Pohjolainen, Topi]

On Fri, May 15, 2015 at 12:32:52PM -0400, Rob Clark wrote:
> On Fri, May 15, 2015 at 12:22 PM, Pohjolainen, Topi
> <topi.pohjolainen at intel.com> wrote:
> > On Fri, May 15, 2015 at 11:59:25AM -0400, Rob Clark wrote:
> >> On Fri, May 15, 2015 at 5: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.
> >> >
> >> > 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.
> >>
> >> jfwiw, I can[*] in a lot of cases have precision per operand..  for
> >> example, add a f32 + f16 with result into f32.  So having separate
> >> opcodes seems kind of funny.
> >
> > As the opcode in NIR is chosen solely based on the destination type, I
> > thought that f32 + f16 would be similar thing as int + bool producing
> > int, for example. I thought that implicit conversions would kick in.
> > And also the drivers making decisions where a conversion is really
> > needed (additional mov) or not. I have to admit though that I haven't
> > thought all the way through how and where the conversions are produced.
> 
> ahh, gotcha.. yeah, that seems like it could work.. somehow I was
> ASSuming opcode meant src and dst types (and always having some
> special mov's to convert src types) ;-)
> 
> my instruction set tends to not be very orthogonal (some groups of
> instructions can convert, some not), so letting the driver backend
> make decisions about inserting converting mov's is what I'd like to
> see..

With Intel hardware we are quite restricted also. If I'm not mistaken
we can only produce 16-bit floats with all the operands being 16-bit.
Therefore I'd like to see the decision making on conversions in the
driver also. Thanks for the feedback :)