Closed Bug 624088 Opened 15 years ago Closed 15 years ago

Improve Direct3D 9 Device Reset handling

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bas.schouten, Assigned: bas.schouten)

References

Details

Attachments

(1 file)

Our handling of Device losses for D3D9Ex devices is flaky. There's some situations where even ResetEx cannot reset the device and currently that puts us into a state where painting is broken (I've seen this once now on a bad driver breakage). We should more aggressively consider the device lost beyond repair. From the documentation: " Devices are now only lost under two circumstances; when the hardware is reset because it is hanging, and when the device driver is stopped. When hardware hangs, the device can be reset by calling ResetEx. If hardware hangs, texture memory is lost. After a driver is stopped, the IDirect9Ex object must be recreated to resume rendering. " The latter will be done if we just activate our device removal code. In the case where texture memory is lost, the easiest thing to do is also just to recreate our entire device (this situation should be very rare anyway, i.e. driver crashes!). Since we don't use ResetEx to resize our buffers I believe the best thing to do is to never use it, and when CheckDeviceState indicates our device is broken to just recreate our layer managers like we do for D3D10. I think this will fix the behavior I saw where the browser became unusable somehow and probably also the behavior some of our users are seeing with remote desktop issues and such. Sadly I can't repro the problem I saw easily. But this patch should be good and safe to take. And always an improvement on our current behavior. It also ensures we don't consider textures valid whose data has been lost with minimal additional code.
Attachment #502187 - Flags: review?(jmuizelaar)
Attachment #502187 - Flags: review?(jmuizelaar) → review+
Comment on attachment 502187 [details] [diff] [review] Recreate our device agressively on device losses This fixes a potential bug, it's full of goodness.
Attachment #502187 - Flags: approval2.0?
Attachment #502187 - Flags: approval2.0? → approval2.0+
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: