[Mesa-dev] [PATCH 4/4] glsl: Use hash table cloning in copy propagation

[Tapani Pälli]

On 01/13/2017 08:55 PM, Thomas Helland wrote:
> 2017-01-13 18:41 GMT+01:00 Vladislav Egorov <vegorov180 at gmail.com>:
>> 13.01.2017 15:31, Tapani Pälli пишет:
>>>
>>>
>>>
>>> On 01/12/2017 09:23 PM, Thomas Helland wrote:
>>>>
>>>> Walking the whole hash table, inserting entries by hashing them first
>>>> is just a really really bad idea. We can simply memcpy the whole thing.
>>>
>>>
>>> Maybe it is just 'really' not 'really really' since I don't spot any
>>> difference in time running the torture test in bug #94477 (oscillates close
>>> to 120s with both with and without these patches), I would expect at least
>>> some difference as it is utilizing this path a lot. Did you measure
>>> performance difference?
>>>
>>
>> It wouldn't help the torture case from the bug, because that shader doesn't
>> have LOOP and IF blocks, so more efficient copying the ACP for LOOP/IF
>> blocks would not be even touched.
>>
>> Quick benchmark of Tom's patches on shader-db.
>>
>> Default shader-db, ./run -1, 10 runs:
>>
>>               BEFORE    AFTER
>> softpipe      3.20s     3.15s
>> radeonsi      5.17s     5.12s
>> i965/Haswell  7.33s     7.19s
>>
>> On my full shader-db (50K+ shaders from games):
>>
>>                   BEFORE   AFTER
>> softpipe (5 runs) 156.6s   153.9s
>> i965              625s     613s
>>
>> So it brings 1-2% speed across the board.
>
> What he said. It only helps when there are if's or loops.

Ah right, this is true.

> The other patch I wrote based on Connor's suggestion makes a big impact.
> But as he found out, and I confirmed, yesterday, the approach doesn't work.
> So it is back to the drawing board on that one. And I thought I was so close :-/

Yeah, I run a CI on it and there was quite a bit of regression. But 
props for trying, it is a tricky pass to optimize.

// Tapani