Jump to content

Edit History

Please note that revisions older than 365 days are pruned and will no longer show here
Blake_

Blake_

17 hours ago, faatal said:

This is not an exact science, since Unity does a lot of things in the background that we don't have control over.

 

1 Depends on the asset, but everything uses some CPU and many assets use system RAM or VRAM or both. Unloading also tends to be delayed because many resources are not specifically tracked by the game and flushed by Unity by UnloadUnusedAssets, which is slow, so not called very often.

 

2 Only the gfx driver and Windows really know how much VRAM is in use and VRAM use is often padded to a higher amount that what it actually needs. Microsoft is working on tech to report more info back, but then Unity has to support it to, so maybe in a few years.

 

3 Not sure. There are various pools of memory in use, which grow and shrink.

 

4 Using the mem console command does call UnloadUnusedAssets, but it won't clear memory being used by resources, since many resources are loaded once and they would never come back. Also the Mono mem heap can never shrink, short of restarting the game.

 

5 We have the Unity Profiler. For you, FPS is a good indicator of CPU use. Use console command "gfx g fps 200" to graph it.

 

Our micro stutter is generally from CPU use spiking on a single frame. I've been working to find spikes and spread work across frames. Some of those changes have already been done for A20, but more can still be done.

 

We are moving to Unity LTS releases, so A20 should be on 2019.4. We won't try 2020 LTS until after A20.x in second half of next year.

 

Thank you for the quick response. I kind of expected some of the memory usage answers, which are not really great news as they depend on Unity improvements.

 

I don't expect huge performance out of my Single Channel 8gb DDR2 1666Mhz RAM (833Mhz double rate)  for those intensive juggling tasks, yet I had to ask in order to separate CPU from GPU situations.

 

I will be using gfx g 200 for my next test to help things further.  FPS do drop, but not always . That "not always" alone could hint at a bigger problem. 

 

EDIT: Further testing revealed that 99.9%  of the performance problems (for a Windows with Nvidia GPU system ) are CPU related and happen in these cases:

 

-Sleeper/entity spawn, respawn and relocation after reentering the area. More than 1 sleeper can be expected to drop fps in a 4C/8T 2.7ghz system.

 

-Music uses CPU. It has a generally low CPU overhead on its own, but can worsen the experience if added to any other CPU situation, doesn't matter how low. It has a hard to spot impact on my system. I spotted it nevertheless, but never alone. Too much stop, start, pause, transition in a short timeframe generates spikes that make the system susceptible if there are other CPU bottlenecks close by.

 

-Particles, Collapses, many entities on screen, big POIs with too many Zds/rooms and also in any situation with many vertex calculations. Texture Atlas reading also uses CPU yet it is almost at its prime currently, so it probably can't get better than this in many cases.

 

-Loading and unloading of assets uses CPU , external profiling reveals that the overhead it's not constant and comes in spikes/bursts, too big for confort. Better systems should not notice these spikes, yet I do, every single time (microstutters). I don't have a clue on how to fix this. I mean maybe unplugging the power supply , blowing and plugging it again or also punching the screen while swearing in Navajo. I got nothing.

 

-Wandering hordes still generate stutters. At least they do not freeze the system for 5 seconds anymore. Just the 1 second it takes for fps to instantly drop 30-45 frames out of nowhere, it is noticeable but playable. Maybe a bit more spread would help..... 1 and a half seconds between spawns ? lol.

 

In order to clean test all of this I did a full wipe/formatting of my system on top of my OCD for absolutely no programs in the background (except the profiling). No EAC nor Gamesparks either.

 

I hope this helps to confirm currently known issues.

 

Salutations.

 

Blake_

Blake_

3 hours ago, faatal said:

This is not an exact science, since Unity does a lot of things in the background that we don't have control over.

 

1 Depends on the asset, but everything uses some CPU and many assets use system RAM or VRAM or both. Unloading also tends to be delayed because many resources are not specifically tracked by the game and flushed by Unity by UnloadUnusedAssets, which is slow, so not called very often.

 

2 Only the gfx driver and Windows really know how much VRAM is in use and VRAM use is often padded to a higher amount that what it actually needs. Microsoft is working on tech to report more info back, but then Unity has to support it to, so maybe in a few years.

 

3 Not sure. There are various pools of memory in use, which grow and shrink.

 

4 Using the mem console command does call UnloadUnusedAssets, but it won't clear memory being used by resources, since many resources are loaded once and they would never come back. Also the Mono mem heap can never shrink, short of restarting the game.

 

5 We have the Unity Profiler. For you, FPS is a good indicator of CPU use. Use console command "gfx g fps 200" to graph it.

 

Our micro stutter is generally from CPU use spiking on a single frame. I've been working to find spikes and spread work across frames. Some of those changes have already been done for A20, but more can still be done.

 

We are moving to Unity LTS releases, so A20 should be on 2019.4. We won't try 2020 LTS until after A20.x in second half of next year.

 

Thank you for the quick response. I kind of expected some of the memory usage answers, which are not really great news as they depend on Unity improvements.

 

I don't expect huge performance out of my Single Channel 8gb DDR2 1666Mhz RAM (833Mhz double rate)  for those intensive juggling tasks, yet I had to ask in order to separate CPU from GPU situations.

 

I will be using gfx g 200 for my next test to help things further.  FPS do drop, but not always . That "not always" alone could hint at a bigger problem. 

×
×
  • Create New...