Has anyone else noticed this? I used the latest stable Blender version and rendered a scene with GPU. Blender 2.61 was faster by a full 35 seconds than Blender 2.67!! 130% faster render!
I realize 35 seconds isn’t very long but this is a small scene compared to what I normally do.
On a larger scene that would take ten minutes in 2.67, it would theoretically only take seven minutes in version 2.61. When you’re doing several product shots and you need them as soon as possible, it can add up!
Zach
You have noticed the vast amount of features that have been added since 2.61?
If I understand what you are saying, you are saying that the new features are causing the GPU to render slower because it has to calculate more?
Also, I was using the scene from the cycles benchmark thread. That file was originally made using 2.61 and without changing any of the settings or shaders or anything, if you render it using 2.67, it’s slower. I guess I’m just surprised.
Perhaps a better question would be, “Why are newer versions of blender now rendering slower than older versions?”
I’m not trying to be negative or put anyone down. The blender devs have done an amazing job and I love blender!
Along that note, I remember back when I first started using blender a good friend of mine kept telling me it would never be as good as any of the commercial software because it didn’t have people being paid to work on it. His argument was that if a company is dedicated and spending money to develop a software, it will always be better than a piece of software that people are developing for free and in their spare time. Here we are, almost ten years after he said this to me and Blender is right up there with the rest of them and it’s free!!
Zach
This is a known issue, and has iirc is because of additions like motion blur and hair.
Oh I see, so even though I am not using motion blur or hair in the render, the GPU has to go through this somehow to compute the scene?
Zach
Current gen GPUs don’t handle branching very well. My guess is that all those ifs asking whether you’re using particular features add up. It’s just an uninformed guess though so take it with a large grain of salt.
On a larger scene that would take ten minutes in 2.67, it would theoretically only take seven minutes in version 2.61.
130% faster render!
In my experience, 110% of forum users have problems with percentages.
If something takes you 0.7 times as long in 2.61, that means it’s (((1/0.7)-1) * 100)% faster. (~43%)
Conversely, 2.67 is only 70% as fast as 2.61.
There are several reasons for this, one being the added amount of features and general code restructurings. Indeed branching is inefficient on modern GPUs, so every time you need to add an if-else statement (something that you simply can’t get around doing a lot of the time) your code is bound to become a little slower. Memory accesses are also slow, so whenever you need to load a little more memory than before, your code will be slower.
Cycles is still comparatively early in development, so it’s not the time for micro-optimizations yet. Things may just get a bit worse before they get better, or they just might stay worse.
Thanks for clarifying the percentage thing. I guess I meant to say that 2.61 is 1.3 times faster at rendering the same scene than 2.67.
version 2.67: 2:34 or (2*60s + 34s) = 154s
version 2.61: 1:57 or (1*60s + 57s) = 117s
117s * 1.3 = 152.1s
130% expressed as a decimal = 130 / 100 = 1.3
So yeah, 2.61 is 130% as fast as 2.67.
(I got my wording wrong. It is 30% faster…lol.)
Zach
On the other hand, if it’s only simple ifs asking whether certain features are used, it’s probably a static amount of time required. So I don’t think it scales as much as implied in the first post.
(So 10 secs on a 1 minute render might remain 10 secs on a 10 minute render, or, making a wild likelyhood guess, 30 secs on a 10 minute render, still not much of a problem)
Unless those ifs are asked on each frame.
I’m afraid you still didn’t get it right 
This is true.
130% expressed as a decimal = 130 / 100 = 1.3
This is also true, however we don’t usually use percentages in this way. 100% percent of some quantity is that same quantity, 130% of some quantity is that quantity plus 30% of that quantity. A pitfall would be then to say “this is 130% more” (1 + 1.3 -> 2.3 as much) when really you mean “this is 30% more”.
But what most people get wrong is the inverse relationship:
So yeah, 2.61 is 130% faster than 2.67.
This is wrong.
The following statement would be correct: “Rendering with 2.67 would take 30% longer”
Also correct: “Rendering with 2.67 takes 130% as long”
However, how fast something is is inversely proportional to how long it takes:
Imagine you could drive down a road at 100mph and it would take you 10 minutes.
Now, imagine you could do it 43% faster, at 143mph, how long would it take you?
100/143 -> 0.7 times as long, or: 7 minutes
Zalamander, I apologize for being stubborn. You are right, of course. I kept looking at my original post and I felt that I was wrong but I just couldn’t figure it out. Thank you for helping me to understand the correct way to do it! Percentages have always been a tough subject for me.
After looking around online about percentages, another way to say it is that rendering in version 2.61 knocks off 24% of my original render time from version 2.67. (Is this correct? 154s - 117s = 37s… 37s is 24% of 154s)
Apparently there are many different ways of expressing percentages…
My apologies!
Zach
Isn’t “100% faster” twice as fast? One time fast plus 100% of 1 time would equal 2 times, or 2 times 100%. Or 200% of something in total. Now, “130% faster” then would be twice and a third times faster i figure…around that.
Back to the sheep, 117 is faster than 154, so i would say 117 two times plus 38 which makes 272 or so, instead of 154.
One more check using above mentioned 43%: 40% of 120 is easier by hart: 120 + 48 = 168 - a bit closer, no?
154-154*24%=117, so 2.67 is slower by 24% compared to 2.61.
Conclusion: we do have 24% regression concerning render speeds. Or so. There is more: 2.49 does better AO still (imho), file from Jan versions had to be severely modified to get rid of firefly invasion and there is a remote chance to produce 2-vertice face using new tools - i managed once.
PS. Just love reading DA.
PS2. I do some English; not all unfortunately; my math is quite a bit rusty; numbers and facts provided can therefore be ignored fully.
PS3… and i’m kinda slow too, as it turns out…
maybe we should create a naked cycles branch, that has no features whatsoever, and so we use that one to load the files and hit render.
So a Clay render engine?