5.6 TOTAL_MEMORY override

Unity Engine
1

I cannot seem to get the Module override to work for TOTAL_MEMORY.

If we set our Player Settings to use TotalWebGLMemory to something like “400” (which results in 419430400) and then use
Module: { TOTAL_MEMORY: }
in the new 5.6 API, we inevitably get “LinkError: imported Memory with incompatible size” in FireFox or “Uncaught (in promise) LinkError: WebAssembly.instantiate(): memory import 419 is smaller than maximum 9600” in Chrome.

I have read that the memory value is actually ‘baked’ into the binary for WebAssembly, is this correct? If so, how does an override value work?

Thanks.

2

Hate to bump, but am I doing something wrong with the Module override?

3

The TOTAL_MEMORY override via instantiate() is not compatible with wasm at the moment.
Since this functionality has a dependency on emscripten, it is possible we are not going to be able to fix it in 5.6 and 2017.1

Please note that you can still use it with asm.js during development. Is this something you rely on in order to be able to release?

4

Marco,

It is not critical for our release process but it was nice to be able to easily customize the TOTAL_MEMORY value at run-time for various scenarios.

Did I miss this not being available for WebAssembly in the documentation/API post somewhere?

Thanks.

5

No, you did not miss it. WebAssembly support in 5.6 is experimental and this one something we were not aware of until you brought it up. Thanks for that.

We will investigate the problem a bit more, then decide whether to consider it a bug or a feature that is not supported in wasm. If it’s the latter we will document it.

6

Thanks for following up.

Do you foresee WebAssembly being fully supported (i.e, non-experimental) in the Unity 2017 lifecycle?

7

That’s the plan:)

2 Likes
8

Sooo… 2017.2 it is!! :wink:

9

I think the thing to keep in mind is that Unity WebGL has dependencies, for Wasm specifically we depend on emscripten+binayen and the browser implementations, so plans are subject to change :wink: