<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 26, 2017 at 3:49 AM, Iago Toral <span dir="ltr"><<a href="mailto:itoral@igalia.com" target="_blank">itoral@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The subject line is incomplete, it misses the '64-bit types' at the<br>
end.<br></blockquote><div><br></div><div>That must be a git-send-email fail.  The commit message I have says:</div><div><br></div>Fix broadcast instruction for 64-bit values on little-core<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, 2017-10-25 at 16:25 -0700, Jason Ekstrand wrote:<br>
> We're not using broadcast for any 32-bit types right now since we<br>
                                    ^^^^^^<br>
                                    64-bit I guess<br>
> mostly<br>
> use it for emit_uniformize on 32-bit buffer indices.  However, SPIR-V<br>
> subgroups are going to need it for 64-bit so let's make it work.<br>
> ---<br>
>  src/intel/compiler/brw_eu_<wbr>emit.c | 26 ++++++++++++++++++++++++--<br>
>  1 file changed, 24 insertions(+), 2 deletions(-)<br>
><br>
> diff --git a/src/intel/compiler/brw_eu_<wbr>emit.c<br>
> b/src/intel/compiler/brw_eu_<wbr>emit.c<br>
> index a18cfa4..fae74cf 100644<br>
> --- a/src/intel/compiler/brw_eu_<wbr>emit.c<br>
> +++ b/src/intel/compiler/brw_eu_<wbr>emit.c<br>
> @@ -3430,8 +3430,30 @@ brw_broadcast(struct brw_codegen *p,<br>
>           brw_pop_insn_state(<wbr>p);<br>
>  <br>
>           /* Use indirect addressing to fetch the specified<br>
> component. */<br>
> -         brw_MOV(p, dst,<br>
> -                 retype(brw_<wbr>vec1_indirect(addr.subnr, offset),<br>
> src.type));<br>
> +         if (type_sz(src.type) > 4 &&<br>
> +             (devinfo->is_<wbr>cherryview ||<br>
> gen_device_info_is_9lp(<wbr>devinfo))) {<br>
> +            /* From the Cherryview PRM Vol 7. "Register Region<br>
> Restrictions":<br>
> +             *<br>
> +             *    "When source or destination datatype is 64b or<br>
> operation is<br>
> +             *    integer DWord multiply, indirect addressing must<br>
> not be<br>
> +             *    used."<br>
> +             *<br>
> +             * To work around both of this issue, we do two integer<br>
> MOVs<br>
> +             * insead of one 64-bit MOV.  Because no double value<br>
> should ever<br>
> +             * cross a register boundary, it's safe to use the<br>
> immediate<br>
> +             * offset in the indirect here to handle adding 4 bytes<br>
> to the<br>
> +             * offset and avoid the extra ADD to the register file.<br>
> +             */<br>
> +            brw_MOV(p, subscript(dst, BRW_REGISTER_TYPE_D, 0),<br>
> +                       <wbr>retype(brw_vec1_indirect(addr.<wbr>subnr, offset),<br>
> +                             <wbr> BRW_REGISTER_TYPE_D));<br>
> +            brw_MOV(p, subscript(dst, BRW_REGISTER_TYPE_D, 1),<br>
> +                       <wbr>retype(brw_vec1_indirect(addr.<wbr>subnr, offset +<br>
> 4),<br>
> +                             <wbr> BRW_REGISTER_TYPE_D));<br>
> +         } else {<br>
> +            brw_MOV(p, dst,<br>
> +                    retype(<wbr>brw_vec1_indirect(addr.subnr, offset),<br>
> src.type));<br>
> +         }<br>
>        } else {<br>
>           /* In SIMD4x2 mode the index can be either zero or one,<br>
> replicate it<br>
>            * to all bits of a flag register,<br>
</blockquote></div><br></div></div>