> To be sure I threw some 'export EMCC_WASM_BACKEND=1's around my build
scripts, but I don't think they're necessary?

Correct, when using a build of LLVM without asm.js installed (like the
upstream builds for the emsdk) it will automatically use the LLVM wasm
backend (as it's the only option possible).

Pthreads: the wasm backend path and pthreads are not quite ready yet, there
are some known issues, and the test suite doesn't pass yet. Very close
though.

> Possibly this upstream-3346 doesn't include all the latest updates from
1.38.27, though it claims to be 1.38.27 in emcc --version?

It should - we update the version number when we tag, so it could only be
later than the tag time, not earlier.

On Fri, Feb 22, 2019 at 10:29 PM Brion Vibber <[email protected]> wrote:

> I spent a little time trying to get ogv.js's codec modules building with
> the LLVM native wasm backend in the hopes of trying out the SIMD mode with
> Chrome's experimental flags, with only partial success so far.
>
> Setting up:
> On Linux, 'emsdk install latest-upstream' works; notes below are for
> testing with upstream-3346. On macOS, I can manually install and activate
> 'emscripten-incoming-64bit' and 'upstream-clang-master-64bit' but I'm still
> trying to confirm they work correctly.
>
> Using:
> It's not easy to use LLVM backend and fastcomp side-by-side so I had to
> disable asm.js builds in the branch for now.
>
> To be sure I threw some 'export EMCC_WASM_BACKEND=1's around my build
> scripts, but I don't think they're necessary?
>
> I also had some trouble with Wasm object files throwing warnings during
> link, which may be related to debug info --
> https://github.com/emscripten-core/emscripten/issues/8158
> For now I've told it to use bitcode object files by setting '-s
> WASM_OBJECT_FILES=0', leaving bitcode->Wasm transformation to the end, and
> it silences those warnings.
>
> Atomics:
> When building the dav1d AV1 video decoder with fastcomp, atomic intrinsics
> used in the thread-related code seemed to devolve cleanly, but on
> non-threaded builds with LLVM backend I was getting a validation failure
> due to their use. I worked around this by #defining them into non-atomic
> operations for single-threaded builds.
>
> Pthreads:
> Pthreads builds don't work, at least with modularize mode:
> TypeError: Module.__register_pthread_ptr is not a function
>
> Possibly this upstream-3346 doesn't include all the latest updates from
> 1.38.27, though it claims to be 1.38.27 in emcc --version?
>
> There's also a difference in path handling for the .js.mem memory init
> file that's created with pthreads builds; with the LLVM backend the
> directory prefix 'build/' was getting picked up and saved in the loaded
> path where previously that was not included in the path passed to
> locateFile.
>
> SIMD:
> I can make autovectorized builds of dav1d AV1 video decoder with '-s
> SIMD=1' but they fail hard with "memory access out of bounds" during some
> initialization. However I'm not sure the build is correct to begin with so
> haven't spent much time on that yet...
>
> Correctness:
> The demuxing, audio decoding and the Theora video codec seem to work ok
> under the LLVM backend.
>
> There's some kind of data corruption problem with the AV1 video decoder
> dav1d; images get progessively more corrupt until a keyframe resets the
> picture state, indicating something's feeding bad data into the
> frame-by-frame updates. I haven't narrowed down the cause of it yet.
>
> libvpx (VP8/VP9 decoder) has some sort of linking failure partway through
> making libvpx.a so I can't build the modules. I'll try to narrow it down.
>
> -- brion
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to