Skip to content

Conversation

@Repiteo
Copy link
Contributor

@Repiteo Repiteo commented Feb 3, 2025

This PR makes the necessary accomodations to allow 64-bit emscription builds to happen:

  • Add wasm64 architecture to support MEMORY64=11. The "hybrid" implementation is outside the scope of this PR.
  • Bump minimum emscription to 3.1.72, where MEMORY64 is no longer experimental2.
  • Explicitly pass architectures to web GHA, chosen arbitrarily (threads = 64-bit, no threads = 32-bit).

Footnotes

  1. https://emscripten.org/docs/tools_reference/settings_reference.html#memory64

  2. https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3172---111924

- Bump minimum emscription to `3.1.72`, where `MEMORY64` is no longer experimental
@Repiteo Repiteo added this to the 4.5 milestone Feb 3, 2025
@Repiteo Repiteo requested a review from a team February 3, 2025 19:57
@Repiteo Repiteo requested a review from a team as a code owner February 3, 2025 19:57
@Calinou
Copy link
Member

Calinou commented Feb 3, 2025

What does browser support look like for wasm64 right now?

If support isn't universal yet, I'm wondering if it's possible to distribute WASM32 + WASM64 alongside where the JavaScript selects the correct file to download according to the browser's capabilities.

@adamscott
Copy link
Member

What does browser support look like for wasm64 right now?

Here's what emscripten's change log say:

3.1.72 - 11/19/24

  • The MEMORY64 setting is no longer experimental. At time of writing all browsers still require a flag to run the resulting binaries but that should change in the coming months since the proposal is now at stage 4. (Fix build with Android NDK r18 #22864)

If support isn't universal yet, I'm wondering if it's possible to distribute WASM32 + WASM64 alongside where the JavaScript selects the correct file to download according to the browser's capabilities.

It could be interesting for performance oriented apps, but for most of the uses, this is overkill, as usually, the target is to have the smallest payload possible to load faster.

@dsnopek
Copy link
Contributor

dsnopek commented Feb 3, 2025

I haven't tested, but I highly suspect that our WebXR code will break with WASM64, due to all the messy pointer math that's happening to send data between the C++ and JavaScript sides. However, if there are issues, it should be pretty easy to fix.

@Repiteo Repiteo modified the milestones: 4.5, 4.x Sep 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants