What is all being sent to the OcclusionSubmittedFence and why does it slowly kill my scene?
I’m in the process of testing optimization of lighting and particle systems and I’ve finally figured out the culprit of what has been slowly killing my scene the longer I have it open (sort of). The only noticeable change I can find in my scene data is the OcclusionSubmittedFence Wait slowly takes up more and more ms in the scene.
Some background info:
All the lights are Dynamic and RayTraced.
I’ve checked all my particle systems and they are all setup properly to remove particles after lifetime. I’ve also confirmed through **stat Niagara **that my particle count is stable.
The only movement happening the scene are the lights which are set to slightly wiggle to better emulate the fire effect.
The fog in the scene is setup through a particle system with a material that uses SphereMask in its material.
I’ve done some more testing and setup a scene that had none of my Niagara particle systems and found that that completely reduced the OcclusionSubmittedFence Wait all the way to 0. So this is a performance hit that is definitely being caused by my particle systems.
I ran some stat checks on my particle systems and I still cannot determine what could be causing this bottleneck. The stats on the systems remain consistent during the entirety of my tests (I included the Niagara stats in the new screen shots). There are no additionally draw calls, and the particles are remaining with a few hundred range in terms of their count.
I’ve done some more testing and I’ve found that the issue only occurs when ray tracing is enable with my Niagara particle systems active. If I disable ray-tracing it solves the issue. If I disable all my particle systems it resolves the issue. Its only when both are active at the same time that this issue occurs. I’m going to setup some cascade versions of my particle systems to see if its Niagara specific.
So I ran a test today and setup a Cascade particle system that was (practically) the same as my Niagara system. I ran a build on both versions and let the game sit for a solid 10 minutes on both with this test scene. The Cascade system has consistent stats and performance during the entire 10 minutes. The Niagara system as expected built up more and more data under the OcclusionSubmittedFence Wait. Eventually this gets to the point where it pushes too much data and starts to slow down performance. (I haven’t found any way to clear this data or even what is being contained in it)
So as it stands I can only come to the conclusion that this is a bug with using Niagara particle systems within a Ray-Traced real time project. If anyone else has any similar examples or if they have examples that show this isn’t the case please post!
I did some testing with the new 4.25 update to see if the issue was still persistent and unfortunately it is still occurring. I found that if I setup my Niagara particle systems inside a separate sub level and then unload and reload that level, the occlusionsubbmitedfence wait will reset. (Please keep in mind this scene is setup as an extreme example in order to help speed up the rate at which this occurs so I’m not waiting a long time to illustrate the issue)
Edit: If you set
r.AllowOcclusionQueries 0
this also removes this data. However this is obviously not ideal since it removes all hardware culling from the scene, so nothing gets occluded from visibility checks. However, this at least helps to confirm that this is some sort of occlusion check that is being made on the Niagara systems.
Thanks for the information @Luoshuang (also I’ve seen your contributions with the GPU lightmass, terrific job). I happened to find a similar post where you posted this and I think you intended to include some more information but missed it so I included it below
I capped my fps to 10 as you suggested and it indeed shows quite different profile results. In this case it seems the main culprit is the GatherRayTracingWorldInstances data pass. So perhaps this has to do with a difference in how the engine is processing niagara particle instances in ray tracing vs the older cascade particle instances (as previously stated I don’t run into issues if I use cascade particle systems in this setup). I’ll have to try and think of other ways I can try to debug and test from here to see if I can find a solution to this.
I am so completely out of my depth haha
Tried to capture some data out of the Unreal Insights tool, can’t upload the file as its over 190MB but I think I took some screen shots of relevant data.
