Sign in to follow this  

[mdx] Cpu usage on mesh.DrawSubset()

This topic is 4227 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4227 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this