#jsmess 2016-11-01,Tue

↑back Search

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