[Mesa-dev] [PATCH] i965/vec4: Fix the source register for indexed samplers

Matt Turner mattst88 at gmail.com
Mon Jun 8 11:00:50 PDT 2015


On Thu, Jun 4, 2015 at 5:59 AM, Neil Roberts <neil at linux.intel.com> wrote:
> Matt Turner <mattst88 at gmail.com> writes:
>
>> I don't know why I was confused by this patch -- after arriving at the
>> same conclusion independently I see that all of the analysis I needed
>> was right there.
>
> Yes sorry, I probably didn't explain it very well. Your explanation is a
> lot clearer.
>
>> To sum up, vec4_visitor::visit(ir_texture *) doesn't set the texture
>> operation's src0 -- it's left as BAD_FILE, which when translated into
>> a brw_reg gives the null register. In brw_SAMPLE,
>> gen6_resolve_implied_move() inserts a MOV from the inst->base_mrf and
>> sets the src0 appropriately. The indirect sampler case does not have a
>> call to gen6_resolve_implied_move(). How convoluted.
>>
>> The fs backend avoids this because the platforms that support dynamic
>> indexing of samplers (IVB+) have been converted to not use the
>> fake-MRF hack, and instead send from proper GRFs.
>>
>> Ideally, we'd convert the vec4 backend to use load_payload and
>> send-from-GRF. Even with that though, I think it would be nice to use
>> a proper MRF source but I'm not sure how much work is involved. I know
>> we have some src[i].file != MRF assertions sprinkled around that would
>> have to change at least.
>>
>>> +      if (inst->base_mrf != -1)
>>> +         gen6_resolve_implied_move(p, &src, inst->base_mrf);
>>
>> I think it maybe makes more sense to add this to
>> brw_send_indirect_message(), to make it more symmetrical with
>> brw_SAMPLE. What do you think?
>
> Yes, that probably makes sense. I was a bit reluctant to do this because
> there are other places that are calling brw_send_indirect_message and I
> wasn't entirely sure what impact the change would have on them. To be
> honest I don't think I understand the base_mrf thing very well. My
> understanding is that after Sandybridge the MRF registers don't really
> exist and you can just send from any GRF register.

Yes, prior to Ivybridge there was the MRF (message register file) that
contained registers that must be used as the sources of a SEND
instruction. IVB+ you can just SEND from GRF and in fact the MRF has
been removed entirely.

> However even on
> Sandybridge it looks like you don't necessarily have to use the base_mrf
> thing and you can just allocate a register using the normal mechanism
> but mark it as being in the MRF. Is that correct? Is base_mrf
> effectively a historical thing that was used before we could allocate
> registers directly in the MRF?

Partially. On Gen 4 and 5 you can actually specify a general register
as the source of a SEND, and the send will implicitly copy it to the
MRF -- which is useful for copying the message header from g0. In that
case base_mrf specifies first register used for the source payload,
and the MRF g0 is implicitly copied to (I think).

> If so, yes, maybe it would be nice to do
> a proper cleanup and get rid of it entirely at some point and just use
> the normal register allocation mechanism to get MRF registers.

Indeed. I expect that the implicit copy actually causes an additional
stall that wouldn't have existed had we scheduled a MOV from g0
earlier in the program. I wouldn't mind getting rid of the implicit
MOV, which would then let us get rid of base_mrf.

> I'll have another look at moving it into brw_send_indirect_message.

Thanks. I'm not really sure what the right solution is, so if you
decide this patch is good as is, that's fine with me.


More information about the mesa-dev mailing list