Loading a scene async in additive creates spikes on the GPU

So, in our game, Kôna, we put houses of our environment in separate scenes, and we load them async and additively. We put Application.backgroundLoadingPriority to Low, because we want to see the fewest stuttering and the best framerate possible.

So, after the loading, the system integrates the scene (for Awake() calls and such), which creates a spike, and that I can understand. However, while the scene is loading, there are strange peaks that seems to originate from the GPU, and that are often way heavier than the last integration peak. This happens both in a build and in the editor.

So I decided to setup a new project, in which I loaded a scene containing a somewhat heavy mansion model. This scene has NO baked GI. I built the game, profiled the loading, and got this:



The actual last integration spike is the small purple CPU bump. The big 87.778 ms one happens while the level is loading and it is awkwardly flagged as a RenderTexture.SetActive on the GPU and Gfx.WaitForPresent on the CPU. What is even weirder, is that I've seen some of those spikes being flagged as MeshSkinning.Update or ReflectionProbe.BlendCubemap in Kôna. My guess is that some kind of thread lock on the GPU sometime happens while loading scenes.

This single 88 ms spike is not that bad compared to several spikes of 1 or 2 seconds I've seen in Kôna, where we have more complex scenes with baked GI. So, has anybody else encountered this? Is that a bug or by design? Is there any workaround, except splitting scenes in smaller scenes (which we tried, to mixed results)? I will probably file a bug soon if I see no way around this.

 

Seems like you have something that actively uses RenderTexture when Awake() is called or such. Was that UMA maybe? Or some other objects with RenderTexture trick to render texture from multiple textures using GPU. Or maybe unity internally does same thing to batch during scene load? Don't know. What I know is GPU is overloaded and causes graphics driver to wait for it which causes your Gfx.WaitForPresent spike on CPU too.

 

That behaviour happens in an empty new project, and the only objects that are loaded are meshes with materials and textures. No script other than one setting Application.backgroundLoadingPriority to Low and loading the scene async when any button is pressed. The only shader used is the standard shader. No baked GI. Quality and Player settings are untouched. So I don't know what I can be doing wrong, but it would be some very basic stuff.

 

Oh, and I tried to mess with Async Upload time slice and ring buffer size, but it didn't solve the issue.

 

Might be unrelated but did you create a package of preloaded shaders from the graphics project settings window ? I remember before we did this loading visual assets would spike big time because of shader compilation.

 

I did not at first, but I just tried that and I still get stutters. However, the last bump is now even smaller.

 

So, I decided to file a bug. Here it is:

https://fogbugz.unity3d.com/default.asp?765766_qbd1keock6sshi07

 

I have the exact same problem and I've been trying to track it for very long now.
Interestingly this happens only the first time a scene is loaded Async during a particular session (be it editor or in-game).

I have a feeling it's related to texture loading since scenes with no textures (but with many game objects) doesn't cause this problem.
Could also be either particle system loading or shader loading, since I have a few of those in the scenes were the lag spikes appear.

 

The problem is gone if I remove mipmapping, increase the ring buffer size of texture loading and compress all textures. So yea... seems tightly connected to texture loading.

 

I tried to increase the ring buffer size, even to ludicrous sizes like 512 MB, and I still got the issue. I can't just remove mipmapping and compress textures further without sacrificing a lot of the visual appeal of the game. This is a big issue for us, since the spikes are really lenghty and annoying.

 

Yea very annoying for me too. It seems as if the async loading doesn't load textures very good. I haven't found any way other than to just reduce visual quality/fidelity (by compressing, lowering resolution and removing mipmaps) to not get the hiccups and spikes.

Another way is to preload ALL texture assets. But then again, that'd be pretty hard on the memory. :/

 

My bet problem is same as when calling Texture2D.Apply() - it just takes too long to load texture to GPU. And it can't be threaded.
You could try to separate textures to be loaded by scenes into several scenes and load them in order or somehow preload them separately to distribute spikes over time.

 

Do you think that simply loading prefabs containing those textures would automatically make them load to the GPU and trigger those spikes ahead of time? I know a lot about Unity, but I still don't know anything about how it manages the texture memory on the GPU.

 

Actually, I don't know that myself. But I would guess so as they can find unused assets and, thus, they know which assets are loaded and which are not. It would've be stupid not to use that in their internal code to optimize loading.
I suggest you test it and see if it helps.

 

Alright, I'll test different solutions and let everyone know if I find a workaround.

 

I've actually tried this. And it does help... but only if I load EVERYTHING before starting my game.. which kind of takes away the whole point with loading and async loading.

I think Unity has a long way to go with their engine. =/ I'm sure these problems stem from multi-platform "supportiveness".

 

Well, I got an update saying my bug was reproduced. I just hope they find a way to fix this.

 

This is the bug, you can vote for it: https://issuetracker.unity3d.com/is...c-creates-huge-performance-spikes-for-the-gpu

 

Running into the same thing, will upvote now. Huge ugly spike that'll probably cause console TCR issues.

 

Seeing this as well on 5.3.4p1, I upvoted the issue. Any news from QA? Have you tried the repro in 5.4, see if UT fixed it by any chance?

 

No, nothing new since they reproduced it.

 

The bug has been closed with the "by design" tag. Is this a joke? May we one day get a truly async loading method? Or are we stuck forever with creating dummy PS3-era loading corridors?

 

Jesus, it took them a year to come back and say that..

 

I'm still having this problem...

 

Also having it. This is ridiculous.