Hi, does anyone know with certainty whether or not SSS and Strand Rendering are not GPU enabled?
Also, I had understood that Sergej’s updates to Rigid Body Dynamics (i.e., motor constrain) are included in this release but did not see in the announcement… does anyone know?
Thank you.
Strand rendering and SSS are currently not usable with the GPU, in part due to the level of difficulty involved when it comes to a fast implementation.
The GPU is not an easy piece of hardware to program for, SSS is doable as shown with Octane’s implementation, but there’s not yet any well known method for getting hair to work without losing the speed advantage.
Hi, does anyone know with certainty whether or not SSS and Strand Rendering are not GPU enabled?
Download the 2.67 RC1 and confirm for yourself.
Because computers are unable yet to program themselves. So there must be a human yet to create the programs. And program for GPU is a hell of a job, you need to do things in a way that you put all the processors to work using same instructions and working on same shared memory. If you don’t that your GPU program can become slower than CPU.
Moved from “Latest News” to “Blender and CG Discussions”
Thank you.
Not able to do so for a couple of weeks – traveling. Are you being sarcastic or do you not know the answer either.
I think RC1 was released just, I downloaded from builder.blender.org, interested in this issues myself.
Is it bad that this release was the highlight of my day?
No, SSS and hair are not enabled, and likely won’t be for some time. Octane is the only group that has figured out fast GPU raytraced SSS, and no one has figured out fast GPU hair. I wouldn’t bank on Cycles being the first, no matter how good Brecht and Stu are.
I would also like to add that I hope Brecht considers gpu SSS and hair to be low priority. Considering how long it will likely take to crack that nut, in the same frame of time they could probably implement displacements, deformation blur, volumetrics, baking, etc…
lets get a fully featured CPU renderer going then go back and add gpu support (which won’t likely happen, since cycles won’t ever be “fully featured”).
my 2 cents. I love the speed of the gpu, but gpu development is insanely hard and time consuming. Something’s gotta give, and first and foremost, I want a stable, feature-complete renderer more than anything.
I agree with this, it’s difficult enough for Brecht to get SSS working on the CPU while keeping with the Cycles philosophy of having no preprocessing stages, I can only imagine the tremendous amount of R&D that Refractive Software spent over a long period to get their GPU SSS implementation working.
So yes, get all of the features working on the CPU first, and worry about the GPU later. I still think it would also be a good idea for Brecht to spend time on CPU optimizations so as to make Cycles a bit faster without requiring the use of the GPU. (like removing the issues with overhead when using the non-progressive integrator with a material using a lot of different shading components).
I am a little afraid the both units falling apart more and more. Next come volumetrics and then motion blur and so forth.
The performance on CPU lacks behind GPU and for small studios it is much cheaper to setup a GPU workstation even electric bill wise.
Since brecht is alone (with broadStu) more or less it need years to get these features to the GPU (or never).
Only my concerns.
Cheers, mib.
I say CPU first, because I don’t have a GPU. 
Not to bash GPU rendering by any means, but I don’t see it as a NECESSITY at all. Every single person running Blender has a CPU capable of rendering with Cycles. CPU SHOULD be prioritized, not because I think it’s better, but because it’s something the Blender userbase all have access to without question. Doing the opposite will just create bottlenecks. GPU rendering wont bring Cycles up to par with something like Arnold. I use Arnold every day, it has absolutely no GPU support, and has gotten much faster this past year; and is MUCH faster than Cycles compared to the last time I compared the two.
I am not again prior CPU but may add a new feature, first CPU than GPU than next feature.
It need a long time to get Cyles feature complete and stable anyway.
But may it is only because I have suitable GPU´s. 
Cheers, mib.
EDIT: Chris L, it would be interesting to compare Arnold on a 500$ CPU with Cycles on a 500$ GPU.
Same for me, i have i5 2400 and until OpenCL is not working then CPU is my only option too, maybe in future Cycles will get more massive optimizations from devs to be much faster on casual(affordable to everyone, middle class) CPU
SSS is awful anyway in cycles. I’m using 128,000 samples and it still has compression-like noise.
Fix that first, then make the render more optimised in general for cpus so it runs faster.
We need CPU rendering for everything in cycles, From what I can tell all we need now is volume and proper caustics rendering.
SSS is awful anyway in cycles. I’m using 128,000 samples and it still has compression-like noise.
Fix that first, then make the render more optimised in general for cpus so it runs faster.
I don’t have such problems. Maybe you’re using too large scale? What is “compression-like” noise, anyway? (do you mean just the regular stochastic noise?)
Did you use Non-Progressive integrator? With progressive is much noiser