Confirmed users
137
edits
Platform/GFX/Quantum Render: Difference between revisions
m
webrender-perf try preset
(→Build instructions: Update workflows) |
m (webrender-perf try preset) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 18: | Line 18: | ||
IRC channel: #gfx <br/> | IRC channel: #gfx <br/> | ||
Project owner: Maire Reavy <br/> | Project owner: Maire Reavy <br/> | ||
Where is it on: [[Platform/GFX/WebRender_Where]] | |||
== Getting the code == | == Getting the code == | ||
| Line 68: | Line 69: | ||
=== On Gecko integration === | === On Gecko integration === | ||
If you are familiar with the way Gecko normally works, the Quantum Render changes should be relatively straightforward. Instead of using a ClientLayerManager, we create a [https://hg.mozilla.org/projects/graphics/file/tip/gfx/layers/wr/WebRenderLayerManager.cpp WebRenderLayerManager] instance. However, this "layer manager" doesn't actually manage layers, because WebRender doesn't use layers. Instead, it walks the Gecko display list and calls the <tt>BuildWebRenderCommands</tt> function on each display item to generate WebRender display items. This display list is sent over the [https://hg.mozilla.org/projects/graphics/file/tip/gfx/layers/ipc/PWebRenderBridge.ipdl PWebRenderBridge] IPDL channel, which is conceptually similar to PLayerTransaction in Gecko. The commands are received in [https://hg.mozilla.org/projects/graphics/file/tip/gfx/layers/wr/WebRenderBridgeParent.cpp WebRenderBridgeParent] which interprets the messages, and talks to the core WebRender library using the API in [https://hg.mozilla.org/projects/graphics/file/tip/gfx/webrender_bindings/webrender_ffi.h webrender_ffi.h] (via various wrapper abstractions in <tt>gfx/webrender_bindings/</tt>). The API is implemented in the [https://hg.mozilla.org/projects/graphics/file/tip/gfx/webrender_bindings/src/bindings.rs webrender_bindings] crate, which is written in Rust. | |||
If you are familiar with the way Gecko normally works, the Quantum Render changes should be relatively straightforward. Instead of using a ClientLayerManager, we create a [https://hg.mozilla.org/projects/graphics/file/tip/gfx/layers/wr/WebRenderLayerManager.cpp WebRenderLayerManager] instance. | |||
Look through [https://bugzilla.mozilla.org/buglist.cgi?component=Graphics%3A%20WebRender&product=Core&bug_status=__open__&list_id=13349798 open unassigned bugs] (with no open dependencies) in the WebRender bugzilla component to find things to work on. | Look through [https://bugzilla.mozilla.org/buglist.cgi?component=Graphics%3A%20WebRender&product=Core&bug_status=__open__&list_id=13349798 open unassigned bugs] (with no open dependencies) in the WebRender bugzilla component to find things to work on. | ||
| Line 76: | Line 75: | ||
=== On reftests === | === On reftests === | ||
Many of the existing gecko reftests (over 13000 of them) are passing with Quantum Render. However, there are still around | Many of the existing gecko reftests (over 13000 of them) are passing with Quantum Render. However, there are still around 80 failing reftests. These are listed in [https://docs.google.com/spreadsheets/d/1DcqaMvt3I38HIl3-RDS_6aiX67nQWItNcwmVt5utbDk/edit?usp=sharing this Google sheet]. You're welcome to work on getting these passing - please follow the procedure below: | ||
* Identify a single reftest you wish to work on. Try to pick one that sounds unrelated to other reftests that people are working on, because often one patch will fix multiple related reftests. | * Identify a single reftest you wish to work on. Try to pick one that sounds unrelated to other reftests that people are working on, because often one patch will fix multiple related reftests. | ||
* File a bug for that reftest, and mark it as blocking {{bug|1322815}} (webrender-reftests). | * File a bug for that reftest, and mark it as blocking {{bug|1322815}} (webrender-reftests). | ||
* Work on the fix. The best way to do this is to remove the fails-if or skip-if annotation in your local checkout and run the reftest using <tt>mach reftest</tt>. Debug and fix as needed | * Work on the fix. The best way to do this is to remove the fails-if or skip-if annotation in your local checkout and run the reftest using <tt>mach reftest --enable-webrender</tt>. Debug and fix as needed. | ||
* | * You should do at least one try push after writing your fix to verify it works in automation, as well as to identify any other tests that are fixed by your patch. Make sure to update the annotations for all newly-passing tests as part of your final commit. Try not to introduce regressions, although breaking a small number of tests to make a larger number pass might be acceptable. | ||
* Land your fix after getting review as appropriate. | * Land your fix after getting review as appropriate. | ||
| Line 97: | Line 96: | ||
=== Try pushes === | === Try pushes === | ||
You can (and are encouraged to) push changes to tryserver to test them out before landing them. For linux64, the tests will run using a regular linux64 build. However, you need to specify <tt>linux64-qr</tt> as the test platform to have QR enabled during testing. The same goes for windows10-64. So, for example, to run all the available tests on QuantumRender-enabled builds, you could use this trychooser syntax: | You can (and are encouraged to) push changes to tryserver to test them out before landing them. | ||
The simplest way to render webrender-related tests is to use the "webrender" try preset: | |||
./mach try --preset webrender | |||
This preset runs most tests relevant to webrender with the exception of some tests running on Pixel 2 devices (for now). It is also possible to push to try using try or try fuzzy syntax explicitly: | |||
For linux64, the tests will run using a regular linux64 build. However, you need to specify <tt>linux64-qr</tt> as the test platform to have QR enabled during testing. The same goes for <tt>windows10-64</tt>/<tt>windows10-64-qr</tt> and <tt>macosx64</tt>/<tt>macosx64-qr</tt>. So, for example, to run all the available desktop tests on QuantumRender-enabled builds, you could use this trychooser syntax: | |||
try: -b do -p linux64,win64,macosx64 -u all[linux64-qr,windows10-64-qr,macosx64-qr] -t all[linux64-qr,windows10-64-qr,macosx64-qr] | try: -b do -p linux64,win64,macosx64 -u all[linux64-qr,windows10-64-qr,macosx64-qr] -t all[linux64-qr,windows10-64-qr,macosx64-qr] | ||
Note that the query above does not run wrench tests. | |||
There is also a webrender-perf try preset which only runs some of the talos tests relevant to webrender: | |||
./mach try --preset webrender-perf | |||
Running Android tests is a little tricker, because we only run Gecko reftests on Pixel 2 devices for Android, and we don't have a lot of those so there's often a backlog of jobs for them. In order to minimize the chance of people accidentally queuing up jobs on these device that they don't actually need, jobs that run on these devices are not selectable by default. Instead you have to run `./mach try fuzzy --full` which lists all the "hidden" jobs, and explicitly select them. From the command line, you can select the Android QuantumRender jobs like so: | |||
./mach try fuzzy --full -q "'"'-qr android !fis' # !fis excludes fission variants which also show up with --full but are perma-fail | |||
You can also run WebRender's standalone tests on tryserver (linting and Linux/Windows tests only for now, macOS is tracked in {{bug|1516568}}). As trychooser syntax is deprecated, the way to run these tests is to select them in <tt>./mach try fuzzy</tt> with the query string <tt>^webrender-</tt>. You can do this on the command line like so: | You can also run WebRender's standalone tests on tryserver (linting and Linux/Windows tests only for now, macOS is tracked in {{bug|1516568}}). As trychooser syntax is deprecated, the way to run these tests is to select them in <tt>./mach try fuzzy</tt> with the query string <tt>^webrender-</tt>. You can do this on the command line like so: | ||
./mach try fuzzy -q '^webrender-' | ./mach try fuzzy -q '^webrender-' | ||
To run all of the QuantumRender tests as well as the WebRender standalone tests, you can use the following command: | To run all of the desktop QuantumRender tests as well as the WebRender standalone tests, you can use the following command: | ||
./mach try fuzzy -q "'-qr" -q '^webrender-' | ./mach try fuzzy -q "'-qr" -q '^webrender-' | ||
or without talos/raptor: | or without talos/raptor: | ||
./mach try fuzzy -q "'"'-qr !talos !raptor' -q '^webrender-' | ./mach try fuzzy -q "'"'-qr !talos !raptor' -q '^webrender-' | ||
If you have a particular set of tests you run frequently that cannot be represented by trychooser syntax, the best way to do it is this: | If you have a particular set of tests you run frequently that cannot be easily represented by trychooser or fuzzy syntax, the best way to do it is this: | ||
* First, do a push using <tt>./mach try fuzzy</tt> where you select the set of jobs you care about | * First, do a push using <tt>./mach try fuzzy</tt> where you select the set of jobs you care about | ||
* The head commit of that try push will have a <tt>try_tasks_config.json</tt> file which lists the jobs. Copy that file into a local commit | * The head commit of that try push will have a <tt>try_tasks_config.json</tt> file which lists the jobs. Copy that file into a local commit | ||