Cycles: Tweak to the expf() speed workaround

Add compile-time check for particular glibc version which fixed the issue.
This makes it so own-compiled blender is the fastest in the world, and the
only issue remains what should we do for release builds.

After some discussion with Campbell we decided to keep it as is for now
because slowdown is not that much noticeable. We'll disable this workaround
for release builds when all the majority of the distros will switch to the
new version of glibc.
This commit is contained in:
Sergey Sharybin 2014-11-07 13:35:45 +05:00
parent 548b8f51c9
commit a8b9402c8f

@ -25,10 +25,12 @@
#include "util_half.h"
#include "util_types.h"
/* On 64bit linux single precision exponent is really slow comparing to the
* double precision version, even with float<->double conversion involved.
/* On x86_64, versions of glibc < 2.16 have an issue where expf is
* much slower than the double version. This was fixed in glibc 2.16.
*/
#if !defined(__KERNEL_GPU__) && defined(__linux__) && defined(__x86_64__)
#if !defined(__KERNEL_GPU__) && defined(__x86_64__) && defined(__x86_64__) && \
defined(__GNU_LIBRARY__) && defined(__GLIBC__ ) && defined(__GLIBC_MINOR__) && \
(__GLIBC__ <= 2 && __GLIBC_MINOR__ < 16)
# define expf(x) ((float)exp((double)(x)))
#endif