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.

> Overall not that significant in context of shader-cache, but as expected, on
> Haswell it's twice slower than OpenSSL's AVX2 implementation.

If I understood you correctly you're saying that despite this
implementation being slower the actual total runtime remains
unchanged.
In the Attila case we even get a minimal improvement, although I'm
inclined to discard that as within the error margin.

That sounds interesting, but in all honesty I don't believe it's worth
worrying unless we have usecase(s) where the runtime difference is
noticeable.

Thanks
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to