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.
