| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
In that case, the writes need two times the size of a 32-bit value.
We need to adjust the exec_size, so it is not breaking any hardware
rule.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
The constants could be double, and it was allocating size for float types
for the destination register of varying pull constant loads.
Then the fs_visitor::validate() will complain.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
When there is a mix of definitions of uniforms with 32-bit or 64-bit
data type sizes, the driver ends up doing misaligned access to double
based variables in the push constant buffer.
To fix this, the driver adds padding when needed in the push constant
buffer and takes it into account to avoid exceeding its limits and to
update the GRF registers to access uniform variables.
v2 (Iago):
- Renamed some variables for clarity.
- Replace the boolean array of paddings that tracked if each param was
padded by an integer array that keeps count of accumnulated padding.
This allows us to remove a couple of loops that had to compute that.
- Reworked things a bit so we can get rid of the nr_paddings field in
brw_stage_prog_data.
- Use rzalloc_array instead or ralloc_array and memset.
- Fixed wrong indentation.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
|
|
Usually, writes to a subreg_offset > 0 would also have a stride > 1
and we would recognize them as partial, however, there is one case
where this does not happen, that is when we generate code for 64-bit
imemdiates in gen7, where we produce something like this:
mov(8) vgrf10:UD, <low 32-bit>
mov(8) vgrf10+0.4:UD, <high 32-bit>
and then we use the result with a stride of 0, as in:
mov(8) vgrf13:DF, vgrf10<0>:DF
Although we could try to avoid this issue by producing different code
for this by using writes with a stride of 2, that runs into other
problems affecting gen7 and the fact is that any instruction that
writes to a subreg_offset > 0 is a partial write so we should really
recognize them as such.
|
|
When the original instruction had a stride > 1, the combined registers
written by the split instructions won't amount to the same register space
written by the original instruction because the split instructions will
use a stride of 1. The current code assumed otherwise and computed the
number of registers written by split instructions as an equal share based
on the relation between the lowered width and the original execution size
of the instruction.
It is only after the split, when we interleave the components of the result
from the lowered instructions back into the original dst register, that the
original stride takes effect and we write all the registers specified by
the original instruction.
Just make the number of register written the same as the vgrf space we
allocate for the dst of the split instruction.
Fixes crashes in fp64 tests produced as a result of assigning incorrectly the
number of registers written by split instructions, which led to incorrect
validation of the size of the writes against the allocated vgrf space.
|
|
Since it no longer handles conversions from double to float but from
double to various other 32-bit types.
|
|
|
|
These need the same treatment as d2f, so generalize our d2f lowering to cover
these too.
|
|
|
|
|
|
Probably not needed since we fix the dst type of comparisons
automatically, but for consistency with the rest of null_reg_*
functions.
|
|
Add asserts so we remember to address this when we enable 64-bit
integer support, as suggested by Connor and Jason.
|
|
In the case of the pack opcode we are already doing the
lowering in NIR, so no need to do it here. The unpack opcode
operates on scalars, so it should not be lowered.
In the case of frexp_sig and frexp_exp, they are lowered in
lower_instructions, so we don't have to care about them.
All the remaining opcodes involve conversions from and to doubles
and are business as usual.
|
|
|
|
We need to do this late, in order to avoid partial writes during the
optimization loop.
|
|
|
|
v2: Account for the stride of the dst (Iago)
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
|
|
|
|
|
|
The destination has to have the same source as the type, or else the
simulator will complain. As a result, we need to emit a CMP that
outputs a 64-bit wide result and then do a strided MOV to pick out the
low 32 bits of each channel.
|
|
The HW has a restriction that only vertical stride may cross register
boundaries. Previously, this only mattered for SIMD16 instructions where
we needed to use the same regioning parameters as the equivalent SIMD8
instruction but double the exec size. But we need to do the same
splitting for 64-bit instructions as well as instructions with a stride
of 2 (which effectively consume 64 bits per element). Fix up the code to
do the right thing instead of special-casing SIMD16.
|
|
Work based on registers read/written instead of dispatch_width, so that
the interferences are added for 64-bit sources/destinations as well.
|
|
Uniform doubles will read two registers, in which case we need to mark
both as being live.
|
|
This makes things more consistent, and also fixes the offset calculation
for double uniforms.
|
|
v2: Do it only for uniforms (Iago)
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
|
|
|
|
When we are actually unpacking from a double that we have previously
packed from its 32-bit components we can bypass the pack operation
and source from its arguments directly.
|
|
When we are actually creating a double using values obtained from a
previous unpack operation we can bypass the unpack and source from
the original double value directly.
|
|
|
|
|
|
|
|
Similar to retype() and offset().
|
|
v2 (Sam):
- Add bitsize to brw_type_for_nir_type() in optimize_extract_to_float()
|
|
|
|
They can only be used with 1-src instructions, which practically (since
we should've constant-propagated away all 1-src instructions with 64-bit
immediates in NIR) means that they must be kept in separate MOV's and
can't be propagated.
|
|
v2 (Iago):
- Squashed bits from 'support double precission constant operands for
the implementation of 64-bit emit_load_const'.
- Do not use BRW_REGISTER_TYPE_D for all 32-bit registers since that breaks
asserts and functionality for some piglit tests. Just keep 32-bit types
untouched and add 64-bit support.
- Use DF instead of Q for 64-bit registers. Otherwise the code we generate
will use Q sometimes and DF others and we hit unwanted DF/Q conversions,
so always use DF.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Tapani Palli <tapani.palli@intel.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v2 (Iago)
- Fixup accessibility in backend_reg
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
|
|
|
