Open
Bug 1297260
Opened 7 years ago
Updated 8 months ago
Devise a testing strategy for GPU process restarts
Categories
(Core :: Graphics, defect, P3)
Core
Graphics
Tracking
()
NEW
People
(Reporter: dvander, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [gfx-noted])
We've never tested our device reset code on TreeHerder, and this is a good time to start now that we will have a very simple way of creating failures: we can kill the GPU process. We don't just want to test that we can recover at the top of an event loop: we should be able to test the GPU process dying in the middle of an IPDL transaction, or while decoding video, or in the middle of a texture operation. Normal unit or integration tests would be a good place to start. Matt also mentioned a chaos mode on tree herder might help: We could randomly crash the GPU process during GPU entry-points and make sure we can recover to paint another frame.
Updated•7 years ago
|
Whiteboard: [gfx-noted]
Comment 1•7 years ago
|
||
Kevin, as I talked with david, this is another good practice to extend testing coverage of composition, especially with gpu process. Please have a look at it.
Assignee: nobody → kechen
Updated•7 years ago
|
Blocks: e10s-gpu-testing
Updated•7 years ago
|
Assignee: kechen → nobody
Updated•6 years ago
|
Priority: -- → P3
Updated•8 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•