On Don, 2012-11-29 at 08:45 -0800, Tom Stellard wrote: > On Tue, Nov 27, 2012 at 07:55:05PM +0100, Michel Dänzer wrote: > > diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c > > b/src/gallium/drivers/radeonsi/radeonsi_shader.c > > index d6e37ac..d5d56c4 100644 > > --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c > > +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c > > @@ -496,7 +496,11 @@ static void si_llvm_init_export_args(struct > > lp_build_tgsi_context *bld_base, > > > > LLVMInt32TypeInContext(base->gallivm->context), > > args, 2, > > LLVMReadNoneAttribute); > > - args[chan + 7] = args[chan + 5]; > > + args[chan + 7] = args[chan + 5] = > > + LLVMBuildBitCast(base->gallivm->builder, > > + args[chan + 5], > > + > > LLVMFloatTypeInContext(base->gallivm->context), > > + ""); > > } > > I think a better fix would be to change the return type of llvm.SI.packf16 > intrinsic from i32 to v2f16. This is more correct and would allow us to > use the intrinsic elsewhere if needed.
Makes sense. > This will also require a new export intrinsic to handle the packed floats, > and you'll need to add the v2f16 type to the register class definitions. Not sure about this, though. Given the various export targets / formats, I'm afraid this would result in a combinatorial explosion of export intrinsics. I wonder if it might not be better to make the export intrinsic take i32s instead (or whatever type is best for generic 32 bit values), and have the driver bitcast as appropriate. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev