On Mon, 2017-01-16 at 16:52 +0300, Vladislav Egorov wrote: > > 16.01.2017 16:13, Emil Velikov пишет: > > Hi Vladislav, > > > > On 14 January 2017 at 01:50, Vladislav Egorov <vegorov...@gmail.com > > > wrote: > > > 14.01.2017 01:45, Timothy Arceri пишет: > > > > I'm asking for a chance to test before we jump in, its probably > > > > not a > > > > big deal and I may even still be able to reduce my use of > > > > hashing but > > > > it would be nice to be given a few days to test and even > > > > explore > > > > alternatives before jumping on this implementation. > > > > > > A very quick and very dirty simple benchmark. I took shader-cache > > > from > > > github, branch shader-cache39. Then I've applied my preprocessor > > > patch on > > > top (because shader-cache still uses preprocessor even if the > > > shader is > > > cached and it was painful to see preprocessor taking more than > > > half of the > > > whole time). Then I've compiled it with openssl and with the > > > Emil's patch. > > > Full run on shader-db (300Mb+ of shaders) with shader-cache > > > warmed up. It > > > takes 78s, spends in libcrypto 0.27%. With OpenBSD SHA1 it runs > > > approximately the same time, spends 0.53% in SHA1Transform() and > > > other SHA1* > > > functions. Subtest - 46Mb of shaders from Total War: Attila - > > > 3.10s (for > > > some reason, the cache works much faster on smaller subsets than > > > on full > > > shader-db). 1.08% were spent in libcrypto, 1.04% in > > > sha1_block_data_order_avx2(). With OpenBSD 3.07s - 2.27% in > > > SHA1Transform() > > > and other SHA1* functions. > > > > > > > Did you mean "shader-db" with the "shader-cache" references above ? > > I > > cannot find any projects with the latter name on github. > > I meant Timothy's github: https://github.com/tarceri/Mesa > > > > Overall not that significant in context of shader-cache, but as > > > expected, on > > > Haswell it's twice slower than OpenSSL's AVX2 implementation. > >
Why not leave in a build time option for whichever is the fastest (non- OpenSSL) external SHA1 implementation but default or fallback to whatever gets pulled into the tree? That way integrators/distributions get to decide if they want to support the extra dependency and it removes almost all the variations and extra support machinery.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
