[mdx] Cpu usage on mesh.DrawSubset()
Author
Recently i was profiling my engine and i was surprised by the fact that %54 of cpu usage was burning in mesh.DrawSubset() method. I want to know should I load my meshes in my own vertex/index buffers and then render them or this is related to creating big chunks of vertex buffers for rendering on newer graphic card?
Since you are profiling, I'm going to assume that your engine is almost complete. What kind of scene are you displaying? A spinning triangle is going to behave differently than a physics simulation. Also, whsat kind of performance are you getting?
Profiling Direct3D calls can be non-trivial as there are lots of ways to generate invalid or meaningless results.
Have a read of the 'Accurately Profiling Direct3D API Calls' article in the SDK documentation.
Are you actually having performance problems? Are you just trying to optimize it just for the sake of making it go faster, or is it currently too slow for your target hardware and you've found DrawSubset() as your bottleneck?
hth
Jack
Have a read of the 'Accurately Profiling Direct3D API Calls' article in the SDK documentation.
Are you actually having performance problems? Are you just trying to optimize it just for the sake of making it go faster, or is it currently too slow for your target hardware and you've found DrawSubset() as your bottleneck?
hth
Jack
Author
Engine is used for a role playing game (Terrain + Animated meshes + static meshes). All stuff is rendered using HLSL effect files. I profiled it for an early demo of the game with a really tiny scene. The demo run at 54 fps (1024x768) on a radeon X800 and Athlon 64 3500+. The problem in framerate showed itself when I turned on the number of rendered objects (almost all of obects were static). Frame rate was depending heavily on number of objects and not on number of polygons!
The scene had been passing between 200K to 400K polys to graphics card. I knew that the engine can render a single 400K poly object with fps 85+ and I'm sure that number was because of the VSync.
At last I ran a VS 2005 profile and I saw that %54 of the CPU were spending on DrawSubset() function (for static objects). Other usages was too scattered: %5 effect.BeginPass(), ...
If I find some time, I will test the engine using my own filled vertex/index buffer to see the results. for now I told the artists to lower number of textures they use per object as fat as they can to lower number of subsets (1 for each characters and small objects and more for bigger ones).
The scene had been passing between 200K to 400K polys to graphics card. I knew that the engine can render a single 400K poly object with fps 85+ and I'm sure that number was because of the VSync.
At last I ran a VS 2005 profile and I saw that %54 of the CPU were spending on DrawSubset() function (for static objects). Other usages was too scattered: %5 effect.BeginPass(), ...
If I find some time, I will test the engine using my own filled vertex/index buffer to see the results. for now I told the artists to lower number of textures they use per object as fat as they can to lower number of subsets (1 for each characters and small objects and more for bigger ones).
Author
According to VS2005 the bottleneck is DrawSubset() but thanks for the tip. I may did something wrong (bad state management,...) so DrawSubset() takes that long, or that's just normal and I should lower the number of calls (creating big chunks of vertex/index buffer) or maybe I should directly use vertex buffers not calling DrawSubset().
As long as that demo didn't have AI, story, rule,... I believe that framerate isn't acceptable.
As long as that demo didn't have AI, story, rule,... I believe that framerate isn't acceptable.
How many times are you calling DrawSubset() per frame? Internally it calls DrawIndexedPrimitive, and calling that more than 500 times a frame will utterly rape your performance.
Author
I didn't count the exact number of calls (I will) but from number of subsets of meshes Iknow it's around 400. One meshes had more than 150 subsets! So if what you say is true what should I do for a scene with more than 500 objects visible at a time? Squeezing them into one big vertex buffer.
I don't know if you're profiling through the .NET profiler or with the PIX DirectX profiler. If you want to use the PIX profiler, this little class might be of use. As Steve pointed out, you should not be calling mesh.DrawSubset (or any drawing method) more than 400-500 times per frame. As for why this is, check out this paper. One common technique to reduce your number of Draw calls is instancing, on which you can find a MDX sample over here.
Hope this help :)
Hope this help :)
In addition, 150 subsets for a single mesh sounds excessive, to say the least. Unless you have a specific need for so many different subsets, maybe you need to group up all similar textured subsets in each object into 1. This will surely provide some kind of performance improvement.
I'd recommend you do this in a modeling software and not in the actual code, since this would be a 1 time operation.
Hope this helps.
I'd recommend you do this in a modeling software and not in the actual code, since this would be a 1 time operation.
Hope this helps.
Author
Wow, thanks a lot for your replies! I'll read all this stuff and see what I can do.
Thanks agian.
Thanks agian.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
