[Mesa-dev] [PATCH 2/2] radv: call nir_lower_io_to_temporaries for VS, GS, TES and FS

[Bas Nieuwenhuizen]

On Fri, May 25, 2018 at 12:45 PM, Timothy Arceri <tarceri at itsqueeze.com> wrote:
>
>
> On 25/05/18 20:40, Timothy Arceri wrote:
>>
>> On 25/05/18 19:57, Samuel Pitoiset wrote:
>>>
>>> On 05/25/2018 04:28 AM, Timothy Arceri wrote:
>>>>
>>>> On 25/05/18 11:24, Bas Nieuwenhuizen wrote:
>>>>>
>>>>> On Fri, May 25, 2018 at 2:25 AM, Timothy Arceri <tarceri at itsqueeze.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>  From what I recall with my testing on radeonsi this wasn't really the
>>>>>> ideal
>>>>>> thing to do. Especially when varyings arrays are accessed via and
>>>>>> indirect
>>>>>> index, register use very quickly gets out of control.
>>>>>
>>>>>
>>>>> in radv we lower all indirect accesses in nir anyway, so that doesn't
>>>>> really happen in the backend anymore.
>>>>
>>>>
>>>> Thats only for Polaris and higher though, and even then I thought that
>>>> was an LLVM bug that should eventually be fixed?
>>>
>>>
>>> I don't know, I didn't hit this potential LLVM bug.
>>
>>
>> I just mean isn't that the only reason we lower indirect access for some
>> varyings in RADV/radeonsi? Because of missing support in LLVM.
>
>
> Also if I'm recalling correctly I believe the tgsi radeonsi backend does
> something slightly better to work around that than what the NIR backend and
> RADV does.

So for Vega+ we lower indirect indexing for everything because it is
utterly broken in LLVM.

for the other GPUs  we lower locals, as large vectors + spilling =
nightmare. radeonsi solves it by explicitly putting the large arrays
in memory. That way you load only one value on an indirect deref
instead of loaidng the entire array -> doing the indirect deref ->
spilling the entire array.

>
>
>
>>
>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 23/05/18 22:31, Samuel Pitoiset wrote:
>>>>>>>
>>>>>>>
>>>>>>> Do not lower FS inputs because this moves all load_var
>>>>>>> instructions at beginning of shaders and because
>>>>>>> interp_var_at_sample (and friends) seem broken. That might
>>>>>>> be eventually enabled later on if we really want to preload
>>>>>>> all FS inputs at beginning.
>>>>>>>
>>>>>>> Polaris10:
>>>>>>> Totals from affected shaders:
>>>>>>> SGPRS: 54072 -> 54264 (0.36 %)
>>>>>>> VGPRS: 38580 -> 38124 (-1.18 %)
>>>>>>> Spilled SGPRs: 652 -> 652 (0.00 %)
>>>>>>> Spilled VGPRs: 0 -> 0 (0.00 %)
>>>>>>> Code Size: 2128116 -> 2127380 (-0.03 %) bytes
>>>>>>> Max Waves: 8048 -> 8086 (0.47 %)
>>>>>>>
>>>>>>> Vega10:
>>>>>>> Totals from affected shaders:
>>>>>>> SGPRS: 52616 -> 52656 (0.08 %)
>>>>>>> VGPRS: 37536 -> 37116 (-1.12 %)
>>>>>>> Spilled SGPRs: 828 -> 828 (0.00 %)
>>>>>>> Code Size: 2043756 -> 2042672 (-0.05 %) bytes
>>>>>>> Max Waves: 9176 -> 9254 (0.85 %)
>>>>>>>
>>>>>>> Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
>>>>>>> ---
>>>>>>>    src/amd/vulkan/radv_shader.c | 10 ++++++++++
>>>>>>>    1 file changed, 10 insertions(+)
>>>>>>>
>>>>>>> diff --git a/src/amd/vulkan/radv_shader.c
>>>>>>> b/src/amd/vulkan/radv_shader.c
>>>>>>> index 7ed5d2a421..84ad215ccb 100644
>>>>>>> --- a/src/amd/vulkan/radv_shader.c
>>>>>>> +++ b/src/amd/vulkan/radv_shader.c
>>>>>>> @@ -278,6 +278,16 @@ radv_shader_compile_to_nir(struct radv_device
>>>>>>> *device,
>>>>>>>          nir_lower_vars_to_ssa(nir);
>>>>>>>    +     if (nir->info.stage == MESA_SHADER_VERTEX ||
>>>>>>> +           nir->info.stage == MESA_SHADER_GEOMETRY) {
>>>>>>> +               NIR_PASS_V(nir, nir_lower_io_to_temporaries,
>>>>>>> +                          nir_shader_get_entrypoint(nir), true,
>>>>>>> true);
>>>>>>> +       } else if (nir->info.stage == MESA_SHADER_TESS_EVAL||
>>>>>>> +                  nir->info.stage == MESA_SHADER_FRAGMENT) {
>>>>>>> +               NIR_PASS_V(nir, nir_lower_io_to_temporaries,
>>>>>>> +                          nir_shader_get_entrypoint(nir), true,
>>>>>>> false);
>>>>>>> +       }
>>>>>>> +
>>>>>>>          nir_split_var_copies(nir);
>>>>>>>          nir_lower_var_copies(nir);
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mesa-dev mailing list
>>>>>> mesa-dev at lists.freedesktop.org
>>>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev