There are a few things I can think of. Either:
1] your app is generating a lot of gpu work -or-
2] there is a genuine driver bug.
You can try disable TDR's to figure out whether it's [1] or [2]. If the app runs fine with disabled TDR's it's likely the former, otherwise it'll be the latter:
http://www.microsoft.com/whdc/device/display/wddm_timeout.mspx
Sprinkling a few liberal flushes may help to minimize the problem if the problem was [1].
Failing that, it may be worth trying to build on one of the DXSDK samples and slowly migrate it towards your current NSE solver project.

Hey this looks pretty good; have you got an implementation that propagates across multiple thread group/blocks ie. a water surface greater than 32x32?
Moe: to get this working on DX10 feature level Compute under DX11, you could actually do it in 1 pass if you changed this to:
1] max 768 threads in a group. Although for efficiency reasons you'd actually want less than 384 threads.
2] a single UAV - possible if one converts the Height+Flow into a single RWStructuredBuffer for output, and a single StructuredBuffer for input.
3] a single groupshared region - possible again if you make it structured.
4] no shared memory scattered writes; ie. convert the algorithm to do gather reads.
5] The output StructuredBuffer can be directly bound as an SRV to other shader stages (VS, GS, PS).
6] compile for cs_4_0 target rather than cs_5_0 target.
(more info here: http://www.slideshare.net/repii/your-game-needs-direct3d-11-so-get-started-now)

When you call the ChangeDisplaySettingsEx function, send it the CDS_TEST flag to test whether the mode is *really* supported. This will test the display switch without actually doing the switch. I usually add this as part of my enumeration of display settings.

1] Thaumaturge is probably correct here. What projection/modelview matrix are you using? Try this just before your drawing. Do you see your two points now? const float LEFT_COORD_X = -10.0f; // ortho coord for left side of the screen const float RIGHT_COORD_X = 10.0f; // ortho coord for right side of the screen const float BOTTOM_COORD_Y = -10.0f; // ortho coord for the bottom of the screen const float TOP_COORD_Y = 10.0f; // ortho coord for the top of the screen glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(LEFT_COORD_X, RIGHT_COORD_X, BOTTOM_COORD_Y, TOP_COORD_Y, -1.0f, 1.0f); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); 2] clear colour should be specified before you do the clear. Thus, swap the order around here: glClearColor(0.0, 0.0, 0.0, 0.0); glClear (GL_COLOR_BUFFER_BIT);

Ah, I should have checked your code more closely and indeed there is a bug. This is what you should have (according to my OpenGL reference) GLint previous[2]; glGetIntegerv( GL_POLYGON_MODE, previous ); glPolygonMode( GL_FRONT_AND_BACK, GL_LINE ); // We want wire-frame mode // Do some drawing glPolygonMode( GL_FRONT, previous[0] ); glPolygonMode( GL_BACK, previous[1] );

Saving starting state (including random seeds) and subsequent player input is a great way to go. Particularly if you run-length compress your player input (it's very compressible!), you can knock it down to a couple hundred bytes for every minute of gameplay (YMMV) Some good articles on the subject: http://www.gamasutra.com/features/20010713/dickinson_pfv.htm http://www.gamasutra.com/view/feature/2029/developing_your_own_replay_system.php