Murmur2a is a very fast hashing function generation int32 hashes.
It also features a very good distribution of generated hashes.
However, it is not endianness-agnostic, meaning it will usually generate
different hashes for a same key on big- and little-endian architectures.
Consequently, **it shall not be used to generate persistent hashes**
(never store them in .blend file e.g.).
This implementation supports incremental hashing, and is a direct
adaptation of reference implementation (in c++):
https://smhasher.googlecode.com/svn-history/r130/trunk/MurmurHash2.cpp
That cpp code was also used to generate reference values in gtests file.
Reviewers: sergey, campbellbarton
Reviewed By: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D892
It now supports different scheduling schemas: dynamic and static.
Static one is the default and it splits work into equal number of
range iterations.
Dynamic one allocates chunks of 32 iterations which then being
dynamically send to a thread which is currently idling.
This gives slightly better performance. Still some tricks are
possible to have. For example we can use some smarter static scheduling
when one thread might steal tasks from another threads when it runs
out of work to be done.
Also removed unneeded spin lock in the mesh deform evaluation,
on the first glance it seemed to be a reduction involved here but
int fact threads are just adding value to the original vertex
coordinates. No write access to the same element of vertexCos
happens from separate threads.
The ones in extern/glew-es have been changed to NOTE instead of XXX
GHOST_ContextEGL.cpp: It really does seem that it is not possible to query the swap interval using EGL
GHOST_WidnowCocoa.h: The comment referring to Carbon is clearly out of date, so I removed it.
math_geom.c: The node about not using tmax again is correct, but the code is kept for a future maintainer who will need to know how to compute it if they modify that code.
paint_image_proj.c (2698): The question about integer truncation does not appear to have been resolved. It still seems to be an incorrectly implementation of rounding (I'd suggest using the round function instead of this hack).
This commit switches meshdeform modifier to use threads to evaluate
the vertices positions using the central task scheduler.
SO now we've got an utility function to help splitting the for loop
into tasks using BLI_task module which is pretty straightforward to
use: it gets range (which is an integer lower and higher bounds) and
the function and userdata to be invoked for each of the iterations.
The only weak point for now is the passing the data to the callback,
this isn't so trivial to improve in pure C.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D838
Two fixes here (only the second one is strictly needed to fix the issue,
but both make the system better).
First is introduction of a random generator array for use with threaded
systems where each thread needs to access its own number generator.
The random texture now uses this so it should not be influenced by other
random generator reseedings of the main random generator like it did
before.
Second, I reshuffled the texture code to resample the upper bits of the
random number first. According to Numerical Recipes, this is where the
most variance can be found, so by sampling those we avoid correlation
issues. Also, multiplying here is not ideal because if a pair of bits
are zero, then the whole result will also be zero.
Overall this is much more random (tm) than before, however result will
also be brighter, since we now have less black spots. Tweaking the
brightness/contrast should somewhat fix that, generally having the same
result as before is not possible anyway if we are to really fix this.
Also, seems like exposing procedural depth might be nice here since it
influences the precision of the texture lookup.
Ghash comp callbacks must return false in case a & b are equal!
Also slightly cleaned up gash code using those comp func,
since those return booleans now, let's compare tham against booleans!
