<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 9:29 AM Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, August 29, 2018 5:38:59 AM PDT Jason Ekstrand wrote:<br>
> On Wed, Aug 29, 2018 at 1:36 AM Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>><br>
> wrote:<br>
> <br>
> > On Friday, August 17, 2018 1:06:24 PM PDT Jason Ekstrand wrote:<br>
> > > ---<br>
> > >  src/intel/compiler/brw_eu_defines.h           |  3 +++<br>
> > >  src/intel/compiler/brw_fs.cpp                 |  8 ++++++<br>
> > >  src/intel/compiler/brw_fs_generator.cpp       | 26 ++++++++++++++++---<br>
> > >  src/intel/compiler/brw_fs_nir.cpp             | 26 +++++++++++++++++++<br>
> > >  .../compiler/brw_nir_lower_image_load_store.c | 15 +++++++++++<br>
> > >  src/intel/compiler/brw_shader.cpp             |  5 ++++<br>
> > >  6 files changed, 79 insertions(+), 4 deletions(-)<br>
> > ><br>
> > > diff --git a/src/intel/compiler/brw_eu_defines.h<br>
> > b/src/intel/compiler/brw_eu_defines.h<br>
> > > index 2289fc9be70..c36699d7676 100644<br>
> > > --- a/src/intel/compiler/brw_eu_defines.h<br>
> > > +++ b/src/intel/compiler/brw_eu_defines.h<br>
> > > @@ -354,6 +354,9 @@ enum opcode {<br>
> > >     SHADER_OPCODE_SAMPLEINFO,<br>
> > >     SHADER_OPCODE_SAMPLEINFO_LOGICAL,<br>
> > ><br>
> > > +   SHADER_OPCODE_IMAGE_SIZE,<br>
> > > +   SHADER_OPCODE_IMAGE_SIZE_LOGICAL,<br>
> > > +<br>
> > >     /**<br>
> > >      * Combines multiple sources of size 1 into a larger virtual GRF.<br>
> > >      * For example, parameters for a send-from-GRF message.  Or, updating<br>
> > > diff --git a/src/intel/compiler/brw_fs.cpp<br>
> > b/src/intel/compiler/brw_fs.cpp<br>
> > > index 5b87991652d..1e1954270e8 100644<br>
> > > --- a/src/intel/compiler/brw_fs.cpp<br>
> > > +++ b/src/intel/compiler/brw_fs.cpp<br>
> > > @@ -4946,6 +4946,14 @@ fs_visitor::lower_logical_sends()<br>
> > >           lower_sampler_logical_send(ibld, inst,<br>
> > SHADER_OPCODE_SAMPLEINFO);<br>
> > >           break;<br>
> > ><br>
> > > +      case SHADER_OPCODE_IMAGE_SIZE_LOGICAL:<br>
> > > +         /* Nothing needs to be done except changing the opcode and<br>
> > setting a<br>
> > > +          * message length.<br>
> > > +          */<br>
> > > +         inst->opcode = SHADER_OPCODE_IMAGE_SIZE;<br>
> > > +         inst->mlen = inst->exec_size / 8;<br>
> ><br>
> > I'm not sure it's even worth having a LOGICAL opcode for this...<br>
> > maybe just set the message length when creating it and call it a day?<br>
> ><br>
> <br>
> The problem is that it has to go through SIMD width lowering which doesn't<br>
> understand mlen.  We could make SIMD width lowering just shrink the mlen<br>
> but that's wrong for almost all opcodes.  Thoughts?<br>
<br>
Hmm.  SIMD width lowering seems a bit odd, given that the parameter is<br>
always a single immediate (LOD 0), and the result is the same for all<br>
channels (the size is the size).  Couldn't you just do it in SIMD8,<br>
and have MOVs that expand it?<br>
<br>
If we do need to go through SIMD-width lowering, then I agree, setting<br>
mlen at the end is probably best...<br></blockquote><div><br></div><div>It looks like just always doing it SIMD8 will work out fine.  I'll do that.</div><div><br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > > +         break;<br>
> > > +<br>
> > >        case SHADER_OPCODE_UNTYPED_SURFACE_READ_LOGICAL:<br>
> > >           lower_surface_logical_send(ibld, inst,<br>
> > >                                      SHADER_OPCODE_UNTYPED_SURFACE_READ,<br>
> > > diff --git a/src/intel/compiler/brw_fs_generator.cpp<br>
> > b/src/intel/compiler/brw_fs_generator.cpp<br>
> > > index e265d59ccbe..13293d7efbd 100644<br>
> > > --- a/src/intel/compiler/brw_fs_generator.cpp<br>
> > > +++ b/src/intel/compiler/brw_fs_generator.cpp<br>
> > > @@ -1017,6 +1017,9 @@ fs_generator::generate_tex(fs_inst *inst, struct<br>
> > brw_reg dst, struct brw_reg src<br>
> > >        case SHADER_OPCODE_SAMPLEINFO:<br>
> > >           msg_type = GEN6_SAMPLER_MESSAGE_SAMPLE_SAMPLEINFO;<br>
> > >           break;<br>
> > > +      case SHADER_OPCODE_IMAGE_SIZE:<br>
> > > +      msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_RESINFO;<br>
> > > +      break;<br>
> ><br>
> > Indentation here seems off.<br>
> ><br>
> <br>
> Wow.  Somehow I got tabs in there.  My .vimrc should make that almost<br>
> impossible...<br>
> <br>
> <br>
> > Maybe just add this case label above the<br>
> > existing case SHADER_OPCODE_TXS, which does the exact same thing?<br>
> ><br>
> <br>
> Sure, why not.<br>
> <br>
> <br>
> > >        default:<br>
> > >        unreachable("not reached");<br>
> > >        }<br>
> > > @@ -1126,10 +1129,20 @@ fs_generator::generate_tex(fs_inst *inst, struct<br>
> > brw_reg dst, struct brw_reg src<br>
> > >        }<br>
> > >     }<br>
> > ><br>
> > > -   uint32_t base_binding_table_index = (inst->opcode ==<br>
> > SHADER_OPCODE_TG4 ||<br>
> > > -         inst->opcode == SHADER_OPCODE_TG4_OFFSET)<br>
> > > -         ? prog_data->binding_table.gather_texture_start<br>
> > > -         : prog_data->binding_table.texture_start;<br>
> > > +   uint32_t base_binding_table_index;<br>
> > > +   switch (inst->opcode) {<br>
> > > +   case SHADER_OPCODE_TG4:<br>
> > > +   case SHADER_OPCODE_TG4_OFFSET:<br>
> > > +      base_binding_table_index =<br>
> > prog_data->binding_table.gather_texture_start;<br>
> > > +      break;<br>
> > > +   case SHADER_OPCODE_IMAGE_SIZE:<br>
> > > +      /* Image binding table indices are absolute */<br>
> ><br>
> > Uh, what?  That doesn't seem right.  Shouldn't this be<br>
> ><br>
> >       base_binding_table_index = prog_data->binding_table.image_start;<br>
> ><br>
> <br>
> No... It's dumb.  The binding table index that gets placed in the uniform<br>
> image param is an absolute binding table index.  If I move this patch after<br>
> the second-to-last patch, we should be able to avoid this mess.  Why don't<br>
> I try to do that.<br>
<br>
Oh, I see, I entirely missed how BTI was getting passed in...it is<br>
indeed coming from the uniform.  So this does seem right.<br>
</blockquote></div></div>