[Mesa-dev] [PATCH 1/8] nir: add varying array splitting pass
Nicolai Hähnle
nhaehnle at gmail.com
Wed Nov 29 11:27:30 UTC 2017
On 29.11.2017 12:20, Timothy Arceri wrote:
> On 29/11/17 21:47, Nicolai Hähnle wrote:
>> On 21.11.2017 04:28, Timothy Arceri wrote:
>>> + nir_ssa_dest_init(&element_intr->instr, &element_intr->dest,
>>> + intr->num_components,
>>> intr->dest.ssa.bit_size, NULL);
>>> +
>>> + if (intr->intrinsic == nir_intrinsic_interp_var_at_offset ||
>>> + intr->intrinsic == nir_intrinsic_interp_var_at_sample)
>>> + nir_src_copy(element_intr->src, intr->src,
>>> &element_intr->instr);
>>
>> &element_int->src[0], &intr->src[0] for clarity, I think.
?
>>> +
>>> + nir_ssa_def_rewrite_uses(&intr->dest.ssa,
>>> + nir_src_for_ssa(&element_intr->dest.ssa));
>>> + } else {
>>> + nir_intrinsic_set_write_mask(element_intr,
>>> nir_intrinsic_write_mask(intr));
>>> + element_intr->src[0] = intr->src[0];
>>
>> I'm still not 100% up on my NIR, but doesn't this also need to be a
>> nir_src_copy? I think it makes a difference if there's an indirect
>> access involved.
>
> We don't split indirects so it shouldn't matter here.
Maybe I'm reading this wrong, but AFAIU this would be for indirects in
the source of a nir_intrinsic_store_var. So, storing to a non-indirect
output variable, but taking a value from an indirect access to e.g. a
temporary array. Those could still exist, right?
(And even if they can't it might be good to use nir_src_copy anyway for
defensive programming.)
Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
More information about the mesa-dev
mailing list