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
Before this patch, we only considered the primary screen when deciding
whether or not WebRender should be enabled. This is problematic for
Intel users where we don't want to turn on WebRender for large screens;
several small screens are just as bad as one large screen. Now we sum
the pixel count for all the screens when making this decision.
Differential Revision: https://phabricator.services.mozilla.com/D46066
--HG--
extra : moz-landing-system : lando
This removes a lot of old cruft in thebes to instantiate Cairo scaled fonts.
Instead, we only instantiate the Cairo scaled font inside Moz2D when we actually
need it for DrawTargetCairo. This thus gets rid of the duplicated code we had
inside both Moz2D and thebes to deal with Cairo scaled fonts.
Differential Revision: https://phabricator.services.mozilla.com/D47297
--HG--
extra : moz-landing-system : lando
This approach does have some stacking issues. The way to fix this would
be to instrument the brush_image shader rather than adding debug rects.
Something like: #ifdef WR_FEATURE_SFW frag.color = vec4(0,1,1,1); #endif
That's slightly more involved though, so I'm going to leave it for now.
Differential Revision: https://phabricator.services.mozilla.com/D47155
--HG--
extra : moz-landing-system : lando
When Windows version is mort than 1903 and GPU is intel GPU, it could cause flickering with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL. See Bug 1556634. As a short term workaround, use DXGI_ALPHA_MODE_PREMULTIPLIED instead of DXGI_ALPHA_MODE_IGNORE at SwapChain.
Differential Revision: https://phabricator.services.mozilla.com/D41713
--HG--
extra : moz-landing-system : lando
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Differential Revision: https://phabricator.services.mozilla.com/D41274
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
StaticPrefs.h will be removed two commits from now, so update these comments.
The patch removes the comment above SetUsesContainerScrolling() because it's
wrong -- it did use static prefs when introduced by bug 1181832 but then
stopped using static prefs in bug 1470504 -- and makes it inlinable.
Differential Revision: https://phabricator.services.mozilla.com/D39133
--HG--
extra : moz-landing-system : lando
These files exist because they were the proof-of-concept first step for
splitting the static prefs header files. Now that those header files can be
generated from a script, we need to move the `accessibility.*` prefs into the
YAML file.
Differential Revision: https://phabricator.services.mozilla.com/D39132
--HG--
extra : moz-landing-system : lando
The RemoveShaderCacheFromDiskIfNecessary() needs to be called after WebRenderConfig initialization.
Differential Revision: https://phabricator.services.mozilla.com/D38978
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
This better distinguishes it from the pref name part of the getter, which uses
snake case.
Differential Revision: https://phabricator.services.mozilla.com/D38603
--HG--
extra : moz-landing-system : lando
When double buffering is enable with compositor, DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL is used without DirectComposition. There are some devices that swap chain with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL does not work well. In this case, device reset happens very often. To avoid the situation, the double buffering needs to be disabled when device reset happens.
Differential Revision: https://phabricator.services.mozilla.com/D36579
--HG--
extra : moz-landing-system : lando
This implements the machinery for the splitting of static prefs headers, and
uses it for a single header. #includes are used in such a way that the amount
of boilerplate for each static prefs header file is minimal.
Future patches will split the remaining prefs into more header files.
Differential Revision: https://phabricator.services.mozilla.com/D36154
--HG--
rename : modules/libpref/StaticPrefs.h => modules/libpref/StaticPrefsBase.h
rename : modules/libpref/StaticPrefs.h => modules/libpref/init/StaticPrefListBegin.h
extra : moz-landing-system : lando
This uses positive-but-empty #if conditions with else clauses rather than
inverted conditions for better readability and documentation.
Differential Revision: https://phabricator.services.mozilla.com/D37083
--HG--
extra : moz-landing-system : lando
Now that all static pref getters use snake_case, these renamings make sense:
- Getfoo_bar_bazPrefName() -> GetPrefName_foo_bar_baz()
- Getfoo_bar_bazPrefDefault() -> GetPrefDefault_foo_bar_baz()
Differential Revision: https://phabricator.services.mozilla.com/D36563
--HG--
extra : moz-landing-system : lando
Also converts webgl.pref-16bpp from a VarCache pref to a normal pref, because
it doesn't need to be a VarCache pref.
Differential Revision: https://phabricator.services.mozilla.com/D36397
--HG--
extra : rebase_source : 5aa1d251b751c41ec525fef7d0467ffebe401d9a
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
This is a temporary fix for the tests in test_pref_rollout_workaround. The
tests are permafailing because they are now always running with MOZ_WEBRENDER=0
which breaks assumptions inside the test.
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
This adds the base64 encoded color profile to the about:support page in
order to allow us to better diagnose and reproduce color management
issues. We can extract this, decode it and load it directly via the
gfx.color_management.display_profile pref.
Wayland does not support remote drawing for widgets from another process
at this time. As such, it is best to force disable the GPU process, so
that users will be able to get WebRender with Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D32640
Listing the preferences in either all.js or StaticPrefList.h would also make them appear in about:config which is something we don't want.
Additionally, rename some pref constants to improve code clarity as we can no longer rely on using the StaticPrefs accessor.
Differential Revision: https://phabricator.services.mozilla.com/D32416
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Listing the preferences in either all.js or StaticPrefList.h would also make them appear in about:config which is something we don't want.
Additionally, rename some pref constants to improve code clarity as we can no longer rely on using the StaticPrefs accessor.
Differential Revision: https://phabricator.services.mozilla.com/D32416
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
StaticPrefs doesn't support nsCString type and the changes required to support this would be rather big. Seeing that there was only a single gfxPrefs using this, and this is a "Once" pref ; we move it to gfxVars instead.
Differential Revision: https://phabricator.services.mozilla.com/D31462
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
I think we just accidentally forgot these ids when we added more mobile
chips.
Differential Revision: https://phabricator.services.mozilla.com/D30940
--HG--
extra : moz-landing-system : lando
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
WebRender has been on in Nightly on AMD hardware for a while with no
complaint. Let's let it ride further.
Differential Revision: https://phabricator.services.mozilla.com/D29416
--HG--
extra : moz-landing-system : lando
Send tasks to dispatch our other wayland event queues from their respective threads whenever we service the GTK main event loop.
Differential Revision: https://phabricator.services.mozilla.com/D28819
--HG--
extra : moz-landing-system : lando
When GPU process does not exist, Render thread is created by gfxPlatform::InitLayersIPC(). Then gfxVars::SetProfDirectory() is called after RenderThread::InitDeviceTask(). Then WebRenderProgramCache could not get correct gfxVars::ProfDirectory() value. It affects to webrender shader disk cache.
Differential Revision: https://phabricator.services.mozilla.com/D28793
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
We haven't seen any AMD related bugs on Nightly so I'd like to expand
our scope further.
Differential Revision: https://phabricator.services.mozilla.com/D23944
--HG--
extra : moz-landing-system : lando
We haven't seen any AMD related bugs on Nightly so I'd like to expand
our scope further.
Differential Revision: https://phabricator.services.mozilla.com/D23944
--HG--
extra : moz-landing-system : lando
We can get back the fancy flag syntax as soon as we get C++17 inline variables,
which I sent an email to dev-platform@ about, with no reply.
Differential Revision: https://phabricator.services.mozilla.com/D22382
--HG--
extra : moz-landing-system : lando
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
In this case, moving ShutdownTileCache()'s function declaration to the header file TiledContentClient.h means the same declaration will be seen by the TiledContentClient.cpp file defining the function and the gfxPlatform.cpp calling the function.
gfx/layers/client/TiledContentClient.cpp:337:6 [-Wmissing-prototypes] no previous prototype for function 'ShutdownTileCache'
Differential Revision: https://phabricator.services.mozilla.com/D20267
--HG--
extra : source : 495273cd3fdc65f353d5562573503fc897760603
extra : histedit_source : fab19badff1cadd66212cf182978217b398c0fe6
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/thebes/gfxBlur.cpp:444:6 [-Wmissing-prototypes] no previous prototype for function 'CacheBlur'
gfx/thebes/gfxPlatform.cpp:1087:6 [-Wmissing-prototypes] no previous prototype for function 'IsFeatureSupported'
gfx/thebes/gfxPlatform.cpp:1355:6 [-Wmissing-prototypes] no previous prototype for function 'SourceBufferDestroy'
gfx/thebes/gfxPlatform.cpp:1365:6 [-Wmissing-prototypes] no previous prototype for function 'SourceSurfaceDestroyed'
gfx/thebes/gfxPlatform.cpp:2422:6 [-Wmissing-prototypes] no previous prototype for function 'VideoDecodingFailedChangedCallback'
gfx/thebes/gfxPlatform.cpp:559:6 [-Wmissing-prototypes] no previous prototype for function 'WebRenderDebugPrefChangeCallback'
widget/GfxInfoBase.cpp:82:6 [-Wmissing-prototypes] no previous prototype for function 'InitGfxDriverInfoShutdownObserver'
Differential Revision: https://phabricator.services.mozilla.com/D20260
--HG--
extra : source : b8333099bca51db166839862e4a3918c5e8874f2
extra : intermediate-source : acb4bb2466df7fb22ca1a76e13c79186ea938bc1
extra : histedit_source : 16cf3a96596046e8111774a147b23ade0676c8e1
Preferrably CreateOffscreenContentDrawTarget would create Capture DrawTargets when we intend to use OMTP. This is not the case at the moment though and changing this would likely introduce more unforseen issues. For now all of these calls basically mean a DrawTarget will be used on the main thread and we should use a no-op ClearRect to ensure that the DrawTarget is actually initialized. Since IsValid for the moment won't do this for DrawTargetD2D. (See bug 1521368)
--HG--
extra : rebase_source : 6a5c1732d3908be748ea4d05668f4a7562828f6a
Preferrably CreateOffscreenContentDrawTarget would create Capture DrawTargets when we intend to use OMTP. This is not the case at the moment though and changing this would likely introduce more unforseen issues. For now all of these calls basically mean a DrawTarget will be used on the main thread and we should use a no-op ClearRect to ensure that the DrawTarget is actually initialized. Since IsValid for the moment won't do this for DrawTargetD2D. (See bug 1521368)
Differential Revision: https://phabricator.services.mozilla.com/D21037
--HG--
extra : rebase_source : 7b9f4c5ed66d5ecaf613634c660f085de3584fd3
This should help increase our WebRender usage so we're more likely to learn
about problems with minimal additional risk.
Differential Revision: https://phabricator.services.mozilla.com/D18020
--HG--
extra : moz-landing-system : lando