Shipping Build Performance Lower than Test and Development Configs

[StBlueFire (BlueFireSR)]

Currently running 4.27 Chaos.

Reproduction steps. Load any secondary level and then move my character to the new level.

If I make a Development or Test packaged build my FPS is 80.

When I make the same package with the Shipping config my fps drops to around 41 FPS.

This is super difficult because if I can get the profiling tools I feel like I can solve any problem. But you can’t get profiling in Shipping.

I have tried (useful collation of solutions I’ve seen that might solve your problem):

1. Cleaning out intermediate/binaries/DDC/saved for both the project and engine.
2. Ensured that SteamVR plugin has been disabled and that RenderTargetMultiplier does not appear. [not a VR game]
3. Ensured Lightmassimportancevolumes are deleted. [we only use DynamicLighting, if using static lighting try using multiple small ones rather than a single large one]
4. Ensured frame rate smoothing is turned off in project settings.
5. Ensured configs files matched between the Development and Shipping configs.
6. Ensured that I have the latest video card drivers.

[StBlueFire (BlueFireSR)]

Just an update to this thread. It seems to be PC specific. I found that after testing with additional hardware it appears to be limited to just my PC (2080 and i7-5820k). Might be worthwhile to test on other PCs if you run into this. Even on lower hardware (a 1080 with no DLSS) it did not have this issue.

My “best” guess is it has something to do with Auto DLSS settings as I can get closer if I set it UltraPerformance on both builds. Strangely turning DLSS off tanks my performance in both builds from 70FPS to 1 FPS, so something is going on there.

Reinstalling a clean video card driver, doing sfc /scannow, and clean installing the game multiple times had no effect.

I’ll update again if I figure out how to get back to normal performance.

[StBlueFire (BlueFireSR)]

Eventually we were able to get this problem to happen on a development build and found out that it was PostInitViews FlushDel with RenderQueryResult being the lowest level the profiler show.

This is the only place I can even see someone having the same problem:

Draw Call problem: PostInitViews FlushDel

Greetings, I have a fairly large open world level that I am trying to optimize. By using “stat unit” I can see that the scene is currently draw thread bound. Using “stat initviews” has shown me that “PostInitViews FlushDel” is taking a whopping 11 ms–totally unacceptable! Here is a screen shot: [338906-postinitviews-flushdel.jpg] I have been unable to find any documentation or discussion about what “PostInitViews FlushDel” is. My foliage does appear to be the culprit because when I hide all…

Will update as we figure out the solution (hopefully).

[StBlueFire (BlueFireSR)]

Another update in the journey. I went through EVERY showflag in development builds and tried them out. There are a few interesting things of note.

1. showflag.translucency 0 moves the FPS drag from PostInitViews FlushDel to GPU Basepass. Still very similar FPS just getting tracked under something different.
2. showflag.PostProcessing 0 does improve framerate significantly, but does not get rid of the problem in number 1.
3. showflag.StaticMeshes 0 completely fixes the FPS. The strange thing is that on other hardware this doesn’t significantly increase the FPS. This further leads me to believe that the issue lies in some kind of bad compile for the textures.
4. An old similar problem we had in this game has resurfaced. Tiny black dot flicker on the screen for just a single frame. See attached video for issue. It flickers so I can never seem to get a screenshot of it.
   
5. When showflag.translucency 0 is set. The new rend bottleneck with a profile is SlateDrawWindowsCommand->EndDrawingViewport_Dispatch->Present Time
   
   

[StBlueFire (BlueFireSR)]

So the ultimate fix we found was that we found was that in
Engine/Config/BaseScalability.ini we had accidentally set:
r.VolumetricFog.GridPixelSize=3
instead of:
r.VolumetricFog.GridPixelSize=8

Even though our [Project]/Config/DefaultScalability.ini had
r.VolumetricFog.GridSizeZ=64

Which I incorrectly identified as the same config setting.

Changing back to r.VolumetricFog.GridPixelSize=8 instantly fixed performance and corrected the black dots. I believe the black dots just to be a side effect of the GPU working too hard.

The reason that only 2 PCs out of our group had this issue is it helped us identify a bug where the settings UI incorrectly told people they were on Epic quality settings when they were not, anyone who went to epic quality (by reducing then resetting to epic quality) immediately had the bug. Only the two of us had done reinstalls that happened to correctly set us to Epic Settings.

Lesson Learned:

1. I thought I had changed this once but due to a P4VS and UE4 P4 integration it reverted my change instead of submitting. So always double check the config files actually get pushed into source control.
2. Really enforce your team to put scalability settings in the project level when possible instead of overriding the engine config to make config changes easy to track in one spot. But always go check for engine changes.
3. Invest 15 minutes in writing your scalability settings to logs so you can quickly see if there are any differences in settings between a dev/shipping/editor build. For shipping just have it show somewhere in the UI if a special key is pressed.