Skip to content

WebGL bindings: Fix shifts for >=2GB heaps #17832

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

Closed
wants to merge 3 commits into from
Closed

WebGL bindings: Fix shifts for >=2GB heaps #17832

wants to merge 3 commits into from

Conversation

kripken
Copy link
Member

@kripken kripken commented Sep 12, 2022

Fixes #17539

@kripken kripken requested review from juj and sbc100 September 12, 2022 19:35
@kripken
Copy link
Member Author

kripken commented Sep 12, 2022

Testing this would require allocating over 2GB of memory, which is tricky on CI... we only have a few stress tests for that. Not sure if it's worth adding something for an issue like this.

@kripken
Copy link
Member Author

kripken commented Sep 12, 2022

Added a disabled test. The test can only pass in Chrome Canary which has fixed some issues in this area recently.

@juj
Copy link
Collaborator

juj commented Sep 13, 2022

I still think this would be best to be fixed with #15433 , so it would work in general for all JS libraries.

Although there was some hard pushback in the comments back then, which made me a bit disheartened to press on that PR, and other more urgent work came in the way. The approach in #15433 does still feel the best way forward to me though, and I'd love to take that in, since it would enable Unity to target 2GB+4GB+Wasm64 in a way that doesn't require teaching Unity JS game devs two different ways to manage pointers in JS land.

Unfortunately I'll be on PTO after this week, so will be a short while until I can focus on #15433.

One way might be to land this interim, and then later replace it with #15433 if we agree with that is the direction to go?

LGTM on the code.

#else
return ptr >> shifts;
#endif
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I think this would be nice to do compile-time, #15433 can help with that. This way there wouldn't be a WebGL-specific function emitted to grow code size. But lgtm for now.

@@ -1951,6 +1951,13 @@ def test_sdl_glshader2(self):
def test_gl_glteximage(self):
self.btest('gl_teximage.c', '1', args=['-lGL', '-lSDL'])

@unittest.skip("can only work in chrome canary atm (Sep 2022)")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use @disabled normally, which I think is just a synonym

@kripken
Copy link
Member Author

kripken commented Sep 14, 2022

I see @juj, thanks.

Sounds good to me to wait for #15433 - this PR is not urgent, as testing this needs to wait on a Chrome update anyhow, so I wasn't planning to land it immediately. Let's wait for your PR, when you have time for it.

(Please don't be discouraged by some of the comments in #15433, I think that PR is the right way forward, and recent work has been going that way anyhow. I am sure we can convince everyone of that, as necessary.)

@kripken
Copy link
Member Author

kripken commented Jan 22, 2025

This has been fixed meanwhile - these GL methods use toTypedArrayIndex() which does >>> for wasm32, which handles >=2GB heaps properly (and it also supports wasm64).

@kripken kripken closed this Jan 22, 2025
@kripken kripken deleted the gl.shift.4gb branch January 22, 2025 22:40
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

Successfully merging this pull request may close these issues.

WebGL2RenderingContext cannot handle large ArrayBuffer sizes.
3 participants