Some gfx drivers (especially on a child process) can open X11 VADisplay instead of a Wayland one which leads
to HW playback failure. As a solution let's create VADisplay explicitly on top of our wayland display connection.
- Load va-api/wayland related libraries only when va-api is enabed by user by widget.wayland-dmabuf-vaapi.enabled
and va-api is generally available (HW acceleration is enabled, dmabuf is available).
- Load vaGetDisplayWl from libva-wayland.so
- Explicitly create VADisplay at CreateVAAPIDeviceContext()
- Use VAAPIDisplayHolder class to release our VADisplay when AVHWDeviceContext is released (by hwctx->free).
Differential Revision: https://phabricator.services.mozilla.com/D71219
Add a gecko pref "gfx.webrender.use-optimized-shaders". If enabled,
then when attempting to compile a webrender shader first look for the
optimized source. If the optimized source is not present, emit a
warning and fall back to the unoptimized source.
Use the optimized source by default in wrench, and add the flag
"--use-unoptimized-shaders" to override this.
Differential Revision: https://phabricator.services.mozilla.com/D70033
Move more shader parsing code to webrender_build, so it can be used
both at runtime and build time.
At build time optimize a set of shaders and feature flag combinations,
using glslopt. Some features are skipped because they are not
supported by the gl version, because the optimizer does not support
them, or because webrender does not need them currently.
Use build-parallel to ensure the optimization is performed in parallel
using the make jobserver. Write the optimized shader source to a
hashmap to be used at runtime, in addition to the unoptimized source.
Differential Revision: https://phabricator.services.mozilla.com/D70032
* For wrench builds, the clang toolchain must now be fetched and be
present in PATH for bindgen to work. When building OSMesa, we must
therefore set `LLVM_CONFIG=no` so that it does not attempt to build
llvmpipe.
* For wrench Mac cross-compiles, we must be careful to expose CFLAGS
and similar variables using the target-specific variable names, so
that host builds do not attempt to use flags intended for the
target. When building OSMesa we must use the generic variable `CC`,
so now we additionally set `HOST_CC`, so that host builds use the
host variable rather than the generic one.
* Similarily, for wrench android builds we must use a fork of
cargo-apk which sets the target-specific variables rather than the
generic ones. Otherwise we would attempt to use the NDK toolchain
for host builds.
Differential Revision: https://phabricator.services.mozilla.com/D70031
For native sanitizer builds, we currently do not pass the linker flags
to cargo, as they were causing crashes in some build scripts. Without
this, however, the linker is unable to find libstdc++. Instead, do
tell cargo to use the linker wrapper, but omit the problematic flags
from MOZ_CARGO_WRAP_LDFLAGS.
Differential Revision: https://phabricator.services.mozilla.com/D70354
This commit firstly moves ResultType and BlockType from WasmOpIter.h to
WasmTypes.h. Many parts of the WebAssembly implementation find
themselves dealing in ResultType so it's natural to define these data
types in a more central place.
Then we add a field to DebugFrame, for the stack results area. This
field is initialized in the baseline compiler prologue, in debug mode.
We also separate the notion of a debug frame with ref-typed cached JS
return values, and a frame with ref-typed result(s). This allows proper
marking of i64 values exposed as BigInt, as well as marking arrays from
multi-result functions of any type.
Finally, we now expose the guts of the ToJSValue code in WasmInstance to
allow the debug trap to synthesize a JS value for a wasm result, even
for multiple value results.
Differential Revision: https://phabricator.services.mozilla.com/D70531
This adds support for instructions that return a new value. In this case the
CacheIRWriter returns a new id of this kind.
Depends on D71520
Differential Revision: https://phabricator.services.mozilla.com/D71521
This adds WrappedPtrOperations and MutableWrappedPtrOperations specialisations for Maybe<T> to all basic Maybe operations to used on Rooted<Maybe<T>>, Handle<Maybe<T>>, etc. I didn't add all of them; in particular I found ptr() would conflict with the Rooted::ptr data member.
This also adds JS::NothingHandleValue for passing Nothing to a Handle<Maybe<Value>>.
Differential Revision: https://phabricator.services.mozilla.com/D71555
- Worker debugger globals gets a client with a null principal
- Ensure globals are created before script loads
- Introduce WorkerGlobalScopeBase to share code
- Transfer ClientSource ownership from WorkerPrivate to worker globals
- Require getting clients from the globals instead of WorkerPrivate with the
exception of getting the reserved client before the non-debugger global is
created
Differential Revision: https://phabricator.services.mozilla.com/D68936
Since we don't support downscaling animated images we'll need something like this even we were to try to request a smaller sized decode.
Differential Revision: https://phabricator.services.mozilla.com/D71523
In the past EGL only supported GLES, not OGL. This has not been true
for a very long time, so lets support OGL context creation in the EGL
backend.
This allows e.g. the Wayland backend to use OGL contexts, which brings
it on par with the X11/GLX backend.
Differential Revision: https://phabricator.services.mozilla.com/D48096
Subhamoy Sengupta
sonakshi
Lee Salzman
Tooru Fujisawa
Brindusan Cristian
Robert Mader
devRD
Daosheng Mu
Glenn Watson
Martin Stransky
Tim Nguyen
Narcis Beleuzu
Kagami Sascha Rosylight
Andrea Marchesini
Jamie Nicol
Dão Gottwald
aarushivij
Andy Wingo
Benjamin Bouvier
Luca Greco
Tarek Ziadé
Jan de Mooij
Jon Coppeard
Makoto Kato
Paul Adenot
Perry Jiang
Emma Malysz
Timothy Nikkel