On Wed, Aug 23, 2017 at 10:48 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > On 23.08.2017 16:36, Ilia Mirkin wrote: >> >> On Wed, Aug 23, 2017 at 10:30 AM, Nicolai Hähnle <nhaeh...@gmail.com> >> wrote: >>> >>> On 23.08.2017 15:15, Nicolai Hähnle wrote: >>>> >>>> >>>> On 22.08.2017 19:32, Marek Olšák wrote: >>>>> >>>>> >>>>> On Tue, Aug 22, 2017 at 7:28 PM, Ilia Mirkin <imir...@alum.mit.edu> >>>>> wrote: >>>>>> >>>>>> >>>>>> How do you propose defining the semantics for e.g. loading a 16-bit >>>>>> value from a constbuf/ssbo? Would those get separate instructions? >>>>> >>>>> >>>>> >>>>> st/mesa should use UP2H, PK2H and similar opcodes for I16 and U16, and >>>>> drivers can replace them with MOV if HalfPrecision == 1. >>>> >>>> >>>> >>>> You mean, if HalfPrecision == 1 for subsequent operations? >>>> >>>> How *do* we implement this for LLVM, anyway? Downcast (fptrunc) from >>>> float >>>> to half whenever we're loading operands of a HalfPrecision == 1 >>>> instruction, >>>> and then casting (fpext) back up before storing the result? >>>> >>>> LLVM instcombine seems quite capable of seeing through that in simple >>>> code, but I worry about control flow. >>> >>> >>> >>> Thinking about this some more, having the precision a property of the >>> temporaries like Ilia suggested would probably help with emitting LLVM IR >>> that behaves well across control flow, but complicate st_glsl_to_tgsi. >>> Hard >>> to say what the tradeoff is there. >> >> >> Why would it complicate glsl_to_tgsi? At the GLSL level, it's not the >> operations that have precision, but variables. And those variables map >> to temp's... we'd have to create a separate pool of high- vs >> low-precision temps, but that's about it. > > > Well, it may not be so bad in the end. But we definitely have to be more > careful with things like temporary remapping, peephole, etc. > > Also, at least OUT variables could also be affected, right?
And IN as well. Note that some hardware has support for fp16 varyings and fp16 color outputs (the GLES end of things). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
