The logic missed a pair of brackets, leading to memory regions
being merged that shouldn't have been merged (anonymous regions
with access flags set getting merged into the previous mapping)
Differential Revision: https://phabricator.services.mozilla.com/D106772
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
We have encountered issues on some platforms due to a large number of
if statements in shaders. The shader optimizer previously generated
code with a large number of if statements, due to the way in which it
optimized switch statements.
Previously the optimizer output 2 if statements for every case in a
switch. First it ORs the "fallthrough" var with the case's
condition. Then sets the fallthrough var to false if the "break" var
is true. Then conditionally executes the case's instructions if
fallthrough is true. For example:
switch (uMode) {
case 0:
gl_Position = vec4(0.0);
break;
case 1:
gl_Position = vec4(1.0);
break;
}
becomes:
bool break_var = bool(0);
bool fallthrough_var = (0 == uMode);
if (break_var) fallthrough_var = bool(0);
if (fallthrough_var) {
gl_Position = vec4(0.0, 0.0, 0.0, 0.0);
break_var = bool(1);
};
fallthrough_var = (fallthrough_var || (1 == uMode));
if (break_var) fallthrough_var = bool(0);
if (fallthrough_var) {
gl_Position = vec4(1.0, 1.0, 1.0, 1.0);
break_var = bool(1);
};
This update removes one of these ifs, by ANDing the fallthrough_var
with !break_var rather than conditionally setting it to false. eg:
bool break_var = bool(0);
bool fallthrough_var = (0 == uMode);
if (fallthrough_var) {
gl_Position = vec4(0.0, 0.0, 0.0, 0.0);
break_var = bool(1);
};
fallthrough_var = (fallthrough_var || (1 == uMode));
fallthrough_var = (fallthrough_var && !(break_var));
if (fallthrough_var) {
gl_Position = vec4(1.0, 1.0, 1.0, 1.0);
break_var = bool(1);
};
This is logically equivalent but uses half as many if statements,
which helps to avoid driver bugs on some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D103713
Bumps version to
3011a2b923c8b0f1b392bcdd008cd8b95ffd846b
This is done to fix a bug where parsing bad metadata in the userdata (udta)
would be fatal when we should instead just fail the userdata.
This also updates some mp4parse-rust dependencies which results in some
removals.
Differential Revision: https://phabricator.services.mozilla.com/D102997
Bumps version to
3011a2b923c8b0f1b392bcdd008cd8b95ffd846b
This is done to fix a bug where parsing bad metadata in the userdata (udta)
would be fatal when we should instead just fail the userdata.
This also updates some mp4parse-rust dependencies which results in some
removals.
Differential Revision: https://phabricator.services.mozilla.com/D102997
Pull in a number of new SIMD opcodes, and a change from iNxM.any_true
to v128.any_true. Plus whatever else has landed in the mean time...
Differential Revision: https://phabricator.services.mozilla.com/D102398
Now that we use an external dump_syms, we don't need to build
breakpad's.
This means we also don't need the dump_syms_rust_demangle crate anymore.
Differential Revision: https://phabricator.services.mozilla.com/D101865
The new version contains
- A bug fix for the bucketed allocator (we don't currently use it)
- A few fixes that can happen when requesting large enough allocation sizes to cause integer overflows. At the moment we never request an allocation larger than 512px so we are safe but it's still good to stay up to date.
Differential Revision: https://phabricator.services.mozilla.com/D101608
