Share via

WPF 3D Performance Troubleshooting

  • Article

I was recently involved in some analysis of a WPF application which used 3D heavily that wasn't hitting its performance goals. The application was pegging the CPU and acted incredibly sluggish.  What didn't make sense was that the CPU was getting pegged despite a video card with 256mb.  Watching Tim Cahill and company go through troubleshooting the application proved illuminating and I want to share some of the learnings.

The first test to make the window of the application smaller to see the implications on performance.  When shrinking the window to 150 x 150 pixels, the performance increased dramatically, suggesting that the application was "fill rate bound."  What is "fill rate bound?"  This is the speed with which the video card can "fill" pixels on the screen.  I found this article quite useful in its discussion of fill rates and of performance in general.

The big question was why is the CPU getting pegged if it was fill rate bound?  Shouldn't the GPU be handling this?  The first suspicion in this case would be that something was rendering in software and the logical fix would be to remove the offending code that was causing WPF to be rendered in software.  However, profiling the application showed that the application was largely running in kernel mode.  This might seem like a dead end -- it is, um, unreasonable to remove offending code in the kernel -- but it actually is revealing.

Kernel mode CPU usage is usually a strong indicator that the GPU is overloaded.  The way hardware acceleration works, the GPU processes instructions asynchronously that it receives from the CPU.  Because it’s asynchronous, the GPU can fall behind the CPU, and there’s a fixed-size GPU instruction queue.  When the CPU issues instructions too quickly and the queue is filled, the video driver has to prevent the CPU from issuing any more instructions.  This manifests itself as kernel-mode CPU time.  WPF tries to prevent this condition from happening in the general case, though edge cases still exist. 

(Sidenote: to get at profiling information that reveals more granular CPU usage information, one could use AMD's Code Analyst or Intel's VTune.)

The moral of the story?  Just because you are hardware accelerated doesn't mean that you are guaranteed great performance.  You can still max out the GPU.  Game developers, who are used to squeezing every inch of performance out of their application, know this.  However, it is easy to get yourself into trouble, especially if you are new to 3D programming and are doing lots with complex 3D meshes, complex materials (visual brushes, video) and animation. 

What are some possible causes of being fill rate bound? 

  • Too many visual / drawing brushes in your scene.  These brushes use video memory much more slowly than image/solid color brushes and you should use as few of them as possible, as small as possible.  
  • Non-front meshes with large idle visual brushes on them.  Even though they’re not visible they’re still going to be rendered if they’re there.
  • Too much overdraw.  Writing to the same pixel 5 times is 5 times as slow as writing to it once. This can be especially problematic z-order issues in 2D and the z-axis in 3D. 
  • Too many materials on your 3D models.
  • Too many lights in your scene.

Generally, the best way to try and fix this problem is to isolate the different features of the application that are guilty of the above and, if possible, add them back one at a time to determine the culprit.

Thanks to the WPF performance team for their insights on this topic.

Comments

  • Anonymous
    October 17, 2006
    Very timely post for me!  Thanks!

  • Anonymous
    October 17, 2006
    But shouldn't WPF remove hidden surfaces before they reach the GPU?  Back surface culling and all that? Also, I think it would really help if we could specify a priority or suggested texture size when using the VisualBrush.  I think it would also help if there was more debugging help to see where the GPU RAM was going.  At least some ETW events...

  • Anonymous
    October 18, 2006
    Some addendums on my earlier post about situations when the CPU gets blocked at the kernel as a result of the GPU not being able to process instructions quickly enough: --This condition is more likely to occur on XP and not on Vista.  Much work went into the WDDM (Windows Display Driver Model) to reduce the chances of this happening, through things like the GPU scheduler and and GPU memory manager.  Check this article out to find out more about WDDM: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/winvistadisplaydrivermodel.asp --On XP, this condition will manifest on windowed applictions.  Full screen applications (games, etc) should not have this issue.