Cr8-xyz/blender
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Cycles: Tweak to the expf() speed workaround

Browse Source 
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
1 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
intern/cycles/kernel/kernel_compat_cpu.h
View File

@@ -25,10 +25,12 @@
#include "util_half.h" #include "util_half.h"
#include "util_types.h" #include "util_types.h"
/* On 64bit linux single precision exponent is really slow comparing to the /* On x86_64, versions of glibc < 2.16 have an issue where expf is
* double precision version, even with float<->double conversion involved. * 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))) # define expf(x) ((float)exp((double)(x)))
#endif #endif