Hello. This is a pretty severe issue for us and the performance of our project.
We are using a custom SRP with Unity 2019.3.11f1 and CPU-wise the performance can become very, very weird. Case and point, this thread.
We’ve managed to spot some incredibly weird behaviour regarding the jobs that are scheduled when we call ScriptableRenderContext.Cull(). Take a look at these two pictures (profiled on Nintendo Switch, but the same happens on other platforms). Both of them capture the same scene and are just one frame apart from each other. The first one’s CullScriptable method finishes rather quickly (leaving the rest to the jobs), while the second one performs much more jobs before returning a value.
It seems as if there are some jobs executed at the end of the CullScriptable method and the timing of when they’re executed seems random (see the CullPerObjectLights job that is executed right after WaitForJobGroupID on the main thread). This doesn’t allow us to properly apply some optimizations to our SRP that we plan to make in the near future and thus will be a massive performance hog.
Guessing here. The default behavior probably allows enough time for jobs to finish, while where you are calling it doesn’t. The SRP culling job time aligning with CullScriptable in time taken say’s to me it scheduled then immediately waited on those jobs to complete.
I would try changing where you call cull and see if you can’t find a spot that allows more time. Very often the trade off here is sacrifice some accuracy like being a frame late to give jobs more time to run.
Fyi my response was mainly to why it’s all on the main thread. But I would suspect order/timing is also the culprit for why the second frame is doing more work. The timing might be making it cull far more then it should be.
Another option is to just use BatchRendererGroup directly and implement the culling callback yourself. Definitely more work but you can easily get rid of all that main thread time waiting because you can time stuff yourself.
As I thought, my planned optimizations didn’t help. We have eliminated all the methods that cause early completes of the jobs by batching them and scheduling at the end, just before calling ScriptableRenderContext.Submit(). The execution time of the ScriptableRenderContext.Cull() varies wildly.
Also found this weird behaviour on the pic. We use ECS for a rendering feature and sometimes the main thread will start executing a couple of jobs regarding the culling (considering that the Cull() method exited early enough for them to even be present at that point). Not a big problem overall, just an interesting thing to point out.
