[Mesa-dev] [PATCH] radeonsi/nir: disable GLSL IR loop unrolling

Timothy Arceri tarceri at itsqueeze.com
Wed Feb 21 21:39:13 UTC 2018


On 22/02/18 06:09, Ilia Mirkin wrote:
> On Tue, Feb 20, 2018 at 8:35 PM, Timothy Arceri <tarceri at itsqueeze.com> wrote:
>> Delaying unrolling and allowing NIR to do it instead has been shown
>> to result in better code in drivers such as i965. shader-db results
>> appear to should the same is true for radeonsi.
>>
>> The other advantage is that using NIR unrolling improves compile
>> times significantly.
>>
>> Totals from affected shaders:
>> SGPRS: 9624 -> 10016 (4.07 %)
>> VGPRS: 6800 -> 6464 (-4.94 %)
>> Spilled SGPRs: 0 -> 2 (0.00 %)
>> Spilled VGPRs: 0 -> 0 (0.00 %)
>> Private memory VGPRs: 0 -> 0 (0.00 %)
>> Scratch size: 0 -> 0 (0.00 %) dwords per thread
>> Code Size: 359176 -> 332264 (-7.49 %) bytes
> 
> This basically means that fewer loops were unrolled.

No that is just one of the possibilities, as the commit message says 
unrolling with NIR has been shown in the past to result in better code.

The large drop seems to be largely a result of better loop unrolling in 
the dolphin uber shaders. For example 
shaders/dolphin/ubershaders/228.shader_test when using GLSL IR to unroll 
results in a final NIR representation with 39 loop (I'm actually not 
sure where they all come from as the raw shader seems to contain far 
fewer), but when unrolling in nir we end up with only 14 that could not 
be unrolled. The end result is a reduction in code size of 55%.

> I don't know if
> this is the right metric to look at when comparing loop unroll
> efficacy.
> 
> IOW, you might want to look at actual perf of some of the affected
> games. (For all I know it really does improve. My point is that this
> isn't a good measure of that.)

If this were simply a case of less loops being unrolled one would also 
expect Max Waves to drop but instead they increased. There was a bunch 
of testing done when i965 switched to using NIR only for unrolling and 
once a couple of regressions were fixed doing it in NIR was shown to be 
much better. The fact is GLSL IR opts can end up doing more harm than 
good, eventually I'd still like to be able to do a a NIR packing pass 
like we have in GLSL IR and move various parts of the linker to NIR so 
that we can try disabling even more GLSL IR opts.


> 
>> LDS: 0 -> 0 (0.00 %) blocks
>> Max Waves: 1355 -> 1432 (5.68 %)
>> Wait states: 0 -> 0 (0.00 %)
>> ---
>>   src/gallium/drivers/radeonsi/si_get.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_get.c b/src/gallium/drivers/radeonsi/si_get.c
>> index ef03a962d1..18d9cec414 100644
>> --- a/src/gallium/drivers/radeonsi/si_get.c
>> +++ b/src/gallium/drivers/radeonsi/si_get.c
>> @@ -437,6 +437,8 @@ static int si_get_shader_param(struct pipe_screen* pscreen,
>>          case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
>>                  return SI_NUM_IMAGES;
>>          case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
>> +               if (sscreen->debug_flags & DBG(NIR))
>> +                       return 0;
>>                  return 32;
>>          case PIPE_SHADER_CAP_PREFERRED_IR:
>>                  if (sscreen->debug_flags & DBG(NIR))
>> --
>> 2.14.3
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list