I *know* SunBurn should never allocate while running, but right now I'm really confused as to where the allocations might be coming. There is an area that makes the framerate drop dramatically, it coincides with allocations.
I've profiled using CLR Profiler my game several times. It seems the allocation are of a SunBurn type I'm not using (so I assume it's internal) and of Matrix[], which I'm not using either.
My setup is the following: I have SunBurn 1.3.1 Pro, I'm using primitives, based on the Primitives 3D sample from XNA, as placeholders, some are very large, they are meant to be buildings. Some are showing minor glitches with SunBurn that I hadn't seen with pure XNA (white line along an edge, under certain camera angles).
Is SunBurn somehow allocating stuff when an object comes for the first time 'on screen'? Should it be affected by very large triangles with only a diffuse color and no texture?
I can provide an exe and some source code if needed.
You can look who's allocating by rightclicking the object and click "Who allocated?..." You should be able to find a lot of info about what object/class initiated your allocation.
Contributor on the SunBurn sgMotion Animation Library open source project.
Hi Julien,
Can you post the class the allocations are originating in?
The only matrix array I can think of in SunBurn is related to skinning, but the array (which is created within the SunBurn LightingEffect) is cached after creation and shouldn't be created again. You'll likely see the allocation when an effect is rendered for the first time, but should not see additional allocations afterward.
Let me know if this helps!
Follow me on Twitter – development and personal tweetsAwesome XNA Videos – Lighting, Rendering, and game videos
Well, you're right about who creates the Matrix array, but it definitely occurs after creation.
I forgot to mention in my previous post, I'm also using sgMotion 1.1 with its sample model. I'm not doing anything fancy with it, just loading, updating world matrix and playing blended animations.
Here is the last part of a call stack when I look at an allocation of '3 instances of Matrix[] 18 kB total':
Microsoft.Xna.Framework.Game::DrawFrame void (): 14 kB (100,00%) PelletApoc.PelletApocGame::Draw void (): 14 kB (100,00%) SynapseGaming.LightingSystem.Rendering.Forward.RenderManager::Render void (): 14 kB (100,00%) SynapseGaming.LightingSystem.Rendering.Forward.RenderManager::r void (<UNKNOWN> void N.O <UNKNOWN>): 14 kB (100,00%) SynapseGaming.LightingSystem.Rendering.Forward.RenderManager::r void (<UNKNOWN> void SynapseGaming.LightingSystem.Rendering.RenderableMesh bool): 14 kB (100,00%) SynapseGaming.LightingSystem.Effects.BaseSkinnedEffect::set_SkinBones void ([]): 14 kB (100,00%) Microsoft.Xna.Framework.Matrix [] : 14 kB (100,00%)
Same thing for an allocation of RenderableMesh[] (6 instances, 12 kB) :
Microsoft.Xna.Framework.Game::DrawFrame void (): 6,1 kB (100,00%) PelletApoc.PelletApocGame::Draw void (): 6,1 kB (100,00%) SynapseGaming.LightingSystem.Core.SceneInterface::BeginFrameRendering void (SynapseGaming.LightingSystem.Core.ISceneState): 6,1 kB (100,00%) SynapseGaming.LightingSystem.Rendering.Forward.RenderManager::BeginFrameRendering void (SynapseGaming.LightingSystem.Core.ISceneState): 6,1 kB (100,00%) N. : 6,1 kB (100,00%) N.w::r void (SynapseGaming.LightingSystem.Rendering.RenderableMesh): 6,1 kB (100,00%) System.Collections.Generic.List<T>::Add void (<UNKNOWN>): 6,1 kB (100,00%) System.Collections.Generic.List<T>::EnsureCapacity void (int32): 6,1 kB (100,00%) System.Collections.Generic.List<T>::set_Capacity void (int32): 6,1 kB (100,00%) SynapseGaming.LightingSystem.Rendering.RenderableMesh [] : 6,1 kB (100,00%)
I've just tried NOT updating my model, not changing animations, and it's somehow worse. I see several series of allocations, of more types (includes Generic.List<T> from a PooledFactory, somewhere deep into obfuscated code, plus an obfuscated N.O [], plus N.O, plus N.w.
I will double check my code for stupidity (like submitting objects repetitively or some such), but I've done that yersterday already :S
I double checked the Skinned Model example and the sgMotion sample, both are running without memory allocations.
By default the CLRProfiler will capture all allocations from when the game starts, make sure to only capture the in-level allocations.
The best way to do this is to start the profiler, uncheck "Profiling Active", browse for and start the game, load up a level, then check "Profiling Active". After a period of time uncheck "Profiling Active" (while still in the level) - this will return the allocations made while the level is running and will eliminate any allocations necessary for loading and initially displaying the level.
I've found the major slowdown issue from my code that was occurring near world's origin. So my framerate isn't halved any longer there, but... I still have allocations happening.
About the CLR Profiler, I've integrated the CLRProfilerControl in my code to disable logging until the end of LoadingContent, that was before my previous post. Now I've tried as you suggested using the CLR Profiler GUI, and I still see allocations.
I've just made a new run on XBox, checking allocations with XNA Remote Performance Monitor and I can confirm allocations. Both strings and managed objects are allocated like crazy when I start moving when I visit places I haven't been to before in my small level (relatively speaking). If I stay in places already seen, there are no allocations, and the game runs smoothly (I'm around 120 fps when I don't lock to 60).
I can send a build if you want. Or just tell me there is a magic switch somewhere to allocate everything upfront, at the cost of a loading time :-)
Allocating memory isn't really an issue in itself. If the allocations don't hitch your framerates you should be fine. Single allocations will always happen and don't need over-optimization.
If you want to allocate beforehand, loadcontent() is the easiest place to do so. I'd only mess with this if you're having problems with your framerates.
"Optimize because you have to, not because you can"
Thanks for the advice, but I already know that.
Yes I'm worried about my framerate, because it feels choppy right now on the XBox (it's 80 fps unlimited, 120 fps without the allocations/garbage collections, but the level is almost empty, so memory structure is fast to parse), and I have yet to fill the game with things that will put a heavy load on the CPU (like collision detection between more than a couple of entities, AI, etc). If it's only happening when I'm using geometric primitives (ie passing VertexBuffer, IndexBuffer & co), I'm fine with it, because it won't happen in the final game, they are only placeholders.
But if it's a matter of, for instance, scaling the scene down (I have setup a 'large scale' camera, with view distance of 5000, I have objects that are over 2000 world units wide) because for some reason, it allows better performance, I want to know it now, not when the models will be all done and imported.
Premature optimization is bad, but doing something the right way from the start is a way to save a lot of energy for important things, like getting the gameplay right, instead of rewriting the core engine.
Julien Villers:I can send a build if you want.
Definitely, that will help us track down any allocations.
Please feel free to strip down the project and remove anything you don't want to send over, we only need a few placeholder objects (simple boxes are fine) that reproduce the problem and the minimal code necessary to place the objects in the scene.
You can send the test project over by responding to the email notification you received from this thread, just put something like "For: JohnK" in the body and the email will be sent to me.
Thanks!
Would a packaged exe + data suffice, or would you need the sources?
I'm not too worried about sending you my project, but there's a lot of code that would be irrelevant to you, and it's a big tedious task to strip it all. I've done it before when investigating the frame rate bug, I'd rather not do it again if it isn't really needed.
We prefer to have the code available, it helps us track down what's happening.
Are you able to see the same problem in the SunBurn starter kits after adding your assets? If so it would make a simpler test case.
Julien, if it's any help we've sent them the full source code and assets for both Avatar Land and most of The MANLY Game to help diagnose problems. No clones have popped up yet, so I trust them. :)
Well thanks for the advice ;-) I'm trusting enough, I just wouldn't want to waste their time.
I'll prepare something today and send it over.
I ran through your test project and the allocations did seem a little high. It looks like this is due to the number of unique effects / materials in the scene - it appears every block in the wall has a unique effect, which could have performance implications down the road (unique effects prevent batching).
The allocations, however only occur the first time an effect is rendered (and never again for the effect). Even better the 1.3.2 branch already has enhancements that eliminate the matrix array related allocations, so when it's available the update will already make a huge difference.
Mmmm OK!
The effect per block isn't such a big deal then, it won't occur with actual data, only those placeholders.
And great news for the new version :)
Thanks a lot for your time, your reputation is well earned ;-)