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

Vladislav Egorov vegorov180 at gmail.com
Sat Jan 14 12:37:34 UTC 2017


14.01.2017 02:32, Connor Abbott пишет:
> On Fri, Jan 13, 2017 at 1:55 PM, Thomas Helland
> <thomashelland90 at gmail.com> 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.
>> 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 :-/
> Did you try deep copying the hash table (making new copies of the
> acp_entry's and fixing up their pointers)? It won't be as fast, and
> you can't do this optimization, but it might still be faster.

I don't see a reason to copy anything at all. From what I see copying 
the ACP is done to remove new COPY entries created inside of a block 
when leaving this block, while kills propagate to parent ACPs (if you 
are killed in the Matrix, you are killed in the real life, but your 
gains in the Matrix mean nothing in the real life). From what I see just 
single shared ACP table can be used. New COPY entries can be logged and 
then just undone rewinding the log when exiting the block. And kills can 
be done on the common ACP table directly. I've experimented with this 
approach on glsl_to_tgsi_visitor::copy_propagate() and it worked great.


More information about the mesa-dev mailing list