[Mesa-dev] TGSI 16-bit support

[Nicolai Hähnle]

On 22.08.2017 22:39, Roland Scheidegger wrote:
> Am 22.08.2017 um 19:10 schrieb Marek Olšák:
>> 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?
>>
> 
> Flagging instructions as 16bit doesn't look too bad to me, but I'm
> wondering if this isn't a bit problematic wrt register files. Clearly,
> this is a restriction of tgsi "everything is a 32x4 value". Doubles, of
> course, have a similar problem, but in the end they still have
> well-defined interactions with the register files, because it's defined
> what bits ultimately represent a 64bit value (at least in theory from
> tgsi's point of view, it is perfectly valid to use some 32bit
> calculations to set some reg, then just use double instructions directly
> without conversion on these values - it may not be meaningful but it is
> well defined).
> But it looks like you want to avoid to have a well-defined mapping of
> the registers to 16bit types (and with 16 bits instruction just being
> hints, I can't see how it could exist).
> Note that being able to flag instructions as HalfPrecision does not
> necessarily mean you can't have any explicit 16bit conversion
> instructions too.

Those already exist: PK2H and UP2H. Or did you have something else in mind?

More generally, there are really two use cases for this, and we need to 
be careful not to mix them up:

- transparent downgrading to 16-bit of lowp and mediump
- support for extensions that explicitly introduce 16-bit types

For lowp and mediump, the approach of just having a HalfPrecision bit on 
the instructions is probably fine.

The second case is different. I don't think there are ARB extensions for 
that yet, but there are AMD_gpu_shader_{int16,half_float} with 
explicitly 16-bit types. (There's also NV_half_float, but that's from 
earlier days without GLSL.) For those, we'd really need to provide 
exactly the required operation. No special handling of TGSI temporaries 
is needed: an f16vec4 is represented as a normal 4-component vector in 
TGSI, just that the upper 16 bits of each component are ignored.

Here's another question: What does "low precision" mean on a texture 
instruction? Are the offsets low precision or is it the output? Maybe we 
can punt on this for now -- at least GCN doesn't have low precision 
there anyway.

To sum it up:
- I think there have to be separate flags for "this is a true 16-bit 
instruction" and for "optional low precision" -- in the latter, the 
driver is responsible for on-the-fly conversion between half and full types
- Apart from potential future issues with texture instructions, I think 
the flags on instructions are fine. So the plan is fine for GLES 
lowp/mediump.

Also, we're running out of bits here, but some of those bits can be 
moved into a separate instruction flags word when the time comes.

Cheers,
Nicolai


> 
> Roland
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.