I’ve been struggling with Cycles under Windows for a over week now. I have a couple of windows 7 boxes rendering next to a few macs. The Windows versions of blender/cycles are rendering at roughly 2-3x slower than they should be (comparable to the relative speeds they get using Mental Ray or Blender Internal).
After a little research and help from some of the users on this forum, I found that Cycles’ render speed is affected by the type of compiler that was used to make the Windows builds. Apparently, you need a gcc compiler for Windows in order to get a non-crippled version of cycles.
Yet no one seems to care at all that cycles is crippled in Windows. No builds on graphicall to address it, the official builds don’t address it. This is a MAJOR issue, but no one seems to know or care about it?
Just because people cannot do anything about it does not mean that they don’t care. It looks like GCC+MinGW are broken on 64-bit Windows platforms. It is doubtful that anybody working on Blender has the extensive experience with contributing to these two packages to fix the issues that are affecting Blender.
If Blender is really suffering from this then chances are that the team on MinGW has lots of open issues and is working on them to the best of their ability.
Don’t spread such half-truths. If you want to compare cycles speeds, benchmark cycles and don’t make any assumptions with results from other renderers. In the other thread someone reported about 1.5x speedup between release builds in linux vs. windows - certainly not a 2-3x difference. Just because GCC on linux may create more optimized binaries, that doesn’t mean GCC-mingw builds will run faster on windows. At least for win64 they are known to be unstable, too. Also, both MSVC and GCC have different optimization settings, it’s possible that there is still room to the top with MSVC. Lastly, OS differences may also have an impact.
Basically, Microsoft does some optimizations that are reserved for the professional or enterprise versions of Visual C++, and most people on graphicall builds x64 versions of Blender using MSVC express. I was doing the same until i stopped doing so, since i don’t have time anymore to do so.
GCC/Mingw indeed can produce better and faster code for windows too, but only if you work with x86 code. Mingw/gcc for windows x64 was declared stable (no, is not broken BTW, but probably is still INCOMPLETE to build Blender or its dependencies, last time i cheched was some months ago) , but there’s no installer, so some manual thinkering before downloading and tweaking is required, and you also need to modify certain parts of the source code to work with it, recompile every library used by Blender with it (and of course, patch some of these to work with the new compiller).
I think Psy-Fi was looking into it, but it seems that there is no progress in that area, or is way too much work at this time to even dare to do it.
I was making a generalization of performance, not any specific benchmarks. Basically, after rendering several projects with both BI and mental ray, I’ve come to know what kind of performance differences to expect between my various hardware. And when I started rendering with Cycles, I found myself scratching my head at render times that I expected to be 20-30 mins were coming out at 50-60 mins. The macs were performing to expectation, but not the Windows machines. So the 2-3x speed hit wasn’t exactly a scientific claim, but my results are consistently in that area no matter what project I throw at it.
So the issue seems to be more issues with the compilers than an issue with blender development. Yikes. I hope that can get ironed out soon.
Hi, I really haven’t tested MSVC cycles against MinGW cycles, but I think it shouldn’t be that different. For GPU execution in particular there should be little difference as the kernel compiler is the same. On one side people claim that MinGW is better than MSVC, but a QT developer friend of mine for instance claims quite the opposite. I haven’t profiled them personally unfortunately.
I hear a lot of people claiming that MinGW is unstable etc., there’s also a notification on the build page but, for the love of gods I still haven’t found out why. On windows 7 64 bit I have worked daily and exclusively with MinGW for about a year and so far I haven’t encountered any runtime issues specific to the compiler.
About MinGW64: I want to provide support for it but I am really bothered by the lack of official binaries. This simply means that different builders may come across different problems. I do consider trying it out though but if no official binary for MinGW64 is provided, I will vote for blender.org to host one.
This has been brought up before…pretty sure on the mailing list.
Brecht’s answer was, IIRC, yes he knows about it and does indeed care.
The main issue is that cycles is a WIP and is going for code completeness before optimization so until we can figure out how to clone Brecht there’s not much that can be done – aside from maybe profiling the msvc builds and figuring out why they’re significantly slower than the gcc builds, shouldn’t be too hard if they’re a half/third of the speed.
A virtual Linux machine (look at virtualbox OSE) might also give you a speed increase. At least if you render from the command line and don’t do anything in Windows while its rendering.
I realize this isn’t the answer you’re looking for, but figured it was worth mentioning anyway.
Make a backup always of your data because first try with Linux is possible you destroy your partitions. I have seen that just today and I see it many many times.
People play with their computers instead playing with sandboxes until they know what they are doing.
I always do my Blender work in Linux nowadays, it is quite irritating indeed but I think that ideasman mentioned that they include some code that makes Blender faster in their linux builds, it currently doesn’t work on Windows.
It kinda sucks but I like Linux so I don’t mind working in it for now
@Bao2: Which is why I suggested wubi or virtual machines since they will achieve just that
Wubi installs Linux right in your Windows partition using a Windows based install client, but is a true dual boot solution. No risk of messing up your partitioning
I have used Linux before and actually I love it, but I’m not very savvy with it once the “hand-holding” ends and the “real linux” begins. I can push my way through that, but what I can’t do is live without Photoshop, or After Effects, or Adobe Premiere, etc, etc.
I’m drifting away from mac (long story), so we’ve been slowly trickling windows boxes into the office, but Linux just won’t work for us until Adobe stops being asses and starts supporting Linux!
Ugh… I may have just derailed my own thread…
EDIT: I’ll look into WUBI. No need to partition?? But still boots into a native Linux environment? NICE!! Not really good for the office, but my inner geek wants to play with that regardless.
Upon once a time, before you got to lurk around here, there was quite some problems with the mingw x86 builds of Blender… long gone since, but you know, wiki pages tend to get pretty dusty over time… And windows users tend to be quite stable with their judgedment about software stability, probably because the system itself become stable since the XP version, i think ;).
The other way is to support them, MAME style: ( http://mamedev.org/tools/ ), in the Blender Wiki. maybe there will be bugs reports, but a warning in the wiki indicating that the toolchain is more or less unsupported should do i think… Oh well.
OK, its a professional setting, so if it just comes down to render speeds make a dedicated Blender box/farm running Linux for your workflow. Depending on when the last time you ran Linux was, you might find it has improved quite a bit in the UI department.
WUBI is cool, especially for people not so Linux savvy, but you do miss out on the faster/better file systems.
We actually have a simple file server running Ubuntu Linux now and it’s awesome! I’m strongly considering a Linux farm just for rendering. But as a graphics workstation Linux really needs Adobe for me to be able to consider it. Frustrating, because I kinda hate Adobe policies but I can’t deny they have some good software.
At least on the 3d side of things, Linux is pretty well convered. Maya, Houdini, Softimage, and this little app called Blender.
Anyway, I digress. I don’t have a lot of win boxes to worry about yet, but it really is disheartening to know that the performance of my hardware is being crippled due to software. I hope this is an issue that can get worked out. Cycles needs every ounce of optimization it can get.
How intensive are the things you do in photoshop? You could consider running a virtual Windows machine on a Linux box or use Wine… Yes, I like Linux, sorry
Do you exclusively use Cycles? If so, maybe a CUDA enabled graphics card in your Windows boxes will work?
I’m not sure virtual machines would work well in my environment. Premiere is CUDA accelerated, Photoshop is OpenGL accelerated and so is after effects. They are all massive 64-bit ram hogs as well. We’ve played a lot with Windows emulation on the mac, and it always winds up lacking, even using apps like vmware and parallels.
I do continue to dabble, from time to time, however.
