How long before Unity has a built to WebAssembly option as it looks like the Browsers are on the brink of releasing versions that work with WebAssemblies?
Excellent to hear it’s coming so quickly.
I haven’t seen much from Unity in terms of schedule of it (so no answers there), but they did just recently release a version of Angry Bots ( https://webassembly.github.io/demo/ ) using WebAssembly, so there must be a experimental version of the editor floating around somewhere.
Chrome 51 has a development version of WebAssembly behind a flag. However, that is very different from saying “Chrome 51 will have WebAssembly support” - it will take longer for the feature to be mature enough, and in a final specification for it to be enabled by default without a flag.
But still, this is good news. Firefox has it in nightly builds as well.
Any stats on performance between asm and WebAssembly?
In theory they should be about the same, although the download speed and parsing time should be faster for WebAssembly, right?
No stats yet.
But that theory only holds up for browsers which already had an AOT compilation path for asm.js code (Firefox, Edge), where this will indeed “just” change the distribution format. For Chrome, I expect to see a decent boost in runtime performance, as WebAssembly will run on a new AOT engine, as opposed to a JavaScript JIT.
Are the Multi-Threading, SIMD and Modular/DLL elements of WebAsm still a long way off, or are they progressing well?
Multi-Threading (SharedArrayBuffers) and SIMD.js are under development simultaneous to WebAssembly, and will ship independently of - but also, unfortunately - initially exclusive to WebAssembly. So, in their initial implementations, these features will only be available from JavaScript, and they will come to WebAssembly later, meaning that there will be a window in time where it is possible to user either SIMD & SharedArrayBuffers or WASM, but not both. Hopefully, this window in time will not be too long. For various technical reasons we are choosing to adapt WASM first, and then the other features, once they are supported in WASM.
I’m not sure if the initial WASM spec will support dynamic linking (DLLs), but we have no immediate need for that in Unity either.
Correct me if I’m wrong, but looking at the newest Emscripten incoming builds, it looks like you have to only add some compilation params to support multi-threading on low cpp level. It shouldn’t break anything in theory. So is there any chance that you will update Emscripten engine to the newest version anytime soon, so we can test some MT stuff by ourselves on nightly firefox? I’m not talking about any changes in Unity or il2cpp, just an Emscripten update. I’m already using a lot of cpp code to extend browsers utility. Considering that game coding is rather long process it could be very beneficial to test some incoming features even if we cant really release it.
It is not that simple. Yes, emscripten has an option to support Shared Array Buffers to enable multithreading in JavaScript. We have been experimenting with it, and have been able to test builds using it internally (see here for some results: http://blogs.unity3d.com/2015/12/15/updated-webgl-benchmark-results/).
However, “just turning this on” probably won’t help anyone today. Some issues:
-When we turn this on, we also need to enable threading in our code base, which will make it fail when no threading is available in the browser. So we’d need two builds of Unity WebGL, or one which can dynamically work with or without threading. We kind of have the latter working, but then, on the JavaScript level, we need to patch out all the Shared Array Buffer code at load time, which is not trivial, and increases startup times.
-Shared Array Buffers won’t initially be supported in WebAssembly, so we cannot have both.
-In it’s current implementations, Shared Array Buffers require a separate copy of the code in memory for each thread, which increases memory usage (which is already a problem). So we’d rather want to wait until the functionality becomes available in WebAssembly, where this likely won’t be a problem
-Shared Array Buffers currently allow no way to either pause threads, or to inspect a thread’s stack, which is required for managed Garbage Collection. Without this (or some other GC solution), it will not be possible to run user C# code in threads.
1 Like
Hi Jonas, now that .net 4.6 has is available (in the beta, of course, and not yet completely compatible with Webgl, I know) I think me and many more we are wondering when System.Threading will be available for WebGL, I guess by using Shared Array Buffers below.
Do you have any news about this topic? I cannot wait to have the whole .net 4.6 (more or less…) for WebGL in my hands : )
The current plan is to add threads support as soon as SAB is available in WebAssembly. However, first we are going to look at enabling internal threads, then expose them to the user (via System.Threading) at a later stage.
Great!
about WebAssembly, are you yet waiting until the browsers have it available by default or is any other thing in the middle?
Wihout any pressure and in a wide frame, is there any ETA for Webassembly in first place, and for SBA in WebAssembly in a second one? It would be good to know (month, a year, 2 years…) for long term strategic decisions for us developers. Anyway, thanks for your answers and hard work : )
You can try WebAssembly today in Unity 5.6 Beta, enable it in PlayerSettings=>PublishingSettings and in the browser via flags:
- Firefox Nightly: about:config => javascript.options.wasm
- Chrome Canary: chrome://flags => #enable-webassembly
Though, consider that wasm support is an experimental feature in 5.6 and that in the current Beta there are a couple of bugs that we are still resolving.
5.6 is the next release so you won’t have to wait too long for that (fingers crossed). For SAB is a bit premature but certainly C# Threads will not be available anytime soon. We will try to keep you posted in the coming months.
Thank you Marco, according with WebAssebly Roadmap they’ll probably have the final release for summer (just guessing comparing their previous times). Instead, about SBA I was not able to find anything, when or how they want to add it.
cheers!
Is there anyway to have two builds on a website (regular javascript WebGL, and WebAssembly), and somehow depending on the browser capability, load the correct one?
I believe webassembly can be decoded to asm.js/javascript with javascript (much like Unity will do gzip decompression in javascript if you haven’t set up your server correctly). You shouldn’t need two versions.
1 Like
When Wasm support is enabled, Unity will generate both asm.js and wasm code (as separate files). The user will download and run wasm code if supported, otherwise asm.js
WebAssembly support is in 5.6 beta 11. Feedback is welcome! Please create new forum post threads for specific issues (and/or submit bug reports).
2 Likes
I did a very quick test (I want to stress the quick part!) and the results were:
Chrome (version 58) uses about 150-200mb more memory with webassembly enabled
Firefox (version 52) uses about 100mb-150mb less memory with webassembly enabled
Just a couple other random notes:
-Even though chrome uses more memory, “fps-wise” webassembly does seem quicker
-Caching (from the Asset Store Package) + WebAssembly = crazy fast load times! 
-Stripping physics works!
Unity 5.6 looking to be a game changer for webgl!
1 Like
@kognito1 - what “caching (from the Asset Store Package)” are you referring to?