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

Expand some bitmask enums to 64-bits? #247

Closed
1 task
kainino0x opened this issue Nov 21, 2023 · 3 comments · Fixed by #336
Closed
1 task

Expand some bitmask enums to 64-bits? #247

kainino0x opened this issue Nov 21, 2023 · 3 comments · Fixed by #336
Assignees
Labels
extensibility Adding features without breaking API changes has resolution Issue is resolved, just needs to be done

Comments

@kainino0x
Copy link
Collaborator

kainino0x commented Nov 21, 2023

Vulkan has had several bitmask enums that they had to expand from 32 bits to 64 bits (by adding version "2" of a bunch of things throughout the API like VkPipelineStageFlags2, vkCmdWriteTimestamp2). We should probably do this early to avoid that kind of thing.

We have 5 of these (in order of likelihood to need more than 32 31? bits ever):
WGPUBufferUsage
WGPUTextureUsage
WGPUMapMode
WGPUShaderStage (almost certainly not)
WGPUColorWriteMask (definitely not)

Note that with #159 we're planning to remove the Flags typedefs, so all we would do here is change these enums' Force32 value to Force64.


  • Probably document that native-only bits should be allocated in the 10-11 MSBs (because JS can only use 53 bits anyway). (Note: maybe don't use 2**63 if we use C enums if they're not guaranteed to be unsigned?)
@kainino0x kainino0x added !discuss Needs discussion (at meeting or online) extensibility Adding features without breaking API changes labels Nov 21, 2023
@kainino0x
Copy link
Collaborator Author

Meeting:

  • Yes let's do this, let's just change all bitmask enums to 64-bits for consistency

@kainino0x kainino0x added has resolution Issue is resolved, just needs to be done and removed !discuss Needs discussion (at meeting or online) labels Dec 7, 2023
@kainino0x
Copy link
Collaborator Author

FWIW @toji pointed out to me today that the Web API will be limited to just 53 bits because everything passes through double. Still better than 32, though. Maybe if we have any native-only ones we can put them in the top 11 bits.

@toji
Copy link

toji commented Jan 3, 2024

And for the record, if we were ever backed into a corner where we absolutely HAD to have more than 53 bits in the WebAPI (which I see as somewhat unlikely?) , the most practical route would likely be to start passing them as arrays of JS enums:

bufferUsage2: ['vertex', 'storage', 'copy-src', 'new-fancy-flag']

Not the worst thing in the world, but let's hope it never comes to that.

@kainino0x kainino0x changed the title Expand some enums to 64-bits? Expand some bitmask enums to 64-bits? Feb 15, 2024
@kainino0x kainino0x self-assigned this Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extensibility Adding features without breaking API changes has resolution Issue is resolved, just needs to be done
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants