[wasm64] Fix window system/graphics JS libraries #20276

jspanchu · 2023-09-16T18:51:54Z

Closes #20274

These changes got some amount of webgl, webgpu and event processing for wasm64 working in Chromium Version 119.0.6011.0 (Developer Build) custom (64-bit). Had to enable experimental Webassembly flags.

jspanchu · 2023-09-16T18:55:36Z

@sbc100 not sure if you've any open PR that includes these changes. I found these commits fix VTK rendering for wasm64. Please let me know if any of these changes already exist in an open PR.

sbc100

Thanks for working on this!

lgtm % a couple of comments.

Normally I would want to see some new tests passing under wasm64 but maybe thats not currently an easy option?

src/library_html5.js

jspanchu · 2023-09-18T20:59:09Z

I think a new workflow is needed for wasm64 on browsers? It appears that the workflows which run wasm64 tests only install node canary.

sbc100 · 2023-09-18T21:11:22Z

I think a new workflow is needed for wasm64 on browsers? It appears that the workflows which run wasm64 tests only install node canary.

We have the @also_with_wasm64 in test_browser.py. Perhaps add that decorator to one of the existing graphics tests?

jspanchu · 2023-09-18T21:14:00Z

Thanks! I think the SDL2 tests will fail because the port will not compile. Let me try that for unit tests which use low level html5 api.

sbc100 · 2023-09-18T21:16:07Z

Thanks! I think the SDL2 tests will fail because the port will not compile. Let me try that for unit tests which use low level html5 api.

sdl1 tests should maybe work too?

jspanchu · 2023-09-19T03:25:12Z

@sbc100 I'm making progress with wasm64 tests inside test_browser.py. So far the sdl1 and egl tests are looking good. Turns out I also have to modify library_webgl.js to use * where necessary. Working on it. Is there any extra step to enable the wasm64 browser tests in the GitHub workflow?

sbc100 · 2023-09-19T03:29:00Z

@sbc100 I'm making progress with wasm64 tests inside test_browser.py. So far the sdl1 and egl tests are looking good. Turns out I also have to modify library_webgl.js to use * where necessary. Working on it. Is there any extra step to enable the wasm64 browser tests in the GitHub workflow?

Just to add @also_with_wasm64 to a test or two. Just adding one or two would be enough to land this change I think

jspanchu · 2023-09-19T13:52:28Z

@sbc100 I've enabled wasm64 for a few simple tests. Just checked the "Run tests" section in circleci and it looks like both firefox and chrome ran the newly enabled wasm64 tests successfully.

There is more work to do for webgl and proxied contexts. We don't use proxied contexts in our library, but I'd love to explore that. I think it's a good idea to make those changes in follow up PRs.

src/library_html5.js

sbc100

lgtm with the final comment fixed.

The webidl `long` type is defined to be a 32-bit type: https://webidl.spec.whatwg.org/#idl-long https://webidl.spec.whatwg.org/#idl-unsigned-long Using `long` on the native side works find for wasm32 but breaks under wasm64 where `long` is 64-bit. Using `int` instead means the type is the same under wasm32 and wasm64 which more accurately represents the html5/webidl type. See emscripten-core#20276

sbc100 · 2023-09-19T16:02:32Z

Actually, I think we should fix the types using html5.h.. which should allow you revert certain parts of this change: #20290

jspanchu · 2023-09-19T16:04:23Z

That is much better imo. I'll revert those after that is merged.

The webidl `long` type is defined to be a 32-bit type: https://webidl.spec.whatwg.org/#idl-long https://webidl.spec.whatwg.org/#idl-unsigned-long Using `long` on the native side works find for wasm32 but breaks under wasm64 where `long` is 64-bit. Using `int` instead means the type is the same under wasm32 and wasm64 which more accurately represents the html5/webidl type. See emscripten-core#20276

The webidl `long` type is defined to be a 32-bit type: https://webidl.spec.whatwg.org/#idl-long https://webidl.spec.whatwg.org/#idl-unsigned-long Using `long` on the native side works find for wasm32 but breaks under wasm64 where `long` is 64-bit. Using `int` instead means the type is the same under wasm32 and wasm64 which more accurately represents the html5/webidl type. See #20276

src/library_webgpu.js

src/parseTools.js

src/library_webgpu.js

jspanchu · 2023-09-19T23:50:36Z

Upon rebasing against main, my canvas was flipped and mouse/keyboard weren't being recognized in browser with wasm64. Seems like the contents of the structs in generated_struct_info64.json were copied verbatim from generated_struct_info32.json? After regenerating with --wasm64, it works as expected!

sbc100

Thanks! Almost ready to land.

test/test_browser.py

src/generated_struct_info64.json

sbc100 · 2023-09-20T21:42:08Z

I just fixed the code size failures on main.. can you try rebasing/merging one more time?

…it stride

…in_loop_arg

…meout_loop

…imer

- set the value of `config` as a pointer type in eglChooseConfig.

- update dynamic call signatures to `p` where the parameter type is a pointer. - proxied events needs additional work.

jspanchu changed the title ~~[wasm64] Fix window system/graphics code~~ [wasm64] Fix window system/graphics JS libraries Sep 16, 2023

sbc100 approved these changes Sep 18, 2023

View reviewed changes

src/library_html5.js Outdated Show resolved Hide resolved

src/library_html5.js Outdated Show resolved Hide resolved

sbc100 mentioned this pull request Sep 18, 2023

emscripten crashes randomly #20277

Open

jspanchu mentioned this pull request Sep 18, 2023

SDL2 fails to create opengl window in wasm64 builds #20273

Open

jspanchu force-pushed the fix_sigs_for_wasm64 branch from 4c7f0be to 407e28c Compare September 18, 2023 20:57

jspanchu force-pushed the fix_sigs_for_wasm64 branch 3 times, most recently from c902bf9 to 8e65611 Compare September 19, 2023 12:23