Uses a tree.json file to configure the tree (will be moved in the yml file)
We also removed the python package doc from the landing page because :
* They are still accessible in the sidebar
* Hardly anyone is going to be looking for them (they are mostly useful to link to from other docs)
* They get in the way of the documentation below
Differential Revision: https://phabricator.services.mozilla.com/D51306
--HG--
extra : moz-landing-system : lando
This change vendors `wgpu` library in-tree and hooks up the initialization bits. It implements adapter and device initialization and adds a simple test.
Current status:
- [x] Architecture
- [x] figure out the IPC story
- [ ] move wgpu crates into a dedicated folder (let's follow up with this)
- [x] Review
- [x] WebIDL changes by DOM peers
- [x] Linux
- [x] avoid depending on spirv_cross - https://github.com/gfx-rs/wgpu/pull/371
- [x] macOS
- [x] due to cross-compiling shaders - https://github.com/gfx-rs/gfx/pull/3047
- [x] need the dependency update
- [x] stop using gcc - https://github.com/SSheldon/rust-objc-exception/pull/5
- [x] unexpected SSL header collision - https://phabricator.services.mozilla.com/D51148
- [x] undefined Metal symbols
- [x] missing webrtc headers for IPDL magic - https://phabricator.services.mozilla.com/D51558
- [x] Windows
- [x] due to "ipc-channel" not supporting Windows yet - https://github.com/servo/ipc-channel/pull/233~~
- [x] due to some exceptional stuff - https://github.com/grovesNL/spirv_cross/issues/121
- [x] undefined symbol: `D3D12CreateDevice`
- [x] d3d12.dll is not found, dxgi1_4 doesn't present
- [x] d3d11.dll and dxgi.dll need to be explicitly loaded on win32 mingw - https://github.com/gfx-rs/gfx/pull/3076
- [x] libbacktrace fails to link on win32 mingw
- [x] cc mislinking C++ standard library - https://github.com/alexcrichton/cc-rs/pull/455
- [x] Android
- [x] spirv-cross fails to build - https://github.com/KhronosGroup/SPIRV-Cross/pull/1193
Update-1:
We decided to go with IPDL mechanism instead of Rust based ipc-channel (or any alternatives), which unblocks Windows build.
Update-2:
It appears that WebGPUThreading isn't needed any more as the child thread (and its event loop) is now managed by IPDL infrastructure. This PR removes it 🎉 .
Update-3:
InstanceProvider is also removed.
Update-4:
All set, the try is green, waiting for dependent changes to go in.
Differential Revision: https://phabricator.services.mozilla.com/D49458
--HG--
rename : dom/webgpu/Adapter.cpp => dom/webgpu/ipc/WebGPUTypes.h
rename : third_party/rust/arrayvec/.cargo-checksum.json => third_party/rust/arrayvec-0.4.11/.cargo-checksum.json
rename : third_party/rust/arrayvec/Cargo.toml => third_party/rust/arrayvec-0.4.11/Cargo.toml
rename : third_party/rust/arrayvec/README.rst => third_party/rust/arrayvec-0.4.11/README.rst
rename : third_party/rust/arrayvec/benches/extend.rs => third_party/rust/arrayvec-0.4.11/benches/extend.rs
rename : third_party/rust/arrayvec/build.rs => third_party/rust/arrayvec-0.4.11/build.rs
rename : third_party/rust/arrayvec/src/array.rs => third_party/rust/arrayvec-0.4.11/src/array.rs
rename : third_party/rust/arrayvec/src/array_string.rs => third_party/rust/arrayvec-0.4.11/src/array_string.rs
rename : third_party/rust/arrayvec/src/char.rs => third_party/rust/arrayvec-0.4.11/src/char.rs
rename : third_party/rust/arrayvec/src/lib.rs => third_party/rust/arrayvec-0.4.11/src/lib.rs
rename : third_party/rust/arrayvec/src/maybe_uninit.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_nodrop.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_nodrop.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_stable.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_stable.rs
rename : third_party/rust/arrayvec/src/range.rs => third_party/rust/arrayvec-0.4.11/src/range.rs
rename : third_party/rust/arrayvec/tests/serde.rs => third_party/rust/arrayvec-0.4.11/tests/serde.rs
rename : third_party/rust/arrayvec/tests/tests.rs => third_party/rust/arrayvec-0.4.11/tests/tests.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/atom/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/cocoa/Cargo.toml
rename : third_party/rust/core-graphics/src/lib.rs => third_party/rust/cocoa/src/lib.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/colorful/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/range-alloc/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/shared_library/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/x11/Cargo.toml
extra : moz-landing-system : lando
This change vendors `wgpu` library in-tree and hooks up the initialization bits. It implements adapter and device initialization and adds a simple test.
Current status:
- [x] Architecture
- [x] figure out the IPC story
- [ ] move wgpu crates into a dedicated folder (let's follow up with this)
- [x] Review
- [x] WebIDL changes by DOM peers
- [x] Linux
- [x] avoid depending on spirv_cross - https://github.com/gfx-rs/wgpu/pull/371
- [x] macOS
- [x] due to cross-compiling shaders - https://github.com/gfx-rs/gfx/pull/3047
- [x] need the dependency update
- [x] stop using gcc - https://github.com/SSheldon/rust-objc-exception/pull/5
- [x] unexpected SSL header collision - https://bugzilla.mozilla.org/show_bug.cgi?id=1592398
- [x] undefined Metal symbols
- [x] Windows
- [x] due to "ipc-channel" not supporting Windows yet - https://github.com/servo/ipc-channel/pull/233~~
- [x] due to some exceptional stuff - https://github.com/grovesNL/spirv_cross/issues/121
- [x] undefined symbol: `D3D12CreateDevice`
- [x] d3d12.dll is not found, dxgi1_4 doesn't present
- [x] d3d11.dll and dxgi.dll need to be explicitly loaded on win32 mingw - https://github.com/gfx-rs/gfx/pull/3076
- [x] libbacktrace fails to link on win32 mingw
- [x] Android
- [x] spirv-cross fails to build - https://github.com/KhronosGroup/SPIRV-Cross/pull/1193
Update-1:
We decided to go with IPDL mechanism instead of Rust based ipc-channel (or any alternatives), which unblocks Windows build.
Update-2:
It appears that WebGPUThreading isn't needed any more as the child thread (and its event loop) is now managed by IPDL infrastructure. This PR removes it 🎉 .
Update-3:
InstanceProvider is also removed.
Update-4:
All set, the try is green, waiting for dependent changes to go in.
Differential Revision: https://phabricator.services.mozilla.com/D49458
--HG--
rename : dom/webgpu/Adapter.cpp => dom/webgpu/ipc/WebGPUTypes.h
rename : third_party/rust/arrayvec/.cargo-checksum.json => third_party/rust/arrayvec-0.4.11/.cargo-checksum.json
rename : third_party/rust/arrayvec/Cargo.toml => third_party/rust/arrayvec-0.4.11/Cargo.toml
rename : third_party/rust/arrayvec/README.rst => third_party/rust/arrayvec-0.4.11/README.rst
rename : third_party/rust/arrayvec/benches/extend.rs => third_party/rust/arrayvec-0.4.11/benches/extend.rs
rename : third_party/rust/arrayvec/build.rs => third_party/rust/arrayvec-0.4.11/build.rs
rename : third_party/rust/arrayvec/src/array.rs => third_party/rust/arrayvec-0.4.11/src/array.rs
rename : third_party/rust/arrayvec/src/array_string.rs => third_party/rust/arrayvec-0.4.11/src/array_string.rs
rename : third_party/rust/arrayvec/src/char.rs => third_party/rust/arrayvec-0.4.11/src/char.rs
rename : third_party/rust/arrayvec/src/lib.rs => third_party/rust/arrayvec-0.4.11/src/lib.rs
rename : third_party/rust/arrayvec/src/maybe_uninit.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_nodrop.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_nodrop.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_stable.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_stable.rs
rename : third_party/rust/arrayvec/src/range.rs => third_party/rust/arrayvec-0.4.11/src/range.rs
rename : third_party/rust/arrayvec/tests/serde.rs => third_party/rust/arrayvec-0.4.11/tests/serde.rs
rename : third_party/rust/arrayvec/tests/tests.rs => third_party/rust/arrayvec-0.4.11/tests/tests.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/atom/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/cocoa/Cargo.toml
rename : third_party/rust/core-graphics/src/lib.rs => third_party/rust/cocoa/src/lib.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/colorful/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/range-alloc/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/shared_library/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/x11/Cargo.toml
extra : moz-landing-system : lando
This change vendors `wgpu` library in-tree and hooks up the initialization bits. It implements adapter and device initialization and adds a simple test.
Current status:
- [x] Architecture
- [x] figure out the IPC story
- [ ] move wgpu crates into a dedicated folder (let's follow up with this)
- [x] Review
- [x] WebIDL changes by DOM peers
- [x] Linux
- [x] avoid depending on spirv_cross - https://github.com/gfx-rs/wgpu/pull/371
- [x] macOS
- [x] due to cross-compiling shaders - https://github.com/gfx-rs/gfx/pull/3047
- [x] need the dependency update
- [x] stop using gcc - https://github.com/SSheldon/rust-objc-exception/pull/5
- [x] unexpected SSL header collision - https://bugzilla.mozilla.org/show_bug.cgi?id=1592398
- [x] undefined Metal symbols
- [x] Windows
- [x] due to "ipc-channel" not supporting Windows yet - https://github.com/servo/ipc-channel/pull/233~~
- [x] due to some exceptional stuff - https://github.com/grovesNL/spirv_cross/issues/121
- [x] undefined symbol: `D3D12CreateDevice`
- [x] d3d12.dll is not found, dxgi1_4 doesn't present
- [x] d3d11.dll and dxgi.dll need to be explicitly loaded on win32 mingw - https://github.com/gfx-rs/gfx/pull/3076
- [x] libbacktrace fails to link on win32 mingw
- [x] Android
- [x] spirv-cross fails to build - https://github.com/KhronosGroup/SPIRV-Cross/pull/1193
Update-1:
We decided to go with IPDL mechanism instead of Rust based ipc-channel (or any alternatives), which unblocks Windows build.
Update-2:
It appears that WebGPUThreading isn't needed any more as the child thread (and its event loop) is now managed by IPDL infrastructure. This PR removes it 🎉 .
Update-3:
InstanceProvider is also removed.
Update-4:
All set, the try is green, waiting for dependent changes to go in.
Differential Revision: https://phabricator.services.mozilla.com/D49458
--HG--
rename : dom/webgpu/Adapter.cpp => dom/webgpu/ipc/WebGPUTypes.h
rename : third_party/rust/arrayvec/.cargo-checksum.json => third_party/rust/arrayvec-0.4.11/.cargo-checksum.json
rename : third_party/rust/arrayvec/Cargo.toml => third_party/rust/arrayvec-0.4.11/Cargo.toml
rename : third_party/rust/arrayvec/README.rst => third_party/rust/arrayvec-0.4.11/README.rst
rename : third_party/rust/arrayvec/benches/extend.rs => third_party/rust/arrayvec-0.4.11/benches/extend.rs
rename : third_party/rust/arrayvec/build.rs => third_party/rust/arrayvec-0.4.11/build.rs
rename : third_party/rust/arrayvec/src/array.rs => third_party/rust/arrayvec-0.4.11/src/array.rs
rename : third_party/rust/arrayvec/src/array_string.rs => third_party/rust/arrayvec-0.4.11/src/array_string.rs
rename : third_party/rust/arrayvec/src/char.rs => third_party/rust/arrayvec-0.4.11/src/char.rs
rename : third_party/rust/arrayvec/src/lib.rs => third_party/rust/arrayvec-0.4.11/src/lib.rs
rename : third_party/rust/arrayvec/src/maybe_uninit.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_nodrop.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_nodrop.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_stable.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_stable.rs
rename : third_party/rust/arrayvec/src/range.rs => third_party/rust/arrayvec-0.4.11/src/range.rs
rename : third_party/rust/arrayvec/tests/serde.rs => third_party/rust/arrayvec-0.4.11/tests/serde.rs
rename : third_party/rust/arrayvec/tests/tests.rs => third_party/rust/arrayvec-0.4.11/tests/tests.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/atom/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/cocoa/Cargo.toml
rename : third_party/rust/core-graphics/src/lib.rs => third_party/rust/cocoa/src/lib.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/colorful/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/range-alloc/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/shared_library/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/x11/Cargo.toml
extra : moz-landing-system : lando
Remove mobile/android/extensions/ and /mobile/android/chrome/content from mozilla-central (Fennec leftovers)
Differential Revision: https://phabricator.services.mozilla.com/D51194
--HG--
extra : moz-landing-system : lando
This patch fixes some issues with binaries not being executable after being extracted. It also fixes the ImageMagick expected extraction path to the correct location. To prevent that from occuring again, a check is done after extraction to be sure that the extraction completed successfully.
Differential Revision: https://phabricator.services.mozilla.com/D51300
--HG--
extra : moz-landing-system : lando
The buffer range starts at 1 (the first valid entry, 0 is reserved as
null marker). So if it now starts *after* 1, it means we have started to
overwrite our oldest data, and we should get rid of Base profiles if any.
Differential Revision: https://phabricator.services.mozilla.com/D51225
--HG--
extra : moz-landing-system : lando
profile.counters[n].sample_groups was mistakenly streamed as an object, which
prevents having more than one, and goes against the published format
documentation.
The front-end was implemented to process the incorrect format, so it will need
to be updated as well; hence the version change to 18.
Differential Revision: https://phabricator.services.mozilla.com/D49867
--HG--
extra : moz-landing-system : lando
Instead of requesting profiles until it "seems" to have collected something,
use `nsIProfiler.waitOnePeriodicSampling()` to really wait for a sample to be
taken.
Note that this means some test could theoretically fail if they were in fact
waiting for stack samples to appear in the first registered thread. If that
happens, these tests should be udpated to do that extra wait-for-data.
Differential Revision: https://phabricator.services.mozilla.com/D50783
--HG--
extra : moz-landing-system : lando
`nsIProfiler.waitOnePeriodicSampling()` returns a promise that gets resolved
after the next full periodic sampling. The promise is rejected if the sampler is
not running.
Implementation detail: `Promise` uses single-threaded ref-counting, so special
care is needed not to touch it in the sampler thread. Safe ref-counting is
handled by `nsMainThreadPtrHolder` and `nsMainThreadPtrHandle`. And the promise
is only resolved/rejected on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D50782
--HG--
extra : moz-landing-system : lando
Register a callback to be invoked the next time the Sampler thread ends its
periodic loop.
Registration may fail (e.g., if the profiler is not active), in which case the
callback is never called.
After successful registration the callback is guaranteed to be invoked after the
sampler runs, or stops running.
Differential Revision: https://phabricator.services.mozilla.com/D50781
--HG--
extra : moz-landing-system : lando
This patch updgrades the current version used in-tree so that browsertime works with chrome, it currently timesout with that browser.
Differential Revision: https://phabricator.services.mozilla.com/D50999
--HG--
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
The source of deadlock is due to profiler->lock->IO->interposer->profiler->lock
loops, where the second profiler call tries to lock the profiler mutex again.
Thanks to `profiler_is_locked_on_current_thread` the interposer can now check
whether the mutex is already locked, in which case it just won't call profiler
functions anymore, breaking the loop.
And now the profiler doesn't need to manually pause/resume/unregister the
(potential) interposer when doing I/Os.
Differential Revision: https://phabricator.services.mozilla.com/D50561
--HG--
extra : moz-landing-system : lando
PSMutex can store the id of the thread owning the lock, and it's safe to check
whether the current thread owns that lock (either it does and no-one else can
change it, or it's another id).
Comments related to memory hooks have been moved to memory_hooks.cpp, because
`profiler_is_locked_on_current_thread()` could be used for other things.
Differential Revision: https://phabricator.services.mozilla.com/D49895
--HG--
extra : moz-landing-system : lando
Refactored the recursion to improve its reliability, and added a caching layer.
Differential Revision: https://phabricator.services.mozilla.com/D50267
--HG--
extra : moz-landing-system : lando
The LUL unwinder on x86_64-android and x86_64-linux tries to read Dwarf unwind
information from the ELF section named ".eh_frame", and expects the section to
have type SHT_PROGBITS. It appears that that section might instead have the
type SHT_X86_64_UNWIND, possibly as a result of recent toolchain (linker?)
changes. This patch tracks that change.
Differential Revision: https://phabricator.services.mozilla.com/D50474
--HG--
extra : moz-landing-system : lando
Logging could be intercepted by the I/O interposer, which takes the lock, this
could deadlock if the mutex had already been taken in the same thread (e.g., by
a "locked" profiler function that wants to log something).
Now, functions that hold the lock must use `LOG_LOCKED(lock, ...)`, which will
skip logging when the I/O interposer is running.
In DEBUG builds, `LOG()` checks that the lock is not owned, to find possible
misuses.
`LOG()`s outside of platform.cpp were changed to `NS_WARNING`s, because they
could not access `gPSMutex` that's defined in platform.cpp; and they're really
warnings anyway.
Some interposer pauses/resumes have been relocated to more appropriate spots:
- Not needed around `locked_profiler_stream_json_for_this_process` anymore,
thanks to `LOG_LOCKED` inside.
- Definitely needed around `std::ofstream` operations in
`locked_profiler_save_profile_to_file`.
Differential Revision: https://phabricator.services.mozilla.com/D49896
--HG--
extra : moz-landing-system : lando
PSMutex can store the id of the thread owning the lock, and it's safe to check
whether the current thread owns that lock (either it does and no-one else can
change it, or it's another id).
Comments related to memory hooks have been moved to memory_hooks.cpp, because
`profiler_is_locked_on_current_thread()` could be used for other things.
Differential Revision: https://phabricator.services.mozilla.com/D49895
--HG--
extra : moz-landing-system : lando
A requested addition to the estimates in the preview pane, showing how large the requested set of tasks is compared to everyone else's set.
Differential Revision: https://phabricator.services.mozilla.com/D50076
--HG--
extra : moz-landing-system : lando
In Bug 1587907 we got some contentPid not found errors. It seemed like we were
failing intermittently at getting content pid. After moving test content inside
the BrowserTestUtils.withNewTab callback, we won't get the same error anymore.
Also from my testing, it looks like it makes the test execution faster. We were
getting some intermittents before because of the timeouts, these will be fixed
if my testing is correct.
Differential Revision: https://phabricator.services.mozilla.com/D49951
--HG--
extra : moz-landing-system : lando
Since markers are stored directly into the buffer:
- We don't need to wait for a sampling run to collect them,
- No markers are left uncollected between the last sampling and the time we stop
the profiler.
Differential Revision: https://phabricator.services.mozilla.com/D49233
--HG--
extra : moz-landing-system : lando
`stopProfilerAndGetThreads()` waits until at least one sample appears in the
main thread, before capturing a profile and stopping the profiler.
`stopProfilerNowAndGetThreads()` does not wait; this should be useful in tests
that may not generate any samples (e.g., using the nostacksampling feature).
Differential Revision: https://phabricator.services.mozilla.com/D49232
--HG--
extra : moz-landing-system : lando
