On Fri, Jan 13, 2017 at 1:55 PM, Thomas Helland <thomashellan...@gmail.com> wrote: > 2017-01-13 18:41 GMT+01:00 Vladislav Egorov <vegorov...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
