XNA mesh.Draw() takes the longest CPU time

Question

We have a problem. Our game steadily slows down as we increase the number of models we draw. When the number reaches 100 - FPS is dead. Our humble tests showed that the reason is not GPU. This is what we did:

Rendered models with the most basic shader code - nothing changed;
Checked the NVidia NSigt metrics - GPU was less and less loaded per second as we increased number of models;

At the same time, a simple Windows Task manager showed that, as the number of models rise, the load increases (up to a 100%) on the single CPU core that our game uses. So we are pretty sure our game is running slowly because of the CPU.

We then moved on and tried to identify which line exactly causes the problem. We used c# TimeSpan metrics and timers for that. Our research showed that the biggest cause of the slow performance is... mesh.Draw() function used by every model that we draw.

We tried commenting this very line and things improved instantly (ofc. nothing was drawn on the screen).

So the question is, what are we to conclude from this? mesh.Draw is a closed function and we cannot optimize it. Trying to bruteforce parallel it is impossible (i guess it was natural). But something tells me that we need to look elswhere if this function is slowing the CPU, the question is where?

Update: here is the code I use to draw the model: public void Draw(...) { int index = 0;

            int i = 0;

            foreach (ModelMesh mesh in Actor.Model.Meshes)
            {

                bool isDrawable = false;
                #region Check if this ModelMesh needs to be drawn according to PartsToDraw (string) list.
                foreach (string s in PartsToDraw)
                    if (s == mesh.Name)
                        isDrawable = true;
                #endregion

                if (isDrawable)
                {
                    int effectStartIndex = index;
                    foreach (Effect effect in mesh.Effects)
                    {
                        if (Actor.MatrixPaletteParams[index] != null)
                        {
                            Actor.WorldParams[index].SetValue(World);
                            Actor.MatrixPaletteParams[index].SetValue(Actor.Palette[i]);
                        }
                        else
                            Actor.WorldParams[index].SetValue(Actor.Pose[mesh.ParentBone.Index] * World);

                        if (drawType != null && drawType.DrawShadow)
                            SetShadowEffectParameters(effect, renderer, drawType.DrawShadowMort);
                        else
                        {
                            SetCommonEffectParameters(effect, renderer);
                            SetLitEffectParameters(effect, renderer, drawType);
                        }

                        index++;
                    }
                }
                else
                    index++;

                if (isDrawable)
                    mesh.Draw();

                i++;
            }
        }

"Set...EfectParameters" methods mostly consist of effect.Parameters["SomeParameter"].SetValue() calls. I pass around 30 parameters to the GPU there, mostly floats, matrices and bools. Moreover each ModelMesh has three textures that it passes into the GPU. I have no idea how fast this works and if it can be optimized. It should be fast.

You should also note that I draw a skeletaly animated model using Dastle's XNA Animation Component library. Once again, I understand that this might be the reason behind lags, and we did find the weak spot of the animation code, but why on Earth does the metrics show that mesh.Draw is the slowest spot? What is happening there?

Is this in a release build? I kinda remember that function being quite slow in debug mode. — Roy T., Dec 04 '13 at 10:21
Draw commands are bound to be slow, thats why you try to pack and minimize statechanges, drawcalls as much as you can. — Tordin, Dec 04 '13 at 10:27
Ok, ok but WHAT should I concentrate on? Should I try to reduce effect.Parameters calls? I know that instancing is the way to go, but I debugged Sait's Row 4 with NVidia NSight and saw that they use NO instancing whatsoever, and it runs at INSANE speed with over 4000 draw calls (can't remember acurately but the timeline was COMPLETELY blue while in our game it has a number of thin stripes across it's white background). — cubrman, Dec 04 '13 at 10:33
Yes, thats common. A modern engine can easily draw ~10k drawcalls just fine. It´s hard to say with outseeing any code. if you could update with your draw code and how you traverse on your sceen it would be greate. — Tordin, Dec 04 '13 at 11:09
The release version of the game is as slow as the debug one. I have updated the question to include the code. — cubrman, Dec 04 '13 at 13:18
So how does your mesh look like? could you take a printscreen of the wirefrmae&solid render of the world? — Tordin, Dec 04 '13 at 15:16
possible duplicate of Information about rendering, batches, the graphical card, performance etc. + XNA? — Seth Battin, Dec 06 '13 at 23:21

score -1 · Accepted Answer · edited Apr 13 '17 at 12:18

-1

It's really weird that no one answered my question, but the truth is I simply hit a batch limit. Indeed Draw takes the longest time on the CPU and that is why you need to limit the number of draw calls per frame. Andrew Russell has a brilliant series of answers here about this problem: https://gamedev.stackexchange.com/a/37794/31853

edited Apr 13 '17 at 12:18

Community

1

answered Dec 06 '13 at 08:39

cubrman

1,551
1
18
31

So how did you resolve your problem, knowing this? – ashes999 Dec 06 '13 at 12:20
I am working towards using instancing, just like Andrew suggests, and I am asking this question: http://gamedev.stackexchange.com/questions/66932/saints-row-the-third-uses-dx9-and-has-over-7000-draw-calls-per-frame-0-o – cubrman Dec 06 '13 at 18:28
-1, this answer doesn't actually address the problem described in the question. You should re-word one or both to match. – Dec 06 '13 at 18:43
My question has already been answered before, I did not know that like many others that come here. I have posted a link to the actual answer and that was clear enough from my point of view. But you are an admin, so I have added even more explanations. If this is not enough - feel free to edit my answer. – cubrman Dec 06 '13 at 19:26
I seriously doubt draw calls are so limited that you cant display 100 objects at a decent framerate. Try a fifty thousand objects, that might be limiting without instancing on any CPU that came out in the last 5 years. – TravisG Dec 06 '13 at 20:31
Naturally we have some shaders to do and some parameters to set and we are not uber-professionals to make it work as good as you suggest. But it would be nice to hear HOW you make it work, instead of just boasting it. – cubrman Dec 06 '13 at 20:44
I don't know how to solve your problem, I just wanted to suggest that you're most likely not draw call bound. – TravisG Dec 06 '13 at 21:07
Is it possible that - rather than being batch limited as such - you are simply CPU limited? (Doing too much non-drawing CPU stuff.) – Andrew Russell Dec 07 '13 at 07:54

XNA mesh.Draw() takes the longest CPU time

1 Answers1