[Mesa-dev] [PATCHv3 09/20] i965/fs: Get 64-bit indirect moves working on IVB.

[Francisco Jerez]

Samuel Iglesias Gonsálvez <siglesias at igalia.com> writes:

> On Thu, 2017-02-09 at 10:16 -0800, Francisco Jerez wrote:
>> ---
>> This replaces "[PATCH v2 09/20] i965/fs: indirect addressing with
>> doubles is not supported in IVB/BYT".
>> 
>> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 27
>> ++++++++++++++++++++++++--
>>  1 file changed, 25 insertions(+), 2 deletions(-)
>> 
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> index ea4a3fe1399..0e2dbe23571 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> @@ -440,7 +440,7 @@ fs_generator::generate_mov_indirect(fs_inst
>> *inst,
>>        brw_MOV(p, dst, reg);
>>     } else {
>>        /* Prior to Broadwell, there are only 8 address registers. */
>> -      assert(inst->exec_size == 8 || devinfo->gen >= 8);
>> +      assert(inst->exec_size <= 8 || devinfo->gen >= 8);
>>  
>>        /* We use VxH indirect addressing, clobbering a0.0 through
>> a0.7. */
>>        struct brw_reg addr = vec8(brw_address_reg(0));
>> @@ -478,7 +478,30 @@ fs_generator::generate_mov_indirect(fs_inst
>> *inst,
>>         * code, using it saves us 0 instructions and would require
>> quite a bit
>>         * of case-by-case work.  It's just not worth it.
>>         */
>> -      brw_ADD(p, addr, indirect_byte_offset,
>> brw_imm_uw(imm_byte_offset));
>> +      if (devinfo->gen >= 8 || devinfo->is_haswell ||
>> type_sz(reg.type) < 8) {
>> +         brw_ADD(p, addr, indirect_byte_offset,
>> brw_imm_uw(imm_byte_offset));
>> +      } else {
>> +         /* IVB reads two address register components per channel
>> for
>> +          * indirectly addressed 64-bit sources, so we need to
>> initialize
>> +          * adjacent address components to consecutive dwords of the
>> source
>> +          * region by emitting two separate ADD instructions.  Found
>> +          * empirically.
>> +          */
>> +         assert(inst->exec_size <= 4);
>> +         brw_push_insn_state(p);
>> +         brw_set_default_exec_size(p, cvt(inst->exec_size) - 1);
>> +
>> +         brw_ADD(p, spread(addr, 2), indirect_byte_offset,
>> +                 brw_imm_uw(imm_byte_offset));
>> +         brw_inst_set_no_dd_clear(devinfo, brw_last_inst, true);
>> +
>> +         brw_ADD(p, spread(suboffset(addr, 1), 2),
>> indirect_byte_offset,
>> +                 brw_imm_uw(imm_byte_offset + 4));
>> +         brw_inst_set_no_dd_check(devinfo, brw_last_inst, true);
>> +
>> +         brw_pop_insn_state(p);
>> +      }
>> +
>
> Oh, you did this change in the generator. The solution I was developing
> last weeks was to do this in a lowering pass. Your change is better!
>

I don't think that doing it at the IR level would have worked...
MOV_INDIRECT makes assumptions about the components of the index source
being valid channel-by-channel, so you'd have to mark it as
force_writemask_all which would have brought in even more problems...

> Reviewed-by: Samuel Iglesias Gonsálvez <siglesias at igalia.com>
>
> I am going to add it to my rc3 branch.
>
> Thanks!
>
Thank you.

> Sam
>
>>        struct brw_reg ind_src = brw_VxH_indirect(0, 0);
>>  
>>        brw_inst *mov = brw_MOV(p, dst, retype(ind_src, dst.type));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170210/c2168881/attachment.sig>