On Mon, Nov 27, 2017 at 08:41:42PM +0200, Pohjolainen, Topi wrote: > On Mon, Nov 27, 2017 at 11:40:49AM -0800, Matt Turner wrote: > > On 11/24, Topi Pohjolainen wrote: > > > --- > > > src/compiler/glsl/ir_print_visitor.cpp | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/src/compiler/glsl/ir_print_visitor.cpp > > > b/src/compiler/glsl/ir_print_visitor.cpp > > > index ea14cdeb6c..ab9a35d73f 100644 > > > --- a/src/compiler/glsl/ir_print_visitor.cpp > > > +++ b/src/compiler/glsl/ir_print_visitor.cpp > > > @@ -482,6 +482,7 @@ void ir_print_visitor::visit(ir_constant *ir) > > > case GLSL_TYPE_UINT: fprintf(f, "%u", ir->value.u[i]); break; > > > case GLSL_TYPE_INT: fprintf(f, "%d", ir->value.i[i]); break; > > > case GLSL_TYPE_FLOAT: > > > + case GLSL_TYPE_FLOAT16: > > > > Are fp16 values stored as 32-bit floats in ir->value.f[]? That seems > > surprising. > > Right. This needs more thought I guess. In the GLSL lowering pass I'm only > changing types at the moment and the conversion of constants from 32-bits > to 16-bits later in GLSL -> NIR. See patch: > > glsl: Add support for 16-bit float constants in nir-conversion
Okay, coming back to this. At the moment there is no separate storage for 16-bit float in "union ir_constant_data". I thought about adding it but then couldn't see the added value as we might as well store 16-bit constants with 32-bit precision. They are originally 32-bit anyway - it is the lowering pass that might change the type to 16-bit. What do you think? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev