CPU boost for GPU rendering.
More a thought than a request, but why not also throw tiles to the CPU during GPU renders? It might be infeasible to implement but it does seem a bit of a waste of resources to have an almost completely idle CPU while rendering on GPU. Sure, it cant do much compared to a decent GPU but it could boost the rate by about a quarter.
Obvious issue: CPU and GPU peek efficiencies are found at VERY different tile sizes (CPU tends to like it best in the 16 to 64 range, GPU typically seems best at 256), so it would probably be best as a sub-tile system where a primary tile is sent for CPU rendering and then broken into a bunch of smaller sub-tiles, all 4/6/8 (or however many cores you have) then collaborate on that one primary tile. If it's not done like that? I foresee a lot of Idle GPU time while we sit and wait for the CPU to finish its 4/6/8/whatever tiles.
8 Comments
I am not a cycles expert (so correct me if i'm wrong), but to my knowledge there is a slight difference in render result when rendering on CPU or GPU (I remember this from distributed renderfarm discussions) so this probably would be not really feasible.
The problem you still run into (from what I understand) is the time necessary to assemble all of those tiles (and the memory management involved in making sure all of the tiles are in the same place. You either need to push the CPU-rendered frames to GPU memory or you need to drop the GPU-rendered frames to system memory. Depending on the overall rendertime for your image, this data shuffling could hurt that time significantly.
You could also use the CLI to initiate rendering if you dont want to open multiple Blender front ends when you do it.
A workaround is to open two instances of Blender and render x frame range with GPU in one instance and X frame range on CPU of the other.
Even better, you could use the Placeholder and No Overwrite features when rendering and you don't have to rely on frame range guessing. That said, this suggestion seems to be more about rendering a single frame than rendering an animation.
For one frame you'd have to do some math, but you could give, say, 256 samples to the CPU and 1024 to the GPU, then mix the two resulting renders with a 1:4 ratio (20%).
I get pretty bad crashing when I try that, and it's only useful for animations too.
Oooh, I didnt think of merging samples, that's a good idea.