On Mon, Jan 4, 2016 at 8:32 PM, Ian Romanick <i...@freedesktop.org> wrote: > On 01/03/2016 10:02 AM, Ilia Mirkin wrote: >> On Sun, Jan 3, 2016 at 12:33 PM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> Am 03.01.2016 um 01:37 schrieb Ilia Mirkin: >>>> Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> >>>> --- >>>> src/gallium/docs/source/tgsi.rst | 10 ++++++++-- >>>> 1 file changed, 8 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/src/gallium/docs/source/tgsi.rst >>>> b/src/gallium/docs/source/tgsi.rst >>>> index 955ece8..f69998f 100644 >>>> --- a/src/gallium/docs/source/tgsi.rst >>>> +++ b/src/gallium/docs/source/tgsi.rst >>>> @@ -458,7 +458,9 @@ while DDY is allowed to be the same for the entire 2x2 >>>> quad. >>>> >>>> .. opcode:: PK2H - Pack Two 16-bit Floats >>>> >>>> - TBD >>>> +.. math:: >>>> + >>>> + dst.x = f32\_to\_f16(src.x) | f32\_to\_f16(src.y) << 16 >>> This doesn't quite match the tgsi info description (which says that the >>> result is >>> replicated). If you don't want channel replication probably should make >>> that CHAN >>> there instead. >> >> I'll add the replication to the docs. Looks like NV_fragment_program >> also wanted this: >> >> tmp0 = VectorLoad(op0); >> /* result obtained by combining raw bits of tmp0.x, tmp0.y */ >> result.x = RawBits(tmp0.x) | (RawBits(tmp0.y) << 16); >> result.y = RawBits(tmp0.x) | (RawBits(tmp0.y) << 16); >> result.z = RawBits(tmp0.x) | (RawBits(tmp0.y) << 16); >> result.w = RawBits(tmp0.x) | (RawBits(tmp0.y) << 16); >> >> But looks like it's just packing, not actually converting. And it's >> unclear whether UP2H is converting or not... let's assume that they do >> the conversions or else this is going to be useless. > > I thought that NV_fragment_program had fp16 as a native type. You did > something like suffix the instruction with H. In that case, the pack > instruction wouldn't need to convert. Right?
Ah that explains why the spec docs don't talk about conversions. Anyways, we're not going to be adding half-width temp registers to TGSI until there's a more compelling use-case, until then I think the current docs that I pushed yesterday can probably stand :) -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
