Previous frame performance tile order in cycles to minimise GPU stalling in mixed render mode
Problem
With the awesome mixed rendering in cycles (GPU+CPU) we can now render like CPU mode but with 1 thread being the GPU. This is awesome but has 1 minor problem. When you have gpu as effectively 1 thread you end up with let's say 7 tiles that are rendered quite slowly and 1 that is rendering quickly on an 8 threaded CPU.
Now you may not realise what is wrong here so let me give you an example.
You have a scene where you have some ground and really fancy volumetric clouds at the top. The ground renders quickly and clouds render extremely slow. Now you start rendering and you come to the last few tiles of the frame. Those frames are the clouds. The gpu redners a frame and there are no unprocessed tiles left. 7 last tiles are processing on the cpu and it is going to take 20 minutes to render them. In those 20 minutes the gpu is just sleeping.
This is horrible for the total render time! A good thing to minimise this problem is to examine your scene and guess what is the best tile ordering mode. (in this example it would be the the top to bottom) ___
Solution
So this problem can be fixed pretty easy. All blender has to do is record a number for each tile render time and then assume that the next fame will not change drastically and then simply start rendering from the most expensive to cheapest tile. This way the GPU stalling will be as low because there is a high chance that the last few tiles will be the cheapest, thus the gpu sleeping time will be the lowest. (in cases where the world background is visible basically non existent as that is rendered extremely quickly)
2 exception to this would be frames where the active camera changes as it's likely that the scene will change drastically and the first frame of the animation. So to fill this gap a fallback/default ordering option would need to be added. ___ Note:
This could also be expanded to any device such as slow and fast gpu where each device (cpu/gpu/what ever can render things) performs a tiny benchmark to determine its computing power.
5 Comments
I don't know if it's possible, but I would rather the GPU just "take over" for the CPU if possible. Then there's no need to track anything.
Is GPU working? Do nothing. Is GPU idle? Is CPU working? Replace CPU with GPU and continue from where it left off.
There might be some overhead associated from passing whatever info back onto the GPU, but it's probably worth it to get that GPU crunching data.
@Cyanbcbc-work: This is something only developers could decide. I honestly don't have a clue about it.
@Cyanbcbc-work: I'm not sure if it's possible to "continue" rendering a tile. It is very likely that it's possible for a gpu to discard the tile and start over. But... this can cause more harm than it could help.
@toni.tube.you: It depends. While a tile on the CPU could take 3-4 minutes if it stops halfway and the GPU it's going to take 45-60 seconds it would be worthy anyway. The point here would be to avoid the CPU taking tiles at the very end I guess.
I've been thinking about this for a while too and I was waiting to see the final tile size for 2.8 because we obviously need the GPU to be as efficient or more than before using very small tiles to allow the CPU to also be effective for that same reason as you just explained. If your suggestion could be achieved it could be a solution. Another one would be having tiny tiles so the latest tiles rendered by CPU wouldn't take as long. Just not sure how small both can go while being as efficient. I think 16x16 was the best size using CPU+GPU. I don't think they can go smaller than that and be as fast.