Hi! This is a trunk build, built with MinGW-w64 (gcc 4.7.0). It comes with everything you'd expect in your official Windows 64-bit build, but with more speed and CUDA 3.0 kernels! (except for the Blender Player, sorry but it's too big and rarely used)
In my own tests with a Visual Studio 2010 build and a MinGW-w64 build, this MinGW build was twice as fast in rendering using the CPU in Cycles. The test was rendered to 50 passes on an AMD Phenom system, with the Visual Studio build taking 66.13 seconds, and this build taking only 32.25 seconds. Don't believe me? ;) Many Windows builds here on GraphicAll, along with official releases use Visual Studio, so expect to see a difference from them.
Your mileage may vary, but this build should still show some speed boost. GPU rendering speeds with Cycles will be the same across any build, so please keep that in mind before commenting that this build isn't any faster. Of course, I encourage you to try other MinGW-based builds on GraphicAll if you have any issues here, they should all be just as fast.
You will need a CPU with SSE3 support to run this build, which almost all 64-bit systems have anyway. Happy blending, and don't forget to leave a comment with your results using this build! :)
SCons build configuration:
import btools arch = 'nocona' WITH_BF_JACK = False WITH_BF_SNDFILE = False WITH_BF_QUICKTIME = False WITH_BF_REDCODE = False WITH_BF_PLAYER = False WITH_BF_COLLADA = True WITH_BF_OPENAL = True WITH_BF_SDL = True WITH_BF_OPENEXR = True WITH_BF_DDS = True WITH_BF_JPEG = True WITH_BF_PNG = True WITH_BF_TIFF = True WITH_BF_ZLIB = True WITH_BF_INTERNATIONAL = True WITH_BF_OPENJPEG = True WITH_BF_FFTW3 = True WITH_BF_GAMEENGINE = True WITH_BF_OCEANSIM = True WITH_BF_LIBMV = True WITH_BF_BULLET = True WITH_BF_ICONV = True WITH_BF_OIIO = True WITH_BF_BOOST = True WITH_BF_OPENMP = True WITH_BF_FFMPEG = True WITH_BF_CYCLES = True WITH_BF_CYCLES_CUDA_BINARIES = True BF_CYCLES_CUDA_NVCC = '../../Program Files/NVIDIA GPU Computing Toolkit/CUDA/v4.2/bin/nvcc.exe' BF_CYCLES_CUDA_BINARIES_ARCH = ['sm_12', 'sm_13', 'sm_20', 'sm_21', 'sm_30'] REL_CFLAGS = ['-O2', '-ftree-vectorize', '-ffast-math', '-finline-functions', '-flto', '-march=' + arch, '-mfpmath=sse'] REL_CXXFLAGS = ['-O2', '-ftree-vectorize', '-ffast-math', '-finline-functions', '-flto', '-march=' + arch, '-mfpmath=sse'] REL_CCFLAGS = ['-O2', '-ftree-vectorize', '-ffast-math', '-finline-functions', '-flto', '-march=' + arch, '-mfpmath=sse', '-DNDEBUG'] WITH_BF_RAYOPTIMIZATION = True BF_RAYOPTIMIZATION_SSE_FLAGS = ['-Ofast', '-flto', '-march=' + arch, '-mfpmath=sse'] BF_BUILDDIR = '..\\build\\win64-mingw-' + arch BF_INSTALLDIR = '..\\bin\\Blender' + btools.get_revision() + '-MinGW64'
rich33584: I'd like to know too, but it's hard to debug if Blender only freezes. Loading old .blend files created with a trunk build has been known to cause issues, so it'd probably be best just to recreate them by appending objects.
Thats strange because its 2 diferent files that its doing that on and I just pulled that phone file out to test and havent used that .blend in awhile.Ill try the work around, but it would be nice to see whats causing it.
I also made another build without any optimizations, and the original phone.blend didn't work either, so it's hard to track down the actual cause. Either way, a new blend file with appended objects from the original file seems to be ok!
I have windows 7 64 bit with 8 gigs of RAM and an I7 processor
Log in to leave a comment.