[Mesa-dev] [PATCH 1/8] nir: add varying array splitting pass
Timothy Arceri
tarceri at itsqueeze.com
Wed Nov 29 11:30:11 UTC 2017
On 29/11/17 22:27, Nicolai Hähnle wrote:
> 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.)
Sure makes sense. I'll fix both of these too. Thanks.
>
> Cheers,
> Nicolai
More information about the mesa-dev
mailing list