QA/Platform/Graphics
Contents
Summary
This page holds important information related to testing and quality assurance for Gecko's graphics code.
- About the team
- Major code changes worth tracking
- Inventory of hardware available for testing
- Information about graphics driver blocklisting
- Draft guides related to Graphics QA
Metrics
- Metrics-Graphics: staging, production
- Code Quality: Code Quality, Quality Indices
- Telemetry: GFX, All
- Bugzilla: Bug Age
Tools
Device ID Catalogs:
- General: [1], [2], [3]
- NVIDIA: wikipedia, nouveau.freedesktop.org
- AMD: wikipedia, developer.amd.com
Get Involved
Here are some ways you can help the Graphics team (and Mozilla):
- Run a sanity test
- Add your details to our inventory
- Send an e-mail to introduce yourself and get further direction
Activities
One & Done Testing
DEPRECATION WARNING: One&Done is being decommissioned. In the meantime, all tasks have been archived to this wiki.
Betabreakers Lab Testing
Summary
There is a large discrepancy between the platform/hardware/driver configurations we see on Release versus what we see on our test branches. Additionally, the Graphics team and our testing community does not and can not provide sufficient test coverage to fill this gap. As a result we've historically been notified far too late about critical graphics issues triggering multiple chemspill releases and a loss of users.
In an effort to improve pre-release visibility of graphics regressions we have partnered with Betabreakers, a company that maintains a lab specifically designed to test various modern and legacy configurations of Windows versions, graphics hardware, and graphics drivers. We try to coordinate a graphics sanity testrun with them once per mozilla-aurora cycle, as detailed below.
More information about our relationship with Betabreakers can be found on mana.mozilla.org.
Test Runs
- Firefox 50: Hardware Accelerated Video
- [DONE] Firefox 48: Windows 10 Anniversary Update
- [DONE] Firefox 48: WARP disabled further
- [DONE] Firefox 46: HTML5 video with hardware acceleration disabled
- [DONE] Firefox 45: WinXP D3D9 E10S compatibility
- [DONE] Firefox 44: Country-specific top sites
- [DONE] Firefox 43: Typical sanity check plus bug cleanup
- [DONE] Firefox 42: Windows 10 AMD/NVidia stability
- [DONE] Firefox 41: WARP disabled on Windows 7 and earlier
- [DONE] Firefox 40: WebGL with e10s
- [DONE] Firefox 39: beta sanity check
- [DONE] Firefox 38: MSE stress test
Bugs
99 Total; 5 Open (5.05%); 90 Resolved (90.91%); 4 Verified (4.04%);
Triage
Triage currently focuses on two main areas: identifying critical stability regressions, and identifying issues which may have slipped through the cracks. We try to have a one hour triage session each weekday, usually starting around 10:00am Pacific. More information about this process can be found on the wiki and dashboard.
Retired Activities
- Fennec Skia Sanity Checks (2015)
- B2G Sanity Checks (2015)
- Toronto Lab Testing (2015)
Top Issues
Blockers
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Crashes
13 Total; 13 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Features
41 Total; 41 Open (100%); 0 Resolved (0%); 0 Verified (0%);
New Issues
14 Total; 14 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Understanding the Problem Space
First order of business for my transition to the Graphics team is to understand the problem space so I can understand the immediate needs of the team and make the best impact I can in the shortest amount of time.
- What are the key problems/challenges facing the Graphics team in terms of quality?
- discrepancy in environments between testers and release users
- discoverability of bugs pre-release
- ?...
- Where can QA add value/support to the Graphics team?
- improving pre-release discoverability of bugs
- closing the gap between tester and release systems
- helping with bug triage, particularly with bugs hiding in general components
- representation in crashkill
- improving code coverage and/or identifying gaps in code coverage
- identifying ways to improve participation in the graphics team (events, projects, One & Done, etc)
- documentation of tools, testing processes, etc
- building out the lab in Toronto
- continuing to drive Betabreakers testing every 6 weeks
- verifying bug fixes (what does this look like)?
- profiling areas of risk (eg. troublesome configs)
- conducting root cause analysis for regressions
- understanding problems outside of our control (eg. driver resets)
- feature testing and upcoming priorities (e10s, Windows 10, El Capitain, Android, B2G, etc)
- What does QA need to know to be effective?
- key components of an actionable Graphics bug
- fundamentals/technologies that should be learned
- how to distinguish a graphics crash from a non-graphics crash with a graphics signature
- meetings, mailing lists, bugzilla components to watch, blogs, IRC channels to join, etc
- who is each member of the team (incl. contributors) and what do they do
- where does graphics code reside in the tree?
- what role does Unified Telemetry in graphics quality?
- what are the prefs to enable/disable different functionalities?
- we need a database of known-troublesome hardware/driver configurations to inform testing, hardware acquisitions, and blocklisting
- Understanding the Stability
- How do we identify a graphics crash?
- by signature: gfx, layers, D2D, D3D, ?...
- by topmost filename: gfx, ?...
- by driver (DLL, version, ?...)
- by device/vendor ID?...
- ?...
- How do we prioritize graphics crashes?
- Overall topcrashes in release > beta > aurora > nightly
- Gfx crashes in release > beta > aurora > nightly
- Explosive crashes in release > beta > aurora > nightly
- What tools do we have at our disposal to investigate crashes?
- Bughunter for investigating crashes correlated to a URL
- KaiRo's reports for identifying crashes that are new or escalating quickly
- Socorro for getting detailed information about crash reports
- What information is needed to make a crash actionable by developers?
- Correlations to particular hardware, driver, add-on, 3rd-party software, or library
- ?...
- Participation
- Sanity checking via One & Done
- Meetups to connect testers/users with devs
- Testdays to teach people about graphics testing
- Documentation and translation of documentation
- Engaging on community spaces (Discourse, Reddit, Facebook, Twitter, etc)
- Telemetry
- COMPOSITE_TIME: time in CompositorParent::CompositeToTarget dispatching draw calls and calling SwapBuffers, but not texture upload (ie. complete composition)
