662111 - Handle D3D10 device resets in content process

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Check for bad device

The attached patch isn't really a WIP, but adds the device check to PuppetWidget in the same place it is in the windows widget backend.

The shadow layer system doesn't support recreating layer managers atm.  That's a fairly big chunk of work.

I wonder if device resets etc. are rare enough that we can "support" them by just killing content processes and restarting ...  It's not clear how much time we should invest into this, with remote Azure on the horizon.

Comment 1

[Bas Schouten (:bas.schouten)]

(In reply to comment #0)
> Created attachment 537398 [details] [diff] [review] [review]
> Check for bad device
> 
> The attached patch isn't really a WIP, but adds the device check to
> PuppetWidget in the same place it is in the windows widget backend.
> 
> The shadow layer system doesn't support recreating layer managers atm. 
> That's a fairly big chunk of work.
> 
> I wonder if device resets etc. are rare enough that we can "support" them by
> just killing content processes and restarting ...  It's not clear how much
> time we should invest into this, with remote Azure on the horizon.

The incidence of device resets should be lower than 1 per 2 days of browsing (much lower in the general case, but that's hard to guarantee). Any device/driver combination where it is higher should be blacklisted. However that does not mean all such combinations are in the wild.

However since we strive to have that incidence, that's the incidence I believe we should base the decision on whether killing the content process is an acceptable solution.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Hmm ... 1 per 2 days might be a hard sell.  The odds of restarting content processes and losing somebody's form data that they left overnight, say, would be pretty high.

Do we have data available somewhere on crash/reset rates?

Comment 3

[Benjamin Smedberg]

No, but telemetry could probably get us some.

How much work is it to throw the entire layer tree away and start fresh on a D3D reset?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Not much. You lose the contents of canvases and possibly some video frames, though.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #3)
> How much work is it to throw the entire layer tree away and start fresh on a
> D3D reset?

Across processes, unknown.  The hard problem is dealing with chrome-process layer-manager restarts.  It's not so hard in theory but there are a bunch of little tricky details.

I remembered that we'll need to deal with layer-manager resets for d3d9 layers because of the two-step startup (basic then d3d9).  The d3d10 bits shouldn't be too bad.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Also D3D9 gets a reset whenever the screen is locked and unlocked. So it has to work without restarts.

Comment 7

[Joe Drew (not getting mail)]

I think that's unrelated, though, as D3D9 would be used only from the chrome process.

Even so, we don't really support e10s any more, so I'm calling this wontfix for now.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think WONTFIXing this is OK, but not because "we don't support e10s anymore". We are going to have to have e10s at some point. The real reason is that when we have it, we should do Azure remoting instead so we won't need D3D in content processes.