• entries
    316
  • comments
    485
  • views
    322258

Shady Drivers...

Sign in to follow this  

562 views


Shady Drivers...


Well, it was a good try. I converted everything over to run on the down level hardware for my NSE Simulation, which should run on D3D_FEATURE_LEVEL_10_0. When I run it with the reference device everything works well, except for the speed of course. When I try running it on my experimental drivers that I mentioned last time, it renders the initial frame then I get a driver lockup and recovery with the following output on the debug window:

D3D11: Removing Device.
D3D11: ERROR: ID3D11Device::RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT ]
The thread 'Win32 Thread' (0x145c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1784) has exited with code 0 (0x0).
First-chance exception at 0x763642eb in LivingBook.exe: Microsoft C++ exception: _com_error at memory location 0x0012f3dc..

That is one heck of an error description if I do say so myself. Since it works fine with the REF device, I'm not sure I can spend too much time looking for something that I'm doing wrong. Has anyone seen anything like this before... My only recourse could be to wait for some actual drivers to come out, which may be never with a Dell laptop [rolleyes]!
Sign in to follow this  


3 Comments


Recommended Comments

Quote:
Original post by Jason Z

... which may be never with a Dell laptop [rolleyes]!


When this popped up on my feed reader, I did assume you were still struggling with that Vostro [smile]

For what it's worth, at least you do get to experience the worst-case scenario your potential users may run into in driver-land [grin]

Share this comment


Link to comment
Yes, it is quite a love-hate relationship with my laptop. I use it every day, and appreciate the fact that it has been robust without any major issues. But at the same time the Dell driver situation is just plain silly.

I went ahead and found an updated laptop driver on the nVidia site, and actually found out what the problem is (my hardware is actually incapable according to the new driver...). So it will remain with the REF device for a little while until I confiscate my wife's new laptop...

Share this comment


Link to comment
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.

Share this comment


Link to comment

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