Skip to content

Conversation

@pkomon
Copy link
Contributor

@pkomon pkomon commented Jul 31, 2024

Fixes #22300.

@kripken kripken requested a review from kainino0x July 31, 2024 23:03
@gozetor
Copy link

gozetor commented Aug 11, 2024

Hello!
Can this PR be merged? It really blocks our WebGPU adoption.
Thank you!

Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

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

This looks trivial enough that I think I can review it myself. Looks correct!

@kripken kripken merged commit 88c23a7 into emscripten-core:main Aug 12, 2024
@sbc100
Copy link
Collaborator

sbc100 commented Aug 12, 2024

@kainino0x would it be reasonable to have a test for this?

@kainino0x
Copy link
Collaborator

In principle it would be good to do that (not just for these tables but also for the codegen-time tables), however our focus is currently on Dawn's fork of these bindings, and we've already obsoleted this problem there by autogenerating all of these tables so they can't get out of sync.

On the Emscripten side, things should hopefully not break too quickly since we're not actively developing Emscripten's version right now. When we unfork and port the work from Dawn back into Emscripten, we'll definitely try to avoid reintroducing the manually-maintained tables (though I don't know precisely how we'll do it yet).

'mapped': 2,
'unmapped': 1,
'pending': 2,
'mapped': 3,
Copy link
Collaborator

Choose a reason for hiding this comment

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

It looks like Int_CompilationMessageType might also be off by one:

system/include/webgpu/webgpu.h:    WGPUCompilationMessageType_Error = 0x00000001,
system/include/webgpu/webgpu.h:    WGPUCompilationMessageType_Warning = 0x00000002,
system/include/webgpu/webgpu.h:    WGPUCompilationMessageType_Info = 0x00000003,

How did this stuff ever work? Or is it just not tested?

Copy link
Collaborator

Choose a reason for hiding this comment

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

A lot of these are pretty niche and most applications don't use them. It probably broke at some point when we updated the header (which shifted the numbers) but no one was using it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WebGPU: Wrong values returned from wgpuBufferGetMapState

5 participants