Jump to content
  • Advertisement
Sign in to follow this  
FoxHunter2

Understanding and evaluating NV PerfHUD

This topic is 3910 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

Hi, thanks to the Release of NV PerfHUD 5.1 I was finally able to test my geomipmapped terrain in XNA with PerfHUD. I already read the quickstart and userguide tutorials, but I don't think I'm ready yet to fully evaluate the dozens of values I'm confronted with. I'd be very grateful if you could evaluate this 4 screenshots for me so that I can do this by myself for future evaluations - right now I just need some sense of which values are "fine" and which are "bad". Like "is my batch size too small/large?", "are the shader pipelines too busy?" and so on. Here are the screenshots: This currently runs at about 200-300 fps (depending on the viewport) on a GF6800gt in 1024x768, but drops to about 130fps using water reflections. thanks

Share this post


Link to post
Share on other sites
Advertisement
Here's my thoughts:

- You seem to do 246 calls to DrawIndexedPrimitive() with the same render state and only rendering 128 polys a call. You should look into making less calls with more polys in each one. I'd aim for at least 1024 per call to avoid being CPU limited.

- Textures and pixel shaders seem to be your main GPU workload, along with frame buffer bandwidth.

Make sure you're using mip mapping, and DXT compressed textures (use DXT1 unless they have an alpha channel). You could also try adjusting the texture filtering.

If you want advice on optimizing the pixel shader you'll probably need to post the hlsl here, but there's various online articles about it too on the NVidia and AMD sites.

- It's also worthwhile reading the perfhud documentation, especially the bit about tracking down where the bottlenecks are.

Share this post


Link to post
Share on other sites
Quote:
Original post by Adam_42
- You seem to do 246 calls to DrawIndexedPrimitive() with the same render state and only rendering 128 polys a call. You should look into making less calls with more polys in each one. I'd aim for at least 1024 per call to avoid being CPU limited.


Sounds good. Right now I'm drawing a 2049x2049 heightmap using a patch size of 129x129, which results in the 256 draw calls in worst case (witout culling).
I can't use larger patch sizes because I'm using 16bit index buffers for compatibility reasons. I'm not sure if I should drop this limitation, it would certainly improve batch sizes (at a cost of compatiblity and double IB size).

Quote:
- Textures and pixel shaders seem to be your main GPU workload, along with frame buffer bandwidth.

Make sure you're using mip mapping, and DXT compressed textures (use DXT1 unless they have an alpha channel). You could also try adjusting the texture filtering.


I'm already using DXT textures, performance was much worse using plain bitmap/jpg files. But you're right, in the current rendering implementation I use six tex2D instructions per pixel (alphamap, lightmap + 4 ground textures), so I think I'm fillrate limited here. Using a simple shader (lightmap + 1/2 textures) I already get about 100 fps more. I have several rendering implementations, and the one I showed here is already the 2nd most complex one.

Quote:
- It's also worthwhile reading the perfhud documentation, especially the bit about tracking down where the bottlenecks are.


I think I need to read it again then :)


thanks

Share this post


Link to post
Share on other sites
If simplifying the shader gives you such big speedups I wouldn't worry too much about the number of draw calls for now as you're not CPU limited, although there'd be no harm in going to say 257x129 as that'll still fit in the 16-bit indices.

Less texture filtering is worth trying. Compare anisotropic and linear min filters, and linear and point mip filters and see what the visual and performance difference is for both nearby and distant terrain. My guess would be you could get away with less filtering in the distance to speed things up.

As the pixel shader is so expensive also make sure you draw the scene in roughly front to back order (for example sort by distance from the camera). That way the z-buffer will be more effective at avoiding shading pixels more than once. Also double check that back face culling is on!

Share this post


Link to post
Share on other sites
My geomipmap engine only allows for patch sizes of 2^n+1 times 2^n+1, so I can't change this one. But I'll play around a bit with different filtering methods for the textures and see what it looks like. Right now I have them all set to linear filtering.

Backface culling and front-to-back rendering are also enabled (the latter can be seen very nicely in the perfhud frame profiler where you can select the draw call). The front-to-back rendering gave me quite some nice performance boost, and I read cards like the GF8xxx can handle this case even better.

I don't think 300fps with such complex shaders and a relatively large terrain is too bad though, but I might be mistaken.

How many tris/frame are modern cards able to handle? I see my screenshot is doing about 55k at the moment.


regards

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!