Cycles: Allow variable render tile size for mixed gpu/cpu #56123

New Issue

Jonathan Dunlap · 2018-07-27T22:13:55+02:00

Jonathan Dunlap commented

2018-07-27 22:13:55 +02:00

Blender now has the ability to render using both CPU and GPU in a single pass (https://developer.blender.org/D2873). However, cpus desire smaller tile sizes (32x32) and gpus prefer larger (256x256). On several machines I've tested, it's often the case that the mixed mode of rendering yields to no benefit to using either pure cpu or gpu (on the same machine) .I'd like to propose a major optimization where the tile size in a single render pass are different between cpu and gpu.

One method could be to divide the rendering area first into larger tiles (like 256x256) that would be optimal for the GPU to render each tile. However, tiles can become owned by the cpu renderer, which would subdivide these large blocks into subdivisions (32x32 or smaller) to process.

Blender now has the ability to render using both CPU and GPU in a single pass (https://developer.blender.org/D2873). However, cpus desire smaller tile sizes (32x32) and gpus prefer larger (256x256). On several machines I've tested, it's often the case that the mixed mode of rendering yields to no benefit to using either pure cpu or gpu (on the same machine) .I'd like to propose a major optimization where the tile size in a single render pass are different between cpu and gpu. One method could be to divide the rendering area first into larger tiles (like 256x256) that would be optimal for the GPU to render each tile. However, tiles can become owned by the cpu renderer, which would subdivide these large blocks into subdivisions (32x32 or smaller) to process.

Jonathan Dunlap commented

2018-07-27 22:13:55 +02:00

Added subscriber: @JonathanDunlap

Jonathan Dunlap commented

2018-07-27 22:18:03 +02:00

Added subscribers: @juang3d, @brecht

Jonathan Dunlap commented

2018-07-27 22:18:03 +02:00

cc @brecht @juang3d for thoughts

Lukas Stockner commented

2018-07-27 22:33:18 +02:00

Added subscriber: @LukasStockner

Lukas Stockner commented

2018-07-27 22:33:18 +02:00

Changed status from 'Open' to: 'Archived'

Lukas Stockner closed this issue

2018-07-27 22:33:18 +02:00

Lukas Stockner self-assigned this 2018-07-27 22:33:18 +02:00

Lukas Stockner commented

2018-07-27 22:33:18 +02:00

I've looked into this and it's definitely doable. The basic changes are easy, but there are two tricky parts:

The render engine API expects uniform tile sizes, that would need to be changed,
For denoising a uniform grid is needed. However, it wouldn't be too hard to merge smaller tiles back into large tiles before queueing them for denoising.

That being said, the bugtracker is not the right place for feature requests, so I'll be closing this.

I've looked into this and it's definitely doable. The basic changes are easy, but there are two tricky parts: - The render engine API expects uniform tile sizes, that would need to be changed, - For denoising a uniform grid is needed. However, it wouldn't be too hard to merge smaller tiles back into large tiles before queueing them for denoising. That being said, the bugtracker is not the right place for feature requests, so I'll be closing this.

Ray molenkamp commented

2018-07-27 22:35:42 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2018-07-27 22:35:42 +02:00

Also the whole 'gpu likes larger tiles' no longer holds true since 6da6f8d

Also the whole 'gpu likes larger tiles' no longer holds true since 6da6f8d

Jonathan Dunlap commented

2018-07-27 22:40:15 +02:00

This comment was removed by @JonathanDunlap

*This comment was removed by @JonathanDunlap*

Jonathan Dunlap commented

2018-07-27 22:40:40 +02:00

Added subscriber: @Lukas-132

Jonathan Dunlap commented

2018-07-27 22:40:40 +02:00

@Lukas-132 Stockner (lukasstockner97) thanks for the info, where's the right place for this?

Ray molenkamp commented

2018-07-27 22:54:03 +02:00

The default paste for a feature requests has some links

Hi, while we love to hear these ideas, this is not the right place for them. This website is mainly used to track bug reports and not feature requests. But luckly, there are some other nice solutions you can take, so please use one of the other >forms of communication listed below:

https://rightclickselect.com/
Fun board mailing list: https://lists.blender.org/mailman/listinfo/bf-funboard

The default paste for a feature requests has some links >Hi, while we love to hear these ideas, this is not the right place for them. This website is mainly used to track bug reports and not feature requests. But luckly, there are some other nice solutions you can take, so please use one of the other >forms of communication listed below: > >https://rightclickselect.com/ >Fun board mailing list: https://lists.blender.org/mailman/listinfo/bf-funboard

Lord Odin commented

2018-07-28 00:04:19 +02:00

Added subscriber: @derekbarker

Lord Odin commented

2018-07-28 00:04:19 +02:00

This comment was removed by @derekbarker

*This comment was removed by @derekbarker*

Lord Odin commented

2018-07-28 00:08:28 +02:00

It is impossible to stress how important this is. Most people dont understand enabling CPU+GPU uses nearly twice the power to render 3 seconds faster. If this is not optimized blender is solely responsible for global warming xD

In #56123#522465, @LazyDodo wrote:
Also the whole 'gpu likes larger tiles' no longer holds true since 6da6f8d

That is absolutely incorrect. I use blender every day of my life on production scenes and never is a tile size below 196x196 faster than 256x256

When this was initially committed you could see a huge improvement especially at 32x32 it was even faster than rendering at 256x256

Now that is not true at all 256x256 is once again optimal for some reason

It is impossible to stress how important this is. Most people dont understand enabling CPU+GPU uses nearly twice the power to render 3 seconds faster. If this is not optimized blender is solely responsible for global warming xD > In #56123#522465, @LazyDodo wrote: > Also the whole 'gpu likes larger tiles' no longer holds true since 6da6f8d That is absolutely incorrect. I use blender every day of my life on production scenes and never is a tile size below 196x196 faster than 256x256 When this was initially committed you could see a huge improvement especially at 32x32 it was even faster than rendering at 256x256 Now that is not true at all 256x256 is once again optimal for some reason

Juan Gea commented

2018-11-28 14:02:34 +01:00

Yes, I noticed it too lately, there is not much of a difference, at least not like before.

Maybe some regression?

Yes, I noticed it too lately, there is not much of a difference, at least not like before. Maybe some regression?

Hernan Schmidt commented

2020-07-26 05:02:58 +02:00

Added subscriber: @hyperchango

Hernan Schmidt commented

2020-07-26 05:02:58 +02:00

As of 2.83.3, there is still a single tile size setting for the whole render process, and GPU preference for larger tiles still holds true.

Is the Blender team considering this feature for an upcoming release?

As of 2.83.3, there is still a single tile size setting for the whole render process, and GPU preference for larger tiles still holds true. Is the Blender team considering this feature for an upcoming release?

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles: Allow variable render tile size for mixed gpu/cpu #56123