Skip to main content
GameDev.net gamedev.net
🔒 Locked 🎮 Unity

SlimDX WPF Sample crashes display driver

Started by samv May 18, 2010 at 6:12 AM 5 replies 4.1k views
Original Post
samv
samv
Hi, I'm having problems with using SlimDX with WPF's D3DImage. When a non-trivial amount of triangles is rendered the Display Driver crashes. I reproduced the problem in the SlimDX WPF sample application (Direct3D9\WPF Interop\WpfSample) with just a small change that makes it render more triangles. My changes: 1. Draw some more triangles than before in MyRenderEngine.cs:

public void OnMainLoop(object sender, EventArgs e)
{
  _sprite.Begin(SpriteFlags.AlphaBlend);
  _sprite.Draw(_texture, Vector3.Zero, Vector3.Zero, _dataModel.Color4);
  int n = 1024 * 1024;
  for (int i = 0; i < n; i++)
  {
    _sprite.Transform = Matrix.RotationZ(i / (float)n) * Matrix.Translation(500, 500, 0);
    _sprite.Draw(_texture, Vector3.Zero, Vector3.Zero, _dataModel.Color4);
  }
  _sprite.Transform = Matrix.Identity;
  _sprite.End();
}

Make the window a bit larger and force redrawing on mouse move in WpfWindow.xaml(.cs):

    Height="800" Width="1024" SizeChanged="Window_SizeChanged">
  <Grid>
    <ii:SlimDXControl x:Name="m_slimDXControl" MouseDown="MouseDownHandler"
                                               MouseMove="MouseMoveHandler"/>


private void MouseMoveHandler(object sender, System.Windows.Input.MouseEventArgs e)
{
  m_slimDXControl.ForceRendering();
}

To reproduce start the sample and move the mouse for maybe 3 seconds. If it doesn't happen after a few frames it will usually not happen at all. Restart the application again. Sometimes it does not happen for quite some time, other times it quickly crashes every time. I'm using the latest SlimDX release (Feb 2010, 9.42), the latest NVidia drivers (197.45 WHQL). It happens on both Vista (x86) and Win7 (x64). In my real application it happens much more often (only?) when targeting .NET 4. But in the modified WpfSample above (with a high enough triangle count) it happens about equally often when targeting .NET 3.5. Thanks for any help!
_________Buggrit, millennium hand and shrimp!
samv
samv
By "the display driver crashes" I mean it gets reset by Windows.
Apparently this is called TDR (Timeout Detection and Recovery), a feature of the new Windows Display Driver Model which restarts the display driver after 2 seconds.

NVIDIA Statement on TDR Errors
Timeout Detection and Recovery of GPUs through WDDM

According to NVIDIA the most common cause is faulty hardware, overheating, overclocking etc.

However this happens on all 3 computers I tried, none are overclocked and all are supposed to be quite fast. (Geforce GTX 280, GTS 250, ... )

Is drawing a bunch of poylgons like this really too much? Does using WPF D3DImage slow this down so much? Is the .NET 4 D3DImage different in some way?
_________Buggrit, millennium hand and shrimp!
Maesse
Maesse
My experience tells me that you loose too much performance on using WPF + D3DImage. I tried using it as a GUI system for my engine, but ended up going back to my own DX implementation. Here's my reasons:

