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.
Marek
>
> On Tue, Aug 22, 2017 at 1:10 PM, Marek Olšák <mar...@gmail.com> wrote:
>> Hi,
>>
>> I'd like to discuss 16-bit float and integer support in TGSI. I'm
>> proposing this:
>>
>> struct tgsi_instruction
>> {
>> unsigned Type : 4; /* TGSI_TOKEN_TYPE_INSTRUCTION */
>> unsigned NrTokens : 8; /* UINT */
>> unsigned Opcode : 8; /* TGSI_OPCODE_ */
>> unsigned Saturate : 1; /* BOOL */
>> unsigned NumDstRegs : 2; /* UINT */
>> unsigned NumSrcRegs : 4; /* UINT */
>> unsigned Label : 1;
>> unsigned Texture : 1;
>> unsigned Memory : 1;
>> unsigned Precise : 1;
>> - unsigned Padding : 1;
>> + unsigned HalfPrecision : 1;
>> };
>>
>> There won't be any 16-bit TEMPs in TGSI, but each instruction will
>> have the HalfPrecision flag, which is a hint for drivers that they can
>> use a 16-bit opcode. Even texture, load, and store instructions can
>> set HalfPrecision, which means they can accept and return 16-bit
>> values.
>>
>> The catch is that drivers will have to insert 16-bit <-> 32-bit
>> conversions manually, because they won't be present in TGSI. The
>> advantage is that we don't have to add 200 new opcodes for the 3 new
>> 16-bit types.
>>
>> What do you think?
>>
>> Marek
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
