Am 29.04.2018 um 11:34 schrieb Gert Wollny:
> Am Sonntag, den 29.04.2018, 10:43 +0200 schrieb Benedikt Schemmer:
>> Hi Gert,
>>
>> couldn't resist at least to try what would happen if I enable
>> register merge for radeonsi:
>>
>> PERCENTAGE DELTAS Shaders SGPRs VGPRs SpillSGPR
>> SpillVGPR PrivVGPR Scratch CodeSize MaxWaves Waits
>> piglit 80732 -0.16 % -0.02
>> % . . 0.87 % 0.86 % 0.04 % . .
>> ------------------------------------------------------------------
>> ----------------------------------------------------
>> All affected 513 -17.58 % -2.30
>> % . . 4.12 % 5.87 % 1.73 % 0.10 % .
>> ------------------------------------------------------------------
>> ----------------------------------------------------
>> Total 80732 -0.16 % -0.02
>> % . . 0.87 % 0.86 % 0.04 % . .
>>
>> I had already removed the defines around the debug code so thats also
>> happily outputting data.
>>
>> fails with two piglit shaders:
> Which are the names of these test? I'd like to check this on r600,
> because here I didn't see any regressions last time I checked.
>
might of course be different on r600 (is bindless available?),
also shader-db is more sensitive to problems than piglit
1. tests/spec/arb_bindless_texture/compiler/images/arrays-of-struct.frag
2. tests/spec/arb_bindless_texture/compiler/samplers/arrays-of-struct.frag
>
>> Real world is a little different:
>
> I guess these tests refer to enabled register_merge - without and with
> this patch set, no?
>
> Out of curiosity, did you also look at how enabling register_merge
> (before this series) impacts the result as compared to the normal
> operation of radeonsi?
no I didn't
but if I do
(old vs new)
nothing vs register merge:
PERCENTAGE DELTAS Shaders SGPRs VGPRs SpillSGPR SpillVGPR PrivVGPR
Scratch CodeSize MaxWaves Waits
piglit 80732 . . . . .
. 0.06 % . .
----------------------------------------------------------------------------------------------------------------------
All affected 435 0.89 % 0.36 % . . .
. 3.61 % -0.06 % .
----------------------------------------------------------------------------------------------------------------------
Total 80732 . . . . .
. 0.06 % . .
register merge vs yours:
PERCENTAGE DELTAS Shaders SGPRs VGPRs SpillSGPR SpillVGPR PrivVGPR
Scratch CodeSize MaxWaves Waits
piglit 80732 -0.16 % -0.02 % . . 0.87 %
0.86 % -0.02 % . .
----------------------------------------------------------------------------------------------------------------------
All affected 83 -56.92 % -14.22 % . . 11.67 %
16.67 % -2.86 % 0.93 % .
----------------------------------------------------------------------------------------------------------------------
Total 80732 -0.16 % -0.02 % . . 0.87 %
0.86 % -0.02 % . .
nothing vs yours:
PERCENTAGE DELTAS Shaders SGPRs VGPRs SpillSGPR SpillVGPR PrivVGPR
Scratch CodeSize MaxWaves Waits
piglit 80732 -0.16 % -0.02 % . . 0.87 %
0.86 % 0.04 % . .
----------------------------------------------------------------------------------------------------------------------
All affected 513 -17.58 % -2.30 % . . 4.12 %
5.87 % 1.73 % 0.10 % .
----------------------------------------------------------------------------------------------------------------------
Total 80732 -0.16 % -0.02 % . . 0.87 %
0.86 % 0.04 % . .
>
>
>> If theres an easy way to figure out when your code makes it worse and
>> when its an improvement this would be really nice.
>
> My insentive for this series was, that on r600 the arrays are allocated
> before the final optimization pass on the byte code that requires that
> the number of registers is <= 124. When I started this no spilling was
> implemented, and shaders with too many arrays and registers would
> simply fail. Now spilling is impelmented, but AFAIK reducing the
> numbers of registers in the final optimization pass does not result in
> changed spilling, so bringing down the number of registers before tgsi-
> to-bytecode is still of interest.
>
> For radeonsi my guess would be that the llvm optimizer works better
> when the registers are not yet merged, and that would be the reason why
> register_merge is disabled.
well at least sometimes it doesn't, low hanging fruit maybe?
>
> In any case, Timothy wrote in this thread [1] (last message) that he
> had similar patches for NIR.
>
> Best,
> Gert
>
> [1] https://patchwork.freedesktop.org/patch/189842/
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
