ElightenRuntimeManager consuming alot of cpu even when GI is completely disabled

This is new in 5.2:
We have all GI options disabled in the lighting settings and even set BounceIntensity to 0 in all lights but the EnlightenRuntimeManager.PostUpdate is still present in the profiler with around 1ms of cpu time. All scenes got slower due to the 5.2 update. PostUpdate seems to Remove, Add and Sort all lights each frame and then do nothing with them.

Is there a way to work around this until this is fixed?

 

Windows Standalone Player.

Our lighting settings in all scenes:

 

Can you estimate when this will be fixed?

 

We're running into a similar issue. On some machines (like a laptop with an Nvidia optimius GPU) we get multiple 30ms spikes a few times per second. The profiler shows the following as the culprit:

• EnlightenRuntimeManager.PostUpdate
  • UpdateEnvironmentLighting
    • GFX.ReadbackImage (60%)
    • WaitForPresent (40%)

All our lights are set to Realtime, bounce set to 0, and lightmapping/GI is disabled for all scenes. This didn't happen in 5.0.x, but is happening now in 5.2.1p2.

 

Thanks for the pointers! Turns out the TimeOfDay plugin is updating some state which triggers this new behaviour. It's still unusually slow, but we'll look into it further.



It's worth noting that on other machines we see PostUpdate, but it does essentially nothing, like it's supposed to with all GI disabled.

 

@KEngelstoft I am having similar issue. enlightenruntimemanager postupdate takes up about 10ms per frame on my android phone. I have GI disabled and no lights, no skybox in the scene. (5.2.2f1)
Is there a workaround for that or another way to disable gi?

 

Confirmed GI can be disabled for android mobile successfully in 5.3.0f4, using lighting settings per julian.moschuering


GI Enlighten was adding 16 to 33ms per frame while enabled: (45% of total CPU @ 73ms/frame)


same scene after GI disabled: Camera.Render is the major factor (38% of total CPU at 45ms/frame)

 

Hey I have the same problem with a desktop PC. It eats up 13MS on the CPU, and it happens only in the player.

Any ideas?

 

I have the same problem when doing a development build plugged in to the profiler. The EnlightenRuntimeManager process takes my scene from 90 FPS to 15fps in continuous spikes!

 

I have completely disabled the realtime GI and made a build just to see if that is the problem. However after I disable it it still works as bad as it did before, but there is no other time taken by the 'EnlightenRuntimeManager'.

I think that the time that we are shown there is a false positive. Try building your scene without realtime GI and see where the problem really is. In my scene it was the fact that it was not very optimized where it comes to LOD's & stuff.

 

It seems my problem was own idiocy, which is nearly always the problem

I have a directional light moving over the scene via script and a shader on the skybox updating every 0.5 seconds, then ambient lighting updated according to the skybox. I'm using Unity 5.6 and had realtime global illumination checked on. No wonder it was causing such issues as I was effectively asking Unity to recompute the GI every few frames when the lighting was effectively changing every 0.5 seconds.

Disabling realtime GI brought the FPS back to what I was expecting again. I'm a little confused about why this same problem wasn't showing up when running the scene in Play mode in the editor but then I'm told a development build always gives a more accurate profiler response.

 

Yea, limit the light modifications. And yea it only shows in a build, it doesn't show up in the editor. But if you still need realtime GI, optimize that lighting code and test again.

 

UpdateEnvironmentLighting is consuming a ton, any way to optimise this? All lights have 0 indirect multiply.

 

Still Having this issue on 2019.1. Did anyone fix this?

 

I am getting a similar issue using LWRP on 2019.2.13 (the version suggested from Oculus for the Oculus GO platform).
Everything is off, I don't have a single light in the scene as I'm passing direction and color of the sun from a script as global variables into the shaders (once per scene load).
Still the GI inspector is showing me something is working and taking up to around 5ms (and I am really greedy in performance as I am working in VR and Oculus doesn't accepts applications running under 60fps for 45 minutes straight - loading screens apart).



Inspected from the device




Fog is off, LightmapZero is a lightmap parameters setting where I set everything down to lowest possible as I had no clue anymore on what to do (I have to admit I never used GI and don't know the single function of each. I just am failing at disabling it)

 

Any updates here? I am facing the same thing. It is only 0.18 ms for me. But 0.18 ms for a disabled feature??

 

2019.4.14f1 right? not a typo? Because I was testing in 2019.4.17f1 and seeing this bug.

 

We see this behavior in our game in 2020.3.14f1. We have no baked lightmaps, no baked lights, and baked lighting is disabled. It still uses 9ms per frame running Englighten. If we *enable* baked lighting, it goes down to 0.4ms (still a very annoying cost given that we don't want baked light).

 

I'm also seeing what @bfoddy reports. I'm using 2021.1.19f. One light source in the scene: directional set to Realtime with no bounces; realtime GI off; no baked light maps; no baked lights. The EditorLoop can take up to 49ms. If you turn on baked lighting, it goes down to a max of 19ms. (This is being profiled in the Editor and it is the EditorLoop that consumes the most time in regular spikes related to EnlightenRuntimeManager.)

I know that much of this will not affect the build - which does run at a stable rate, with fewer spikes - but this really affects performance in-Editor, making it almost unplayable for rapid testing there (unless I turn on baked lighting, in which case the framerate in-Editor IS acceptable).

In my case, I am manipulating the skybox every Update because I am changing the Sun's rotation in a simple day/night system. I know that this is resource-intensive in terms of ambient lighting calculations. Also, this is running on a MacBook Pro with Integrated graphics, so this is asking a lot already, I know.

What is interesting is that in 2019.2, where much of this project was developed, these Enlighten-related in-Editor spikes did not exist.

 

@KEngelstoft Hello there! I am having a huge problem with this EnlightenRuntimeManager... I am using untiy 2121.3.10f1. It takes 65 SECONDS!!!! to unload. How can this be fixed ?? i dont have any active realtime lights on unload, only baked and mixed light