[00:00] When I add dev firefox, it always overwrites Other Firefox [00:00] firefox and nightly should coexist but might cause problems if you let it share a profile [00:00] like you have to close all your ff processes to start nightly, and vice versa [00:00] Shiiiiiiiiiiiiiiiity [00:01] you can launch it with different command line parameters to make it use a separate profile but I always forget :D [00:01] Same [00:04] TypeError: wasm validation error: at offset 8: binary version 0xc does not match expected version 0xd [00:04] There, I'm messed up on both [00:07] hmm, now I'm using the code to create an instance and getting: [00:07] TypeError: WebAssembly.Instance(): Import #0 module="env" function="STACKTOP" error: module is not an object or function at pacman.html:14 [00:09] (I'm not seeing this on shift-reload) [00:11] yeah, this is specifically with chrome dev build. still hammering at it [00:12] I'm guessing that the compiled output is referencing some module named "env" and I'm expected to provide it somehow? [00:12] db48x: Any thoughts [00:13] bai: the first input to Instance should be a module. if it says "module is not an object", maybe there was a problem creating that? [00:15] hmm, how would I check? this is inside the promise, after calling WebAssembly.compile() - presumably if it failed it wouldn't call the .then() function right? [00:16] i'm not that familiar with promises, but yeah, what you say makes sense. but maybe console.log('module: ' + module) in the then handler, would show something? [00:16] btw, is this code you wrote yourself to create the module and instance, or from somewhere? [00:16] when I log the compiled object it just says it's "Object {}" in the console [00:16] and no properties when expanding [00:16] I'm basing it on this http://webassembly.org/getting-started/js-api/ [00:16] does it work in other browsers? could be a chrome bug [00:17] yeah, let me recompile the toolchain and tery with the latest bleeding edge versions [00:17] it's still using the 0xc build I did the other day [00:26] azakai: is binaryen-version_18 the correct one? [00:27] bai: yes [00:27] ok cool [00:30] ok, got an 0xd build now. it loads the code in ff nightly now, gives me a WebAssembly.Module object, but then "TypeError: import object field 'env' is not an Object" [00:30] so this build is trying to include some module called "env" which I have to define? [00:31] the second parameter to Instance should be an object, yeah, with imports [00:31] or just {} if there are no imports [00:32] hmm. I guess I'll have to figure out where that import is coming from then. it's not something I specifically added, how are imports normally specified when compiling? [00:32] in emscripten, any unresolved symbols are assumed to be imported into wasm. and we look in the js libs for them [00:32] ahh, hmm [00:33] so if you have extern "C" void func() and never implement it, it assumes you import it [00:33] I think some of the pre or post.js code might look for Module.env [00:39] hmm ok, yeah I think I just need to set up some env values here, it's basically just throwing errors for undefined ENV variables [00:40] hmm, these seem like internal emscripten values. STACKTOP, STACK_BASE, STACK_MAX [00:44] yeah, I can define each of those and it moves on to a different error, but now I'm getting errors like [00:44] TypeError: import object field 'cttz_i8' is not a number [00:44] that's an internal emscripten libc thing [00:44] emcc should hook up all this for you automatically. i'm not sure what you're doing - are you trying to do everything manually? [00:45] I guess so yeah. I didn't get a .html file when I compiled [00:45] emcc -o a.html will make it emit an html [00:45] or just put the js it gives you in an html [00:46] oh, so you do need the .js and the .wasm? [00:46] the js loads the wasm [00:47] if you emit -o a.js, you'll get a js and a wasm (and maybe others, like a .mem, depending on opts) [00:49] I get .asm.js .js .wasm .wast [00:50] hmm yeah, those might be needed depending on opts - you can tell it to run the .asm.js instead of the wasm. or to interpret the wast [00:50] we should probably not emit those unless necessary [00:51] I see, so .asm.js is backwards compatible for non-webassembly builds, and the wast is just the s-expr version of the .wasm file? [00:51] yes [00:52] and the .js file contains some emscripten runtime stuff which sets up the execution environment [00:53] yes [00:54] ok, in that case our loader probably doesn't change much, if the .js file exposes the same interface as the old pre-webassembly stuff did [00:54] I thought we were supposed to load the .wasm file directly, but there's still that layer which implements the emscripten-to-browser translation layer, that makes sense [00:54] one thing you might need to change is to preload the .wasm file into Module.wasmBinary [00:55] as the js code needs it to be there when it runs [00:55] ok, yeah that should be easy enough [00:56] is it normal for that basic .js file to be 5.5mb? all of my app's code should be in the .wasm block right? [00:56] that does sound odd, yes, all compiled code should be in asm.js and wasm [00:56] could be in an -O0 build, the memory init is in the js file, which could be big [00:57] the .wasm is 7.2mb and the .asm.js is 48mb, which is significantly bigger than normal builds. maybe some peculiarity with mame's build system [00:57] the asm.js isn't minified, which is why it's larger [00:57] I'll check to make sure it's not doing -O0 but I think default should be -O3 [00:58] ah yeah I forgot about the memory init stuff [00:58] that's probably what it is [01:01] i have to go, ttyl [01:01] thanks! [01:01] np [01:01] *** azakai has quit IRC (Quit: Ex-Chat) [01:04] well, now I can reliably crash firefox, so that's progress! [01:05] it was complaining about not having a canvas, so it was getting pretty close. I gave it a canvas and now it's dying [01:05] we build with --memory-init-file 0 so the memory init is always in the js file [01:06] yup [01:06] anyway, now that I know how to load it all in, I'll try using the loaders to make sure the whole environment's being set up [01:06] I'm not passing in any roms or anything yet, but at least the wasm code is loading and starting to execute [01:09] btw, when the .js and .wasm file are gzipped, that's a total size of about 2.4mb. current builds are what, 10-15mb? [01:11] ~3.2mb gzipped https://archive.org/download/emularity_engine_v1/ [01:19] Both Nightly and Canary crash [01:21] So that's consistent. Chrome crashes with a little more glibness [02:12] looking promising http://i.imgur.com/PvbcCWm.png [02:12] now it's all just setting up the roms [02:43] well...it's running, but not fast: http://baicoianu.com/~bai/emularity/pacman.html [02:57] Mine both crash./ [03:00] huh. [03:00] lemme try on my desktop. they were crashing there too, but when I switched to my laptop they started working [03:09] crashes nightly on my desktop, but chrome canary works [03:09] still slow though [03:09] unusably so [03:10] but, we have a starting point now [03:11] Not clear, from here. [03:12] Agreed, a start. I've not seen it run. [03:12] If you press F11, what percentage do you get [03:12] ooh, I got a version running fast in canary now [03:13] 100% in canary now. it was more like .1% before [03:13] difference being native-wasm vs interpreted-binary [03:13] I'm not getting this at all. [03:13] I have no explanation for that [03:13] you're using the new url, not refreshing the old url, right? [03:14] Wait no [03:14] Yes, I was [03:14] http://baicoianu.com/~bai/emularity/pacman.html is the version that's running through emularity [03:16] Trying my laptop (Windows 10) vs. My windows 7 [03:16] yeah both of these systems are windows 10 [03:18] I'll have to build jaguar to see if there's any performance benefit here [03:18] pacman always ran at 100% [03:18] load time seems to be generally better [03:18] Be weird if that was the case [03:19] (Windows 10 vs. Windows) [03:19] 7 [03:19] Let me find you another thing [03:19] Ah, I have one. [03:20] (If at all possible, make more *.html ones, so we can compare this pacman. [03:21] Do simon [03:21] http://fos.textfiles.com/dfjustin/simon/simon.zip (all the files) [03:22] hmm, do you know what driver that uses? [03:23] oh it's mess, not mame, isn't it [03:24] Should all be mame now [03:24] And SHOULD be "simon" [03:24] Let me check [03:26] It's simon [03:26] Except it's going to be mamesimon being generated now. [03:27] Also, bai: https://archive.org/details/ia20thanniversaryevent_images [03:28] Simon is a big one [03:30] woahhh http://baicoianu.com/~bai/emularity/jaguar.html [03:30] it's....it roared at me [03:30] at 100% speed [03:31] can't proceed past the jaguar screen though, hmm [03:31] oh I probably need to use a cart, not a rom [03:31] Yes [03:31] You need a cart. [03:31] That's why [03:33] Need one? Or got it [03:35] oh yeah. this is good. http://baicoianu.com/~bai/emularity/jaguar.html [03:36] it's still not quite 100% but it is a significant improvement [03:36] I promise you, simon's the big one [03:36] roughly 70%, and playable [03:36] yeah, I'm not quite sure how to build that one, I'm not seeing a simon.cpp in src/mame/drivers/ [03:37] I get 85% the laptop for Jaguar, which is notable. [03:38] yeah, dfjustin's build in the same browser is about 20% [03:38] 20% to 70% is a damn nice improvement [03:38] It is. [03:39] Same here: 22% went to 85% [03:39] I have 48 to 84. [03:40] Running them next to eachj other because how could the system hate that [03:40] excellent. I'll show this to azakai tomorrow, we have a test case which works brilliantly in chrome and crashes firefox [03:40] haha [03:40] 33-65% [03:41] Let me think of one like simon for you [03:41] Did I explain why this is so important or did I fail at that [03:41] looks like ff is definitely getting to the point where it's booting mame, but something in the bootup process makes it crash [03:41] why simon is important, or why webassembly is important? [03:42] simon [03:42] simon runs at 25,000%. [03:42] Literally [03:42] But it sounds AWFUL [03:42] because of The Problems [03:43] It's an example of not being able to throw silicon at the problem [03:43] if you can find the command that's used to build that one I'll give it a try [03:44] Found it [03:44] Let me determine what it's exactly called [03:44] hh_tms1k [03:45] Also, megadriv, please [03:49] That will be a good set for performance. [03:49] pacman, hh_tms1k, jaguar, megadriv [03:49] http://baicoianu.com/~bai/emularity/simon.html [03:49] That's all up and down the map and all up and down the map in terms of performance quirks [03:49] memory access out of bounds for that one [03:50] I got some errors about missing symbols while building though [03:50] so might be another driver I need to include [03:50] Try ti [03:50] Instead of hh_tms1k [03:51] which ti? [03:51] createMESSProjects(_target, _subtarget, "ti") [03:51] files { [03:51] Oh I see [03:51] Ignore me [03:52] DFJustin will have better ideas. [03:52] Megadriv then [03:52] With good ol' sonic [03:52] url me to the romz [03:53] http://fos.textfiles.com/dfjustin/megadriv/genesis.zip [03:53] You're welcome to do others, of course [03:53] And as soon as I can I will do more [03:54] If yoy make a cheat sheet I could make a messaround environment [03:55] I want to see if sound glitching on 100% items is gone [03:55] a800 is the master of glitching [03:57] sonic http://baicoianu.com/~bai/emularity/sonic.html [03:57] 100% [03:59] interesting, even though it's 100% it feels a lot slower than dfjustin's build [04:04] OK. [04:04] If you can do a800 tonight, great. [04:05] That's Preppie! and glitch superbnlu [04:17] Weird, sonic won't load at all [04:18] Oh, syntax error in line 56. [04:18] "missing ) after argument list" [04:26] the command you want to find out the driver name is mame -listsource [04:45] yeah, just had to do a full build [04:46] fixed sonic [04:56] Can you do a800? I can put in the preppie! and the rest [04:56] I don't hear any skipping with sonic [04:57] https://archive.org/download/atr_Preppie_1982_Adventure_International_k-file/Preppie_1982_Adventure_International_k-file.atr [05:00] Unlike JSMESS, I can go between tabs, come back, and it "fixes" the sound [05:33] so is this built with EMCC_WASM_BACKEND=1 yet? [05:33] I'm using -s BINARYEN=1 [05:33] and it's generating .wasm output [05:33] I assume that's the same thing? [05:34] what it does by default is compile to asm.js and then translate that into wasm in a second step [05:34] ahh ok [05:34] there's also an experimental full wasm toolchain [05:34] yeah, I guess I'm not using that yet then [05:34] https://github.com/WebAssembly/binaryen#cc-source--webassembly-llvm-backend--s2wasm--webassembly [05:34] the end result should be the same? or more optimizations? [05:34] that's where I expected most of the benefit to come from actually [05:34] because native 64-bit ints etc [05:35] I'll give it a try [05:35] where should I put this, should just setting it in my env work? [05:36] probably, or prepend it to ./emcc in scripts/src/main.lua [05:37] ok sonic is running at the wrong speed because you picked the PAL megadrive [05:38] you want 'genesis' [05:39] CRITICAL:root:WebAssembly set as target, but LLVM has not been built with the WebAssembly backend, llc reports: [05:39] ah ok that's good to know about sonic [05:39] guess I have to build some additional llvm backend support [05:51] hmm. not finding much info on what I need here [05:51] https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend seems to just say that argument is all you need [05:52] emscripten seems to only report the following backends: [05:52] how recently did you update your llvm tree [05:52] js - JavaScript (asm.js, emscripten) backend [05:52] x86 - 32-bit X86: Pentium-Pro and above [05:52] x86-64 - 64-bit X86: EM64T and AMD64 [05:53] hmm. I guess that depends, I updated clang-incoming-64bit emscripten-incoming-64bit and sdk-incoming-64bit using emsdk a few hours ago [05:53] would that have updated my llvm tree? [05:54] I don't think the wasm backend has been upstreamed yet [05:54] oh emsdk hmm never used that [05:55] yeah my first time too [05:57] may need to add something to the cmake list of targets https://kripken.github.io/emscripten-site/docs/building_from_source/building_fastcomp_manually_from_source.html#building-fastcomp [05:58] hmm yeah, that rings a bell, let me see if I can modify what emsdk does [06:00] found it, time to rebuild [06:16] you guys are way ahead of me [06:16] I'm still trying to get modularized builds working [06:17] db48x: there's just one teeny tiny change needed to make wasm builds work in Emularity [06:17] right now I'm manually doing an XHR, fetching the .wasm file, then setting thatthe contents of that file as Module.wasmBinary [06:18] but it should be easy enough to make that part of the chain of arguments you pass to the Emulator constructor [06:18] easy enough indeed [06:19] I'm using emulator.setCallbacks({ before_emulator: function() { ... } }) [06:20] :) [06:20] nice and flexible [06:20] but an argument would be cleaner [06:24] I'll look into what's needed to make the modularize change [06:24] the only complication will be that SAE needs something different to do wasm [06:25] ah, yeah dunno how this will work with sae [06:25] sae isn't emscripten-compiled at all is it? hand-crafted js? [06:25] Right [06:25] yep [06:25] SAE's it's own thing [06:25] yeah, making that use wasm would be a whole rewrite, but this shouldn't interfere with that [06:26] Anyway, if you do a800, I think that's enough and we can wait for Azakai to come back to the flaming, insane wreck we left [06:26] dosbox as wasm should hopefully be smooth too, this was pretty painless [06:26] but we'll see once I have it using wasm end to end [06:26] dosbox as WASM will run Windows 95 [06:26] Horrifyingly [06:26] SketchCow: DFJustin made me go deeper [06:26] DEEPER [06:26] What way [06:26] more optimizations to be had by enabling wasm output further down the toolchain [06:27] rather than compiling to asm.js then converting to wasm which is apparently what I did [06:27] oh yea, I remember why I wasn't able to figure this out [06:27] when I step over the call to Module({ ... }); the debugger takes a little nap [06:28] and by "debugger" I mean "all of firefox" [06:29] heh [06:29] yeah just loading the emscripten-compiled js file in the source tab is bad enough [06:29] last time it was using 15gb of memory and 100% of a cpu, now it's just 10gb and 100% [06:30] hey, that's 50% improvement [06:31] oh nice, it's actually using 19gb of address space [06:42] Confirmed, crashes Canary on Android [06:42] But we now think it's doing too much which is why [07:10] bai: Let me know when you're done for the evening. :) [07:11] still poking. I rebuilt the toolchain but it still didn't build the right backend [07:18] hmm, I get a lot of "A web page is slowing down your browser" with the wasm builds in Firefox 52 on Kubuntu [07:18] is that expected? [07:20] So, we think things are not good yet [07:21] And that it's one of those cases where the browser versions that can withstand unreasonable pain are living [07:21] ah [07:23] Like, right now, I can see my Windows 10 is running Google Canary with this in it at 352mb [07:25] Firefox 52 here is eating around 698 MB on the Jaguar machine [07:29] yipdw: yeah I was seeing a lot of those in firefox, but then it was crashing [07:30] it seems about 50/50 either it runs or crashes [07:30] runs on my laptop, crashes on my desktop [07:30] heh [07:31] I'll give the dev chromium a shot [07:31] can't seem to get this WebAssembly backend to build. claims it's not a supported target, even though all the files for it are definitely there [07:31] I think it has to be canary, dev branch is still slightly behind [07:31] oh [07:31] Is it an error or something else [07:31] The target `WebAssembly' does not exist. [07:31] It should be one of [07:31] AArch64;AMDGPU;ARM;BPF;Hexagon;JSBackend;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;X86;XCore [07:33] yipdw: Yeah, has to be canary [07:33] ok, I'll give it a shot on my Windows machine then [07:33] AFAIK there's no Canary build for Linux [07:33] I find it crashes on Win7 but not Win8 [07:33] I guess I *could* build chromium from source code, but I have been told it's vastly unpleasant [07:34] I'm not sure the os has anything to do with it, I have one working win10 and one broken [07:46] Does https://github.com/WebAssembly/binaryen help inform you, bai? [07:48] well, that's where we started, I need to set EMCC_WASM_BACKEND=1 while compiling [07:49] but to do that, I need to compile emcc to know about the wasm backend [07:49] the version I have has all the files to target WebAssembly, but when I tell it to build it it says it's not a supported target [07:51] I see https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend [07:51] past time for me to sleep [07:52] I see the Emscripten backend tells us to go to that page [07:54] Added new build option -s WASM_BACKEND=0/1 which controls whether to utilize the upstream LLVM wasm emitting codegen backend. [07:54] Strong implication LLVM vanilla IS the backend [07:55] (looking in https://kripken.github.io/emscripten-site/docs/introducing_emscripten/release_notes.html?highlight=wasm for that target being added) [07:55] Or I should say compile flag [07:55] v1.35.13 added it [07:56] What version LLVM are you using [07:57] *** Vito` has joined #jsmess [08:04] yeah maybe I just need to ditch fastcomp and compile with llvm [08:05] I've never built llvm separately [08:14] It makes it clear you HAVE to [08:14] hrm. not convinced this version is building with webassembly either. might need a special branch or some config option [08:14] The strong implication is LLVM now has webassembly in it [08:15] yeah, I definitely see all the files for it [08:15] but I'm not sure it's building byd efault [08:15] It claims it is [08:16] That's the release notes thing [08:16] -- Constructing LLVMBuild project information [08:16] -- Targeting AArch64 [08:16] -- Targeting AMDGPU [08:16] -- Targeting ARM [08:16] -- Targeting BPF [08:16] -- Targeting Hexagon [08:16] -- Targeting Lanai [08:16] -- Targeting Mips [08:16] -- Targeting MSP430 [08:16] -- Targeting NVPTX [08:16] -- Targeting PowerPC [08:16] -- Targeting Sparc [08:16] -- Targeting SystemZ [08:16] -- Targeting X86 [08:16] -- Targeting XCore [08:16] -- Looking for unwind.h [08:16] I would expect it to list WebAssembly there [08:16] but....maybe that list just isn't comprehensive [08:16] I'll build it and find out [08:17] https://github.com/kripken/emscripten/issues/4013 [08:17] The target `WebAssembly' does not exist. [08:17] It should be one of [08:17] AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;X86;XCore [08:19] https://github.com/WebAssembly/binaryen/pull/112#issuecomment-172246160 [08:49] *** db48x has quit IRC (west.us.hub irc.Prison.NET) [08:49] *** godane has quit IRC (west.us.hub irc.Prison.NET) [08:49] *** mta has quit IRC (west.us.hub irc.Prison.NET) [09:08] ah hah! [09:08] apparently I shouldn't be using -DLLVM_TARGETS_TO_BUILD=WebAssembly I should be using -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly [09:24] hurrah [09:27] I'm tapping my feet angrilly willing my machine to compile the compiler faster [09:27] so I can use the freshly compiled compiler to compile the code I really want to compile [09:31] cant wait [09:32] this better be worth it! [09:32] those benchmarks would be pretty interesting to do [09:35] 95%, come onnnnnnn [09:37] ok, now for the real compile [09:39] *** db48x has joined #jsmess [09:39] *** godane has joined #jsmess [09:39] *** mta has joined #jsmess [09:39] *** irc.Prison.NET sets mode: +o godane [09:42] balls. same error. WebAssembly set as target, but LLVM has not been built with the WebAssembly backend, llc reports: [09:44] oh here we go, apparently here it's not called "WebAssembly" it's called wasm32 or wasm64 [09:45] or maybe I have some path problem [09:46] ah, yeah path problem, on to the next thing [09:51] ../../../../../3rdparty/bgfx/3rdparty/khronos/EGL/eglplatform.h:107:2: error: "Platform not recognized" [09:51] well, that's an unexpected next thing [09:52] the rabbit hole deepens [10:06] ../../../../../3rdparty/asio/include/asio/detail/tss_ptr.hpp:29:3: error: Only Windows and POSIX are supported! [10:06] seems to be some platform defines that normally get set aren't being set here [10:06] I think normally emscripten would set defines for __unix__, posix, etc [10:28] want me to look? [10:37] my build env isn't really easy to share, it's in a vm running on this laptop. I think I'll pick this up tomorrow - there just seems to be some difference in the platform defines when compiling with pure webassembly, rather than via asm.js [10:37] all the 3rd party projects are configured to look for asmjs so there are probably just some extra #ifdef checks [10:38] ok [10:38] but pretty good progress [10:39] once I get full wasm64 builds going we'll do some benchmarks. this'll be big. [16:18] Bloop [17:58] *** Swizzle has joined #jsmess [18:13] * db48x headdesks [18:15] t-mobile's website was built by clowns [18:22] bai: Do you need me to get Alon back in here [19:02] hey, I'm making progress [19:04] apparently I just need to initialize the fs differently [19:04] I guess it's no longer using the global FS [19:24] Yeah, we should shore up Emularity at some point [19:24] BWfla has rebranded and is coming in hot [19:43] SketchCow: in a little bot yeah, once I'm fully awake [19:43] bit* [20:02] rebranded as what? [20:02] *** Swizzle has quit IRC (Read error: Operation timed out) [20:12] bai: how did you load things into the filesystem when using a modularized emulator? [20:14] db48x: umm I believe modularized builds had their own .FS objects rather than a global one, so I had to make that availaable as a var in post.js [20:14] along with some others like ENV [20:15] yes, I can see Module({}).FS, but the module doesn't exist yet [20:15] I'm still in the preInit callback [20:16] basically this._module = Module({preInit:function() { initFS(); }}); [20:16] Module hasn't returned yet, so this._module is undefined, and the FS is still just a local variable further up the callstack, and thus inaccessible [20:18] hmm. [20:21] not sure, been a long time since I poked at that particular part [20:22] bah [20:22] now chrome just crashes every time I run it [20:26] well, it only crashes if I have the debugger open :P [20:27] maybe I'm better off with Firefox, where it merely takes half an hour to step over the Module() function call... [20:27] heh [20:27] fun with browser abuse [20:53] I require comestibles [20:53] hmm [20:54] vietnamese or a burrito? [20:55] both! [20:55] heh [20:56] wow, you really can find anything on google [20:56] i put in vietnamese burrito as a joke query and ended up with https://www.yelp.com/search?find_desc=vietnamese+burrito&find_loc=San+Francisco%2C+CA [20:58] there's a sushiritto too [20:58] there's a sushi burrito place near me, I need to go check it out sometime [21:13] not sure if want [21:15] it's basically an oversized temaki hand roll :D [21:51] *** Swizzle has joined #jsmess [22:09] ok, new idea [22:10] set noInitialRun:true when calling the Module function, then set up the FS, then call .start() later [22:18] bah, that doesn't work either [22:18] I thought that there would be a module.FS, but there's not [22:26] Let me see if Alon is around. [22:35] Pinged on twitter [22:39] *** azakai has joined #jsmess [22:43] DFJustin: https://archive.org/details/SimTown_Win31_Curated [22:43] So, interesting one. I can't get SIMTOWN to start. [22:43] (I realize the _start is set wrong, but I can't do it by hand) [22:43] bai: azakai is here, his time is limited [22:43] Hit him with it [22:45] azakai: Hi [22:46] So, we got it to compile and work, which is great - lots of speedup, and indications the sound is smoother. [22:46] hi SketchCow [22:46] oh good! [22:46] However, there's a sign that bai got it "wrong" in terms of it's compiling at the wrong part of the chain. [22:46] 01:34 <@DFJustin> what it does by default is compile to asm.js and then translate that into wasm in a second step [22:47] 01:34 <@bai> ahh ok [22:47] So that's what it might be doing now [22:47] He's trying to figure out how to make it happen normally, but is hitting some issues. [22:47] 04:17 <@bai> The target `WebAssembly' does not exist. [22:47] 04:17 <@bai> It should be one of [22:47] 04:17 <@bai> AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;X86;XCore [22:47] He's seeing thqt [22:47] the integrateWasmJS() method is what decides whether to run wasm or asm.js. can add debug logging in there. but, best is to just compile and tell it to just use wasm, no fallbacks [22:47] -s 'BINARYEN_METHOD="native-wasm"' [22:48] oh wait [22:48] your question is about compile time, not run time [22:48] Right [22:48] We have it running, after a fashion. [22:48] But it's doing the "wrong thing" [22:48] Also, crashes browsers like candy [22:48] so yes - the correct behavior *is* to compile to asm.js, and then compile that to wasm. [22:48] Like the good old days, 4 years ago! [22:48] So you think what we're doing is right, then [22:49] there is also a wip project to make a path that goes straight to wasm, but it is not ready for use yet, and when it's stable, we'll evaluate it on perf. not clear how that will go [22:49] baicoianu.com/~bai/emularity/pacman.html [22:49] yes, for now, just running binaryen goes through asm.js and that's the right thing to do [22:49] That's the URL to one compiled using methods bai thought were right [22:49] (it uses the asm2wasm tool, which converts asm.js to wasm) [22:50] This crashes a LOT of browsers [22:50] I got it working in chrome canary on windows 81. [22:50] heh [22:50] bai got it working on others. [22:50] well, works here on ff nightly. looks nice and fast [22:51] baicoianu.com/~bai/emularity/jaguar.html [22:51] crashes shouldn't happen of course but not that surprising, given a lot of this is new code in browsers (less in firefox and edge, more in chrome and safari) [22:52] This one is a case of "it's very intense, so it's only a certain speed, so we can see the difference." [22:53] If you run the ASM.JS version of Jaguar, it'll be, for example, 25% on the title screen, 70% on game, but WASM version will be, like, 70% on title and 100% on game [22:53] Obviously this isn't super scientific test harness, but we see a major difference. [22:53] nice [22:54] baicoianu.com/~bai/emularity/sonic.html [22:54] hmm, i get this on that link: https://pageshot.net/qgfra4gn35Khfx8x/baicoianu.com [22:54] the black area looks like it's too small? [22:54] Then press and it'll resize [22:54] We have NO prettiness [22:55] press what? [22:55] Press a key while it has focus, or click on it [22:55] oh i see [22:55] jaguar frame rate looks pretty good [22:55] It's OK. Press F11 to see the internal percentage of native [22:56] 80-90% here [22:57] Right, but when you run the thing, like the game, it might slam up to 100% [22:57] or not [22:57] Anyway, I promise you, notable, notable improvement [22:57] yeah, this looks better than last time i saw it, for sure [22:57] and i'm happy to see that compiling to wasm looks good on both toolchain and browser side (minus some browser crashes) [22:58] heh i just wrote that and sonic crashed my tab [22:58] Right. [22:58] When bai comes back from his meal, I'm sure he'll have some questions. [22:59] are those links good to file bugs with (won't go away soon)? [22:59] Well, I'd rather: [23:00] - He get some hints from you (in case we're missing an obviousness) [23:00] - Then he makes a second link where we leave it frozen while we mess around \ [23:00] Like we did long ago! [23:00] ok cool [23:01] Let me think of anything else [23:01] and any browser crashes are definitely the respective browser's faults, so once there's a frozen link i can file those [23:01] So, are there options he should be using that you think he might not know? [23:01] I mean, obviously the WASM is coming out and it's working [23:01] If you're analyzing that at all [23:01] good thing is the sonic crash looks 100% consistent, so should be easy to fix for them [23:03] main thing is to just use wasm. there are some possible tweaks that might be worth trying, but likely not a big deal. for example, worth building to wasm with -O3 and -Os, the second generates somewhat different code now in wasm, can be much smaller [23:04] I'm racking trying to remember what else we had [23:04] It's a load off to know we're doing it the right way, as it currently is [23:07] btw, compile times should be significantly faster too now, would be interesting to know the difference [23:09] I'm sure he'll be back soon - it'll rocket propel the project with your insight [23:11] What's the timeframe for Webassembly being on by default? [23:18] on by default in emscripten, you mean? [23:18] or in browsers? [23:19] I mean we suddenly see browsers turn it on by defauly [23:19] Luckily, we have a case that it'll "just work" as it goes, as the failover provides [23:19] Is that super up in the air still? [23:21] the hope is to have it in release firefox and chrome around next march. edge and safari have more complicated timetables [23:22] basically, if no showstoppers appear, then the code should be stable by the end of this year. Then it takes a few months to get into release versions [23:23] Sensical [23:29] ah ok I didn't realize the straight to wasm path wasn't usable yet [23:32] *** taisel has joined #jsmess [23:32] Any other questions for him, DFJustin [23:33] (I'm concerned azakai will have to get back to stuff soon) [23:33] yeah, i will need to leave soon [23:34] Previously, we often encountered "hey, use this flag" that would have radical effects [23:34] You already mentioned O3 and Os [23:35] yeah, worth trying -Os as well. but it may run more slowly. code size should be smaller though, more of a difference than in asm.js [23:37] ok, i have to go for now. bye [23:38] See you [23:38] Thanks [23:38] *** azakai has quit IRC (Quit: Ex-Chat) [23:56] *** Swizzle has quit IRC (Read error: Operation timed out)