Cycles CPU + GPU rendering
It would be faster if the GPU and CPU were working together on 1 tile, instead of having the CPU with its separate tiles; constraining the GPU to an inefficient small tile size or having each CPU core take ages over its own big tiles.
What would also be amazing is if we could use the CPU for only caustics, and let the gpu handle everything else (akin to Luxcore, which i love to death for these kinds of features.)
12 Comments
Here's my suggestion:
devtalk.blender.org/t/problem-with-gpu-cpu-rendering/12223
* @3d illusions * this lead to a problem page with a redirect to the search function with "cpu gpu rendering". this isnt helpful
it would be better if the bucket size of the cpu was automatically calculated so that all cores combined would equal the speed of one optimally set GPU bucket.
For example if the cpu has 4 cores, and all 4 cores combined are 10 times slower than the GPU, then the 4 cpu buckets combined should be 10 times smaller than one GPU bucket. This would guarantee that there'd be no long wait when then gpu completes it's final bucket.
If the gpu runs out of VRAM and cycles has to go out of core, then sufficient cores should be removed from rendering so that they can be dedicated to transferring data to the GPU to avoid bottlenecks. Of course in this case the cpu bucket size should be recalculated based on the new number of cores that are available for rendering.
* @3d illusions * this poses one more problem; like when should the GPU rest and let the CPU do the rest? Having everything work on 1 single tile would eliminate this issue.
* @Julien * The gpu would just finish it's last tile, and then the cpu would finish it's last batch (which would take the same amount of time as one gpu tile).
* @3d illusions * but how would it plan that properly? what if theres a sliver of pixels left? would the gpu do that in less than a second or the cpu? these are the type of under the hood checks that can slow down renders, and its better to outright eliminate them.
* @Julien * Would it be faster for the GPU or the combined cores to render the last sliver of pixels if they both render at the same speed?
What would be the benefit of the gpu and cpu working on the same tile rather than them working on their own tiles if the GPU bucket renders at the same speed as the combined CPU buckets?
If you consider the image one tile, then why does it matter if the gpu and cpus all render the same tile if the image will finish at the same speed.
* @3d illusions * the gpu would be faster, and like i said before;having everything render the same tile removes the possible waiting on the slower tiles. youre just asking rethorical questions that lead nowhere
* @Julien * Sorry, my point is if the single gpu tile renders at the same speed as the combined CPU tiles, then it doesnt matter which finishes first, because they're both an equal speed. This means you will get the same speed as both cpu and gpu working on one tile.
* @3d-illusions * While I do understand, you're assuming both the GPU and CPU are equally fast. And honestly this is fine for still renders where a single second extra per frame is not a problem at all, but it does bleed render time during animation render sequences. After re-reading my previous messages to you (which honestly sounded defensive and aggravated,) so I do apologize for those.
I still think having both GPU and CPU work on the same tile would eliminate this issue altogether, but then there's the question of how to implement this; We could have the GPU and CPU see the big tile as a progressive image (like the progressive rendering option), write both results to memory and merge them every N amount of samples from the CPU (slowest hardware to prevent CPU being interrupted by GPU sampling speed and merge.)
What's your take on this?
AFAIK can't be done. CPU and GPU are separate processors working differently, using different memory. The caustics idea I don't know, sounds possible.
There is an argument for different tile sizes for GPU and CPU, but according to comments here:
blender.community/c/rightclickselect/qdcbbc/
It doesn't matter anymore - not something I've tested.
* @JRRRRRR * Luxcore does this, and ends up being faster than Cycles by 30% for me. it can definitely be done.