Cycles CPU and GPU hybrid?

Currently, if I’m rendering a scene that can be done on both the CPU and GPU, I set the GPU rendering, open up another instance of Blender, reduce the threads so there are two spare, then set it rendering on the CPU also.

What do we think of implementing this inside of Blender as a feature? Obviously things like OSL would be disabled for such things, would need to go with what’s GPU compatible. I know it would make my rendering a bit easier/simpler…

OpenCL would support this, alas CUDA does not afaik

I doubt it will be implemented as it is kind of “hacky” which is exactly what Cycles was created to get away from. There’s never anything preventing you from opening two instances of Blender though. Just keep in mind that for many peoples’ set ups the overhead would result in a slower combined render speed than just using the GPU.

Here I wonder indeed, why not dropping cuda which has all this troubles regarding sm20 sm21 etc, different code headache, and instead focus on hybrid approach with open cl? Would this mean a total rewrite for Cycles? Or is perhaps not convenient?

Sorry if it’s a dumb idea or if it has been proposed before… but what about sending the scene both to CPU and GPU at the same time and both render an amount of samples depending on the device speed and then the result is mixed into one single image factored with the amount of total samples rendered by the device?
So, if a CPU can render 200 samples and the GPU 400 in the same time, then the final image is 33% CPU and 67% GPU.

Dropping CUDA wouldn’t be a good idea… Because, well, it’s there and it works…
Cycles Open CL development is on hold because of driver issues, which is for the Open CL devs to fix, as far as I know…

yes, AMD devs are making some progress it seems. amd is more powerful in double fp operations than nvidia, so it would be a shame not to take advantage of that… let’s hope they will fix it somehow
http://devgurus.amd.com/thread/160163

Because OpenCL has even more troubles and headaches than CUDA. It needs to mature a bit more first…

In OpenCL, each vendor has different platforms as it is right now. So sharing context between two is not trivial. Moreover, cpu and gpu have different speeds, so dispatcher needs to optimize for it.

Last I tested it, Cycles in OpenCL-mode on NVIDIA was about 30% slower than CUDA. It’s also more reliable and convenient as far as pre-compiling the kernels goes. Supporting CUDA in addition to OpenCL isn’t a big deal either, so I don’t see a reason to drop it. The sm20/sm21 problems are likely to just show up under OpenCL, as well.

Cycles doesn’t use double-precision at all, so that doesn’t make a difference.

@FreeMind / n-pigeon / Zalamander: I see, thanks. I thought AMD troubles were just related to drivers and not OpenCL, also i was thinking about the Tile Compositor, but perhaps is heavily different task than rendering and it’s not comparable.