1. Using and displaying the D3DImage + the general overhead of WPF was a bit higher than I had anticipated.
2. WPF forces v-sync on.
3. It doesn't work with PerfHUD (my nvidia card is dead now, so not that it matters)
4. This is the worst: When you use WPF + D3DImage, you have to use WPF as the pump for your engine. This pump has some horrible timing, and will basically make your game feel crappy, unless, maybe, you always can deliver 60fps.
tgrand
tgrand
FWIW I just built a proof of concept app starting from the SlimDX WPF sample. I built SlimDX to target .NET 4.0. It's holding up great so far. I didn't try throwing a million API calls at it per frame (is that really a good idea?), but I am drawing some non-trivial meshes (~70k poly), with anti-aliasing (on Vista/7, shame it can't work on XP), multi-texturing, my own shaders, rendering to a large offscreen surface, etc. Mouse control of objects is very smooth. The app normally only draws when necessary, but I tried some continuous animation and it appeared to draw at refresh rate with no visible stuttering.

So far I've only tested on a few machines, but I've covered XP, Windows 7, NVIDIA, ATI, Intel integrated graphics, and everything is looking very good. I've been extremely happy with performance. I'm writing an app, not a game, but I've been seeing game-like performance. And I intend to test on a lot more systems before committing to this combination of technologies.. plus try some heavier workloads.

I've only run into two significant performance problems so far, and both were easily solved. First, I had to change the resizing behavior of the sample to not re-initialize everything on every mouse move event. This was particularly important on XP and slower systems. Second, I had to make sure that the SlimDX control did not have a keyboard focus indicator on it. For some reason, that slowed it down by quite a bit. I haven't investigated why yet - there was an easy property to set to just disable the indicator and that solved it.
samv
samv
Thanks a lot for your input! It's very much appreciated.

I'm also working on an application where not using WPF is not viable, not a game.

tgrand, I assume you still use D3DImage for your SlimDX/WPF interop?

Quote:
I built SlimDX to target .NET 4.0.

You recompiled the SlimDX DLL yourself, targetting .NET 4.0?
Very interesting. Was there a specific reason for doing this (as opposed to using useLegacyV2RuntimeActivationPolicy)? Is it just a simple recompile or is anything non-trivial required?

Quote:
a million API calls at it per frame (is that really a good idea?)

Probably not. The actual application doesn't do that either. (just shaders on a <10k triangle mesh.) I was just testing if the SlimDX sample app had the same problem. This was the simplest way to increase the complexity, so I pushed it until it triggered a TDR. Now I'm starting to think that this is not actually the same problem at all. (Just similar symptoms.)

Cheers!
_________Buggrit, millennium hand and shrimp!
tgrand
tgrand
Quote:
tgrand, I assume you still use D3DImage for your SlimDX/WPF interop?

Yes, that's right. I'm still using the sample code for that part.
Quote:
You recompiled the SlimDX DLL yourself, targetting .NET 4.0?
Very interesting. Was there a specific reason for doing this (as opposed to using useLegacyV2RuntimeActivationPolicy)? Is it just a simple recompile or is anything non-trivial required?

Yes, I compiled it myself. I didn't know about useLegacyV2RuntimeActivationPolicy. I just figured if I was going to go .NET 4.0, I should do it all the way. I noticed SlimDX had a VS2010 project in SVN. So the process was pretty easy: get latest code from SVN, install latest DirectX SDK, edit project settings to set include/library paths correctly, compile, remove anything from the project that didn't compile (I think it was only DirectCompute-related stuff), and then voila... .NET 4.0 SlimDX. For deployment I just put my custom-built SlimDX.dll in the same dir as my app.

I also did some experimenting with cutting down the size of SlimDX.dll by excluding APIs I wasn't using, but it didn't seem all that worthwhile. Excluding pretty much everything but D3D9 made the (release build) size go from 3.2MB to 1.5MB (or, 678KB compressed to 360KB compressed). With D3D9 excluded as well, it was still 909KB (235KB compressed).
samv
samv
Hey, thanks a ton for the detailed tips!

By the way, looks like I can avoid the crashes by calling Device.Present(). (Maybe this sounds obvious, but in .NET 3.5 this was not needed. Actually many people explicitly mentioned it shouldn't be called with D3DImage. And I don't really see why it should...)

Now I'm back to "just" dealing with the things Maesse mentioned. I'm not sure yet but it feels like frame skipping has become worse in .NET 4. [crying]

I'll try recompiling SlimDX though, maybe that does help a bit.

Cheers!
_________Buggrit, millennium hand and shrimp!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.