sed -i -e 's/GLuint/unsigned/g' -e 's/GLint/int/g' \
-e 's/GLfloat/float/g' -e 's/GLubyte/uint8_t/g' \
-e 's/GLshort/int16_t/g' assembler/*.[ch]
Drop the GL types here, they don't bring anything to the table. For
instance, GLuint has no guarantee to be 32 bits, so it does not make too
much sense to use it in structure describing hardware tables and
opcodes.
Of course, some bikeshedding can be applied to use uin32_t instead, I
figured that some of the GLuint are used without size constraints, so
a sed with uint32_t did not seem the right thing to do. On top of that
initial sed, one bothered enough could change the structures with size
constraints to actually use uint32_t.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This allow us to factor out the test that checks if, when using both
predicates and conditional modifiers, we are using the same flag
register.
Also get rid of of a FIXME that we are now dealing with (the warning
mentioned above).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Like with the predicate fields before, there's no need to use the full
instruction to collect the list of options. This allows us to decouple
the list of options from a specific instruction encoding.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Right now we have duplicated code for when the option is the last in the
list or not. Put that code in a common function.
Interestingly it appears that both sides haven't been kept in sync and
that EOT and ACCWRCTRL had limitations on where they had to be in the
option list. It's fixed now!
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Rather than user a full instruction for that. Also use
set_instruction_predicate() for a case that coud not be done like that
before the refactoring (because everyone now uses the same instruction
structure).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Now that all instructions (relocatable or not) are struct
brw_program_instructions, this means we can move the relocation specific
information out the "relocatable instruction" structure. This will allow
us to share the relocation information between different types of
instructions.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This will be less typing for the refactoring to come (which is use
struct brw_program_instruction in gram.y for the type of all the
instructions).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Everything is now aligned to be able to use brw_set_src1() in the
opcode generation, so use it.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This way we ensure to have a single place where these are handled. The
immediate benefit is that now line numbers are always printed out, which
is quite handy.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Unfortunately, it's all a walk in the park. Both, internal code in the
assembler and external shaders (libva) generate registers that trigger
assertions in brw_eu_emit.c's brw_validate().
To fix all that I took the option to be able to emit warning with the -W
flag but still make the assembler generate the same opcodes.
We can fix all this, but it requires validation, something that I cannot
do right now.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Another check (that we hit if we try to use brw_set_src0()). Again,
protect it with the -W option.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The list of region restrictions in bspec do say that we can't have:
width == 1 && hstrize != 0
We do have plenty of assembly code that don't respect that behaviour. So
let's hide the warning under a -W flag (for now) while we fix things.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Now that we have locations, we can write error() and warn() functions
giving more information about where it's going wrong.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Let's generate location information about the tokens we are parsing.
This can be used to give accurate location when reporting errors and
warnings.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
There's no real need to warn when the same register is declared twice.
Currently the libva driver does do that and this warning makes other
errors really hide in a sea of warnings.
Redefining a register with different parameters is a real error though,
so we should not allow that and error out in that case.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The goal is to use brw_set_src[01](), so let's start by validating the
register we have before generating the opcode.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
A few notes:
I needed to introduce a brw context and compile structs. These are only
used to get which generation we are compiling code for, but eventually
we can use more of the infrastructure.
brw_set_dest() uses the destination register width to program the
instruction execution size.
The assembler can either take subnr in bytes or in number of elements,
so we need a resolve step when setting a brw_reg.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The goal is to use brw_set_dest(), so let's start by validating the
register we have before generating the opcode.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
One more step on the road to replacing all register-like structures by
struct brw_reg.
Two things in this commit are worth noting:
* As we are using more and more brw_reg, a lot of the field-by-field
assignments can be replaced by 1 assignment which results is a
reduction of code
* As the destination horizontal stride is now stored on 2 bits in
brw_reg, it's not possible to defer the handling of DEFAULT_DSTREGION
(aka (int)-1) when setting the destination operand. It has to be done
when parsing the region and resolve_dst_region() is a helper for that
task.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
More code simplification can be layered on top of that (by using some
brw_* helpers to create registers), that'd be for another commit.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
More code simplification can be layered on top of that (by using some
brw_* helpers to create registers), that'd be for another commit.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
It's time to start converting the emission code in gram.y to use libbrw
infrastructure. Let's start with using brw_reg for declared register.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Until now, the assembler had relocation-related fields added to struct
brw_instruction. This changes the size of the structure and break code
assuming the opcode structure is really 16 bytes, for instance the
emission code in brw_eu_emit.c.
With this commit, we build on the infrastructure that slowly emerged in
the few previous commits to add a relocatable instruction with the
needed fields.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The output of the parsing is a list of struct brw_program_instruction.
These instructions can be either GEN instructions aka struct
brw_instruction or labels. To make this more explicit we now have a type
to test to determine which instruction we are dealing with.
This will also allow to to pull the relocation bits into struct
brw_program_instruction instead of having them in the structure
representing the opcodes.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Factoring out the code from the grammar will allow us to switch to
using brw_compile in a cleaner way.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This function can only be called to resolve subreg_nr in direct mode
(there is an other function for the indirect case) and it makes no sense
to call it with an immediate operand.
Express those facts with asserts and simplify the logic.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Another step towards using struct brw_reg for source and destination
operands.
Instead of having a separate field to store the sub register number of
the address register in indirect access mode, we can reuse the subreg_nr
field that was only used for direct access so far.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
writemask_set gets in the way of switching to using struct brw_reg and
it's possible to derive it from the writemask value.
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>
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>
