Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set TOTAL_MEMORY for WASM version #92

Open
nicokruger opened this issue Mar 22, 2018 · 10 comments
Open

Set TOTAL_MEMORY for WASM version #92

nicokruger opened this issue Mar 22, 2018 · 10 comments

Comments

@nicokruger
Copy link

Hi there,

Setting TOTAL_MEMORY as per the WASM example doesn't seem to work, I still get a 16mb total heap for Box2D. Not sure if I did something wrong, but I added the:


<script>
var Module = { TOTAL_MEMORY: xxxx }
</script>

And it doesn't seem to make a difference.

I then tried to set the max memory like this:

Box2D({
   TOTAL_MEMORY:xxxxx}
).then( () => { } )

But then I get the error:

WebAssembly Instantiation: memory import 43 has a larger maximum size 4096 than the module's declared maximum 256

Which makes me think somewhere in the webassembly the size is also configured - as I'm trying to set it to 256mb which is also 16 times bigger than 16mb.

Any ideas?

@kripken
Copy link
Owner

kripken commented Mar 22, 2018

We compile with MODULARIZE here, so it doesn't see the Module global object, you need to pass it in as you wrote later.

But in wasm (unlike asm.js) the module must declare a minimum and maximum size. See the WASM_MEM_MAX option in emscripten, we could set that to 2GB to allow setting the memory size the way you suggest.

@nicokruger
Copy link
Author

So I'm taking it then that is a compile-time setting? Ie. a setting that will have to be set when you guys convert box2d to the WASM module and not something I can set now using the already built WASM library?

Sorry if I'm asking stupid questions but I couldnt find anything by googling for WASM_MEM_MAX.

@kripken
Copy link
Owner

kripken commented Mar 22, 2018

Yeah, sorry for not being more clear. That's an emscripten compile-time option.

Although, thinking some more, we should probably just enable memory growth for the wasm build, since growth is fast there (unlike asm.js) and it solves not just this problem but also lets you not worry much about the initial memory size.

@nicokruger
Copy link
Author

Thanks for the clarification. Any ideas on when you guys will be able to enable the memory growth setting? Is there any way I can help? I'm really keen on trying the WASM version as I do see quite a speed improvement :). It's just the memory size limit holding us back from moving over at the moment.

But thanks for the effort for the box2d port !

@kripken
Copy link
Owner

kripken commented Mar 23, 2018

Well, it should be as easy as adding the flag ( -s ALLOW_MEMORY_GROWTH=1 alongside WASM=1) and building (emmake make), but I tried it now and get

./box2d_glue.cpp:857:74: error: unknown type name 'b2MotorJoint'
void EMSCRIPTEN_KEEPALIVE emscripten_bind_b2MotorJoint_SetLinearOffset_1(b2MotorJoint* self, b2Vec2* arg0) {

Looking in the makefile, b2MotorJoint is indeed handled in a special way. May depend on the Box2D version, and we sort of support 2 right now.

If you have time to figure out what's going on with the 2 versions (do we need both?) and what's going on with b2MotorJoint that could help move things along.

@nicokruger
Copy link
Author

I'll see if I can get a basic build working on my side, and no I don't think its really necessary to support both (in my opinion), I would say lets just try to get the 2.3.1 version working? Not sure what the major differences are between them.

@kripken
Copy link
Owner

kripken commented Mar 25, 2018

Yeah, my intuition is also that we just need the latest. Might be worth looking through the history and issue tracker here, might be we support both for a good reason I can't remember.

@nicokruger
Copy link
Author

nicokruger commented May 29, 2018

Hi @kripken ,

I'll have some time this week to look at this.

I'm trying to compile using emmake, but get the following error:

LLVM version appears incorrect (seeing "9.1", expected "6.0")

I'm assuming I'm using a newer version of emscripten or something? Should I try downgrade my emscripten or should I rather try and get it working with my version?

Full error trace:

/usr/local/Cellar/emscripten/1.38.3/libexec/em++ -O3 -IBox2D_v2.3.1 Box2D_v2.3.1/Box2D/Dynamics/Joints/b2MotorJoint.cpp -o Box2D_v2.3.1/Box2D/Dynamics/Joints/b2MotorJoint.bc
WARNING:root:LLVM version appears incorrect (seeing "9.1", expected "6.0")
CRITICAL:root:fastcomp in use, but LLVM has not been built with the JavaScript backend as a target, llc reports:
===========================================================================
(no targets could be identified: [Errno 2] No such file or directory)
===========================================================================
CRITICAL:root:you can fall back to the older (pre-fastcomp) compiler core, although that is not recommended, see http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html
INFO:root:(Emscripten: Running sanity checks)
CRITICAL:root:Cannot find /usr/bin/llvm-link, check the paths in ~/.emscripten
make: *** [Box2D_v2.3.1/Box2D/Dynamics/Joints/b2MotorJoint.bc] Error 1

@kripken
Copy link
Owner

kripken commented May 29, 2018

Hmm, there is no LLVM 9.1 (last release is 6.0, svn is at 7.0) so something is going very wrong there when it tries to run clang to check the version.

Anyhow, if you get the emsdk, it should provide a proper build of LLVM for you. If not, maybe you're hitting an unknown bug?

@nicokruger
Copy link
Author

nicokruger commented May 29, 2018

Thanks!

Using emsdk I can now at least start the build 👍

I get errors like the following now:

/xxx/emscripten/1.38.3/third_party/closure-compiler/node-externs/domain.js:68: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Bad-Type-Annotation for more information.
 * @return {function(...[*])}

but at least the toolchain seems to be working now.

I guess thats what happens if you just mindlessly install emscripten using something like brew without really knowing what you're doing :)

I think I'll be able to get somewhere from here, so thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants