[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