Blender Guru is comparing 8 Blender versions to see how their rendering speed has changed recently. The results are impressive!
Cycles has long been accused of being slow and therefore ‘unfit for production’. But actually, Cycles today has never been faster. In fact, it’s almost twice as fast as it was two years ago. I tested 3 different scenes on the same computer, using both CPU and GPU – and compared the results with the last 8 versions of Blender.
39 Comments
Electric cost wise, 2x GTX 680 are 195 watt X 2 = 390 watt (at full load), plus other power consumption it is close to 600 watt. Which is still 6x the consumption of a CPU rendering at full load. 6x is big, a $1 million production in CPU optimized rendering
will mean $6 million (GPU initial cost and setup not accounted) in GPU
assuming same rendertime. The better matrix to measure rendering
efficiency is rendertime/wattage/frame.
But the reality now
(based on the data presented) cycles CPU rendertime is 5~6x GPU rendertime.
Either way you still use 5~6x your CPU power usage, which, big surprise,
close to your GPUs power usage per frame. : ]
6 times the cost to power it is nothing compared to the cost of a bunch of artists sitting around waiting for their renders to complete ;)
If you have idle artists then the studio has serious work organization problem. The studio manager should fire himself/herself. XD
I read this and fired myself.
Oops.
Based on the highest kwh cost of 2011 being $0.41 you could run a single machine at 600 watts non stop for about 14,000 years, for $30m. So I'm not quite sure where you're getting your figures.
It is very obvious I'm not talking about a single machine (not hobbyist numbers). I'm talking about people who are building renderfarm(s), a mid size studio, real world situations with typical production profit margin. Cycles now (either CPU and/or GPU) is barely profitable (on too many projects that we know and experienced). There are talks about this among developers in the past few months. Ton himself acknowledge this issue. But others dismissed it, such as few above, because they never run/manage a renderfarm. This is not about plain dislike of cycles, when it comes to dollars and cents cycles still not sustainable for small and mid size businesses.
I was just pointing out that $30mil is an absolutely absurd figure.
Even with 1000 of these machines, you're still talking 14 years of rendering.
You sure it's not 5mil on a 30mil production?
1000 machines with gpu is big cost (roughly $1 million at current hardware price). Plus the running cost that I mentioned, times hardware "mortality" rate, times hardware depreciation value, plus admin cost, plus cooling cost, plus wiring cost, space cost, plus scheduled maintenance cost. Clearly you don't see those added into the total sum.
Since you don't seem to use periods properly, I'm only quoting a small segment, of your running sentence.
"a $5 million production power usage in CPU optimized rendering will mean $30 million power cost "
At no point did you mention, any part of the $30,000,000 being part of anything, other than the electrical cost. So please get all the figures and facts straight, before you post something, making such claims.
Attacking me will not solve cycles power usage and rendertime.
No attack, but take it however you like.
Glad that you bought that up that is probably the single most issue I have with unbiased renderers they are simply gobbling up to much power with not really qualitative benefits over biased optimized rendering engines like vray, mental ray, I hope we get biased algorithms on cycles, original yafray was super awesome for this very simple fact and that fact that it was firefly free too.
Thanks for understanding the issue. I have worked with cycles for clients, profit on those projects are near zero, charity. Few of my other friends in Cyberjaya, Kuala Lumpur and Selangor in Malaysia also voiced the same concern. Now they try not to get cycles involved in any of their projects. They resort to matcap and GLSL rendering.
While cycles still relevant for most stills, projects with 1 time usage (ie: event poster, animated logo at 8k) are often very low budget. Cycles only profitable when the rendered result is reusable (ie: tutorial makers, commercial animations [Pay per view, cinema broadcast]).
Hi, I appreciate that this is a very late reply. I've been trapseing the Internet for a valid reason to use maya over blender and mental ray over cycles. And to be honest there doesn't seem to anything. Off point.
However your response/reason to cycles being a very costly rendering choice is quite frankly ridiculous. I'm by no means a professional, I'm actually a student, however I'm studying 3d animation and vfx, and I had cycles render several scenes which equated to about 3 minutes of video time. Full environments and materials, several light sources and particle systems including fluid systems. And I had it run for maybe 4 days (96 hours) and it cost me about £5 (~$8) that was at full HD and about 1200 passes per frame. So it was by no means of grainy quality. It ran full global illumination with raytrace shadows and caustic and reflections etc. On a "gaming" rig not a workstation. I can't see how at any point it would ever cost any production company anywhere near $30mil ever.
I'm sorry if you think I'm trying to troll or whatever but I just cannot see that cost ever.
Understand your POV, but you need to run a business to be able to see the cost at a larger scale. Also for Gooseberry, Cycles has been at their hardware limit for almost every render. I mean the amount of entropy needed just for a frame is high.
Well that was quick! I just came here to submit it and you beat me ;)
Cheers Bart!
I'm keeping an eye on you :)
Light Bwk has it right. Come on, people, "fit for production" is not the same thing as "it's twice as fast as it was when it was four times too slow." As Light Bwk points out, it's all about the combined costs of using one compared to another renderer. 'But Cycles is free!' Again, penny wise and pound foolish. Using a free renderer only to shell out millions of extra dollars in power consumption is not a bargain.
Did you read the second paragraph of his first post?
As far as gpu vs cpu rendering, gpus render faster and use an almost equivalently higher amount of power. As far as watts per second are concerned, they're pretty much neck and neck.
it's like comparing an easy bake oven with a real oven. Sure, the easy bake is only using 100 watts, but it will take 10 times longer than the real oven with 1000 watt output.
There are several totally legitimate reasons why cpu rendering is a better decision than gpu rendering. Power consumption isn't one of them.
I'd still rather see a speed comparison with other renderers instead of simply comparing where it is now to how slow it used to be. "Twice as fast as it was" is not informative at all as to its performance against its competitors. Literally, all it means is "It used to be two times slower than it is now." And I'm sure the present version of Cycles is easily ten times faster than some early alpha version of Cycles. It still leaves the actual issue well ambiguous. What are the criteria for production suitability, and where does Cycles stand in comparison to this? That is the minimum information required to make an informed decision.
And if this article were entitled "why cycles is the fastest renderer in the world" that would be a totally valid complaint. But for the point the article was trying to make, that cycles is faster now, that seems like a bit of a red herring.
"Cycles has long been accused of being slow and therefore ‘unfit for production’." That 1st sentence is begging for it to be compared with other more efficient renderers. After that sentence, the article stray away from the real issue, comparing itself now to itself in the past. Like comparing how smart you are now to how smart you are in the past, but not comparing how you are among the smartest.
I hate to say it, but that's what's known as the "Begging the question" fallacy. Saying it's was previously accused for being slow and unfit for production isn't necessarily a comparison with how well other renderers perform with the same tasks for production.
The comparison at least just determines that, in a production environment, Cycles is improved towards the demands of production. Even if you've never used any other renderer for production, waiting half a day for a single render isn't a very time-efficient pipeline.
You don't need to compare Cycles to how well others fare to realize that saving time is always an improvement.
It is useless and time wasting to argue my approach to this reasoning. As it neither improve cycles rendertime, power usage and efficiency. However, failing to see cost to profit ratio in real situations, that is a problem.
Just a note, I added a bit more to my post there. I didn't see your post until I refreshed the page. The cost-to-profit ratio is a related topic, but I'm only dealing with as much as your statement saying that this comparison begged to be compared with other "production-ready" renderers, and my point is "production-ready" is relative.
While I know it's not required to be meant as comparison with how well other renderers perform the same tasks, my point is that the first topic sentence sets the expectation, by stating outright the "unfit for production use", objection, it implies the notion that some standard industry benchmarks exist that can or should be met. As such, the first sentence seems incongruent with the material that follows. As the dramatic fiction storywriting expression roughly goes, "the shotgun on the wall shown in Act One, Scene One that needs to be taken down and used by Act Three, Scene Two" -- just paraphrasing from memory here, don't have the actual quote. The first sentence itself felt like a red herring when I read it.
Andrew's direct quote was: "Cycles has long been accused of being slow and therefore ‘unfit for production’. But actually, Cycles today has never been faster. In fact, it’s almost twice as fast as it was two years ago." I read into this that the second sentence was meant as a proof of the first sentence. My interpretation was too literal?
What's the most efficient GPU to use right now?
gtx 750ti. It's not the fastest in the world, but at only 60w power consuption and $150, can't beat it for efficiency
one thing to account for: is the hardware used the same as the hardware used in the previous test? it can be easy to point that a program runs faster on newer hardware(and frankly, it would be concerning if new chipsets didn't improve the general performance in some way)
Cycles grow up faster :D i'm so happy
i don't have good GPU but now CPU is faster too, i'm so thankfully to 2.71 version
I'm confused. Why all this sniping about Cycles? It's free. If you think it's too slow for you, then:
a) Go and spend a fortune on an alternative 3D package.
b) Spend a fortune on V-Ray, Maxwell or whatever, and then spend ages exporting all your designs out of Blender to the new renderer, applying materials etc.
c) Keep using lovely free Cycles, spend a modest sum on a faster GPU, and waste only 1/10 second pressing F12 when it's time to render.
Some people here sound like spoilt children or glass-half-empty whiners.
Well the argument is that if you want to get the most out of Cycles, using complex lighting and shaders, rendertimes can make the rendertimes astronomically high to get a noiseless/acceptably grainy image. While this isn't much of a problem for still images, for animations it makes Cycles impractical for most Blender users unless you either make really simple stuff or you're willing to let it look quite noisy. Sometimes I wish we had a 'Blender Render 2.0' instead of Cycles, i.e. a more traditional raytracer instead of a pathtracer.
Also while it is true that Cycles is free, I don't think that should be used as an excuse to complain at people for not being happy with design choices that don't make sense.
Aren't grainy artifacts a part of any unbiased renderer that supports caustics and real world materials?
Yes, I didn't just mean it was Cycles specifically, hence the "Sometimes I wish we had a 'Blender Render 2.0' instead of Cycles, i.e. a more traditional raytracer instead of a pathtracer"
Why some time I feel that Andrew price seem like a blender dark sith?
What?! XD
I hope for AMD compatibility..