2017-01-13 22:43 GMT+03:00 Emil Velikov <emil.l.veli...@gmail.com>: > > On 13 January 2017 at 19:22, Vladislav Egorov <vegorov...@gmail.com> wrote: > > 13.01.2017 19:51, Emil Velikov пишет: > >> > >> From: Emil Velikov <emil.veli...@collabora.com> > >> > >> At the moment we support 5+ different implementations each with varying > >> amount of bugs - from thread safely problems [1], to outright broken > >> implementation(s) [2] > >> > >> In order to accommodate these we have 150+ lines of configure script and > >> extra two configure toggles. Whist an actual implementation being > >> ~200loc and our current compat wrapping ~250. > >> > >> Let's not forget that different people use different code paths, thus > >> effectively makes it harder to test and debug since the default > >> implementation is automatically detected. > >> > >> To minimise all these lovely experiences, import the "100% Public > >> Domain" OpenBSD sha1 implementation. Clearly document any changes needed > >> to get building correctly, since many/most of those can be upstreamed > >> making future syncs easier. > > > > > > It can hurt performance. > This is not performance critical path ;-) If that ever changes we can > rethink our options. > > Emil
If it's used by shader-cache, it's certainly along the critical path. And 7-8 cycles per byte (or more than 10 cycles per byte on Atoms, Celerons and low-end AMDs) per byte of shader text is something to be considered. In comparison the entire preprocessing stage takes ~15 cycles per byte -- well, after my optimizations :) I regularly see util_hash_crc32() in perf top - because it uses inefficient table-based implementation with the same ~8 cycles per byte. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
