I’ve been “out of it” for a couple months and now i just dove back in by installing 2.65a. I looked for a MinGW build and couldn’t find one, so I’m wondering if the “standard” build is now the fastest build, or do I have to start begging for a MinGW build (Windows 7 64-bit).
If MinGW is still majorly faster (which it definitely is in 2.63) why is not the preferred compiling method? It’s always baffled me that cycles was so hugely crippled on standard builds but MinGW release builds are so hard to come by.
Sorry is this is common knowledge, I’m just hoping someone knows the defintive answers so I don’t have to spend a couple of hours testing rendering speeds and hunting for builds to find out for myself.
Stability concerns are a legitimate reason for keeping it from being a preferred build. I never had stability issues with the builds I used, but that’s just my own experience.
Buildbot doesn’t seem to have the 2.65a release. It looks much older. It would be nice if there was a release build available.
huh, they havent been built in a month… my bad… i see them up there and was like well they must be updated regularly… sorry man!
As for stability issues, yeh i have had some weird cases, where the program would crash after i had a render if i was using the displace modifier… not sure if that has been fixed yet or not.
The MinGW Builds have some threading issues afaik (issue in the compiler itself), Psy-Fi did not found a solution to that yet.
It’s nice indeed, but still nowhere near a stable release.
Also there is no OSL for x64 MinGW atm.
If you can, just use Linux (on a second partition or so). Cycles on Linux is the fastest thing you can get (CPU rendering).
What kind of threading issues are present? Im just curious if the problem are something I can avoid. The render speed increase is hard to ignore, and switching all of our workstations to linux is too big of a hurdle at the moment.
Is it possible that the normal method for compiling could ever become as fast as the mingw builds?
the main thing with threading is no OpenMP.
so things using it you wont have…
Fluids, Cloth,(i think Smoke)
no OSL on MinGW either at the moment
really depends on what type of scene you are rendering…
If using Windows i would definitely have a MinGW build set as “portable”
config folder in your 2.6X folder and use that for CPU rendering if
no, Cloth, Smoke, or Fluids present and not using OSL
(basically normal indoor architectural scenes) etc…
Save file and switch to the MSVC OpenMP build when you need it.
Just My2Cents
as far as compiling goes with Mingw64, i used to be able to compile it with Scons no problems…
however as of about mid 2.64 something happened, and it will only compile with Cmake
(at least i can only get it to compile this way, Scons fails,
I liked Scons compiling way better, compile times were way faster to complete)
Scons mingw Numjobs 6
cmake mingw -j7
(scons would compile faster it seems, to bad it doesn’t work for me anymore ,
must use slow cmake)
I use it all the time; I keep a couple of versions on the computer. So the ones not prone to crashing are available. I tried a small test in linux before I had issues with computer (Managed to get a replacement motherboard on ebay) so lost my linux build, but will retry.
The test I did on linux was about the same as mingw; but it was only one test so can’t be sure.
But to answer the question, yes the speed increase has been consistent on all tests I’ve done; I done many over a period of time using various builds.
As far as I know, MingW is basically the Linux GCC compiler being ported over to Windows, right now it’s apparently developed enough to get Blender and Cycles working, but it’s still not perfect as the OpenMP and OSL libraries have to be disabled for now.
I also saw Brecht write before that MingW also compiles some of the Cycles code with SIMD optimizations even though it’s not explicitly written that way, which explains some of the speedup you get when using Cycles.
The threading issues are not only related to OpenMP, but to threading in general.
It’s related to how the mingw team implemented threading on the windows platform. Psy-Fi can tell you details.
Anyway, if you don’t need OSL then you can try it of course and see if it delivers reliable results for you fahr.
If you have plenty of RAM, a modern CPU (preferably with Virtualization extensions) and don’t need GPU Rendering, you could run Blender under a Linux virtual machine with little to no loss of rendering performance compared to the native Linux version.
With the usual Mike-Pan test scene on my Intel i5 3550, Blender 2.65 official version:
Kubuntu 64 bit (VM under VirtualBox / Windows 8 64bit): 3:58 (238 seconds)
Windows 8 64bit: 5:50 (350 seconds)
,
