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 <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.

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.

Cheers,
Nicolai


Cheers,
Nicolai


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





--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to