We ended up with 2 structures that where exactly the same, so just use
one, which happens to be the one Mesa has.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The purpose of this commit is to synchronize opcode definitions across
the gen4asm assembler and mesa.
I had to drop how mesa splits msg_control as the current assembly
language gives access the the whole msg_control field.
Recompiling the xorg and the intel driver of libva shaders doesn't show
any difference in the assembly created.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The purpose of this commit is to synchronize opcode definitions across
the gen4asm assembler and mesa.
I had to drop how mesa splits msg_control as the current assembly
language gives access the the whole msg_control field.
Recompiling the xorg and the intel driver of libva shaders doesn't show
any difference in the assembly created.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The purpose of this commit is to synchronize opcode definitions across
the gen4asm assembler and mesa.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Two changes there, a field has been renamed and one bit of padding is
now used for compressed instructions.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This involved changing dest operands to have their own structure like src
operands, as the destination writemask (which is align16-only) shares space
with register numbers in align1 mode.
This required restructuring to store source operands in a new structure rather
than being stored in instructions, as swizzle is align16-only and shares
storage with other fields for align1 mode.
These changes were not tested on real programs using swizzle.
This avoids the need for a start condition to prevent for example g1.8<0,1,0>UW
being lexed as GENREG NUMBER LANGLE etc. rather than
GENREG INTEGER DOT INTEGER LANGLE etc.
