radeonsi: enable compiling one variant per shader
authorMarek Olšák <marek.olsak@amd.com>
Thu, 28 Jan 2016 00:29:59 +0000 (01:29 +0100)
committerMarek Olšák <marek.olsak@amd.com>
Sun, 21 Feb 2016 20:08:58 +0000 (21:08 +0100)
commit9aaf28da629e025f652c7ff63750ad8ee513ff42
treeb03eb8a6f38fbbc9e15f22ba0ec7fdbf635b2da3
parent754cf171e90cc61d135e7c45f8be319ee2db02a5
radeonsi: enable compiling one variant per shader

Shader stats from VERDE:

Default scheduler:

Totals:
SGPRS: 491272 -> 488672 (-0.53 %)
VGPRS: 289980 -> 311093 (7.28 %)
Code Size: 11091656 -> 11219948 (1.16 %) bytes
LDS: 97 -> 97 (0.00 %) blocks
Scratch: 1732608 -> 2246656 (29.67 %) bytes per wave
Max Waves: 78063 -> 77352 (-0.91 %)
Wait states: 0 -> 0 (0.00 %)

Looking at some of the worst regressions, I get:
- The VGPR increase seems to be caused by the fact that if PS has used less
  than 16 VGPRs, now it will always use 16 VGPRs and sometimes even 20.
  However, the wave count remains at 10 if VGPRs <= 24, so no harm there.
- The scratch increase seems to be caused by SGPR spilling.
  The unnecessary SGPR spilling has been an ongoing issue with the compiler
  and it's completely fixable by rematerializing s_loads or reordering
  instructions.

SI scheduler:

Totals:
SGPRS: 374848 -> 374576 (-0.07 %)
VGPRS: 284456 -> 307515 (8.11 %)
Code Size: 11433068 -> 11535452 (0.90 %) bytes
LDS: 97 -> 97 (0.00 %) blocks
Scratch: 509952 -> 522240 (2.41 %) bytes per wave
Max Waves: 79456 -> 78217 (-1.56 %)
Wait states: 0 -> 0 (0.00 %)

VGPRs - same story as before. The SI scheduler doesn't spill SGPRs so much
and generally spills way less than the default scheduler.
(522240 spills vs 2246656 spills)

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
src/gallium/drivers/radeon/r600_pipe_common.c
src/gallium/drivers/radeon/r600_pipe_common.h
src/gallium/drivers/radeonsi/si_pipe.c