Handle D3D10 device resets in content process

RESOLVED WONTFIX

Status

()

Core
Graphics
RESOLVED WONTFIX
7 years ago
6 years ago

People

(Reporter: cjones, Unassigned)

Tracking

Trunk
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 537398 [details] [diff] [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.
(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.
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

7 years ago
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?
Not much. You lose the contents of canvases and possibly some video frames, though.
(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.
Also D3D9 gets a reset whenever the screen is locked and unlocked. So it has to work without restarts.
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Summary: Handle D3D10 device resets in content → Handle D3D10 device resets in content process
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.
You need to log in before you can comment on or make changes to this bug.