[Mesa-dev] TGSI 16-bit support
nhaehnle at gmail.com
Wed Aug 23 14:30:34 UTC 2017
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 <imirkin at alum.mit.edu>
>>> 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.
>>> On Tue, Aug 22, 2017 at 1:10 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> 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
>>>> 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?
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
More information about the mesa-dev