Deprecate -sUSE_WEBGPU in favor of --use-port=emdawnwebgpu

[kainino0x]

Add a linker warning for using -sUSE_WEBGPU pointing to --use-port=emdawnwebgpu, and update documentation.

Moves the port from contrib.emdawnwebgpu to just emdawnwebgpu since we'll keep maintaining it as we work on Emdawnwebgpu.

Emscripten's implementation of webgpu.h is unmaintained. Dawn now maintains "emdawnwebgpu", a fork of Emscripten's implementation that is up to date, resolving #23432.

We want people to move to emdawnwebgpu. However, the API has changed substantially, so it will take people time to switch over. Plus, there might be new bugs in that implementation. So we need a decently long deprecation period before removing the old implementation.

Closes #23432
Starts fixing #24265

[xpenatan]

Hi, what about firefox or browsers that dont use dawn?

[kainino0x]

emdawnwebgpu is independent of browser (except it supports a few experimental features that are only in Chromium browsers). They're actually just a fork of the bindings currently in Emscripten, the only difference is we're maintaining them in the Dawn repository instead of here.

I should clarify this in the deprecation message and/or in the emdawnwebgpu docs.

[sbc100]

I think we should maybe wait until we have a way for folks to do --use-port=contrib/emdawn.py (or something like that) to use the new version. i.e. lets fix #24260 first?

[ypujante]

I think we should maybe wait until we have a way for folks to do --use-port=contrib/emdawn.py (or something like that) to use the new version. i.e. lets fix #24260 first?

I agree 100%. It would be better to deprecate -sUSE_WEBGPU while offering an alternative that is as painless as possible. And using the --user-port=contrib.emdawn syntax would be the least painless possible...

[kainino0x]

Seems reasonable.

[sbc100]

Can you add a ChangeLog entry?

[kainino0x]

@sbc100 I think this is ready again. I've done a bunch of stuff since your last full review, so could you review again?

[sbc100]

lgtm % comments

[kainino0x]

The dylink variants failed with:
Exception: FROZEN_CACHE is set, but cache file is missing: "sysroot/lib/wasm32-emscripten/pic/lib_emdawnwebgpu-8eb10848-O0.a" (in cache root path "/root/cache")

I've removed those for now but how would I fix that?

[sbc100]

The dylink variants failed with: Exception: FROZEN_CACHE is set, but cache file is missing: "sysroot/lib/wasm32-emscripten/pic/lib_emdawnwebgpu-8eb10848-O0.a" (in cache root path "/root/cache")

I've removed those for now but how would I fix that?

The other test suite runs in mode where it assumes that all libraries have already been built by the build-linux CI phase.

In order to ensure we don't regresss here we use FROZEN_CACHE so that the test suite cannot build anything new itself.

If you want a port to be available in PIC mode here I think you would need to add it to MINIMAL_PIC_TASKS in ./embuilder.py.

[sbc100]

Also the name of the library looks a little odd. Libraries don't normally have an underscore after the lib part. e.g we call them libc and libz and not lib_c and lib_z

[ypujante]

Also the name of the library looks a little odd. Libraries don't normally have an underscore after the lib part. e.g we call them libc and libz and not lib_c and lib_z

To play devil's advocate here, I would argue that lib_emdawnwebgpu-8eb10848-O0.a is far more readable than libemdawnwebgpu-8eb10848-O0.a... It only looks "odd" because you are used to having short library names and you have seen this names for a long time...

[sbc100]

Also the name of the library looks a little odd. Libraries don't normally have an underscore after the lib part. e.g we call them libc and libz and not lib_c and lib_z

To play devil's advocate here, I would argue that lib_emdawnwebgpu-8eb10848-O0.a is far more readable than libemdawnwebgpu-8eb10848-O0.a... It only looks "odd" because you are used to having short library names and you have seen this names for a long time...

It looks odd because it doesn't follow the standard naming convention.

You could argue the convention is wrong, or needs updating, but I don't think this is the right forum for that.

[kainino0x]

If you want a port to be available in PIC mode here I think you would need to add it to MINIMAL_PIC_TASKS in ./embuilder.py.

Thanks for the tip! It's probably not necessary, I think I'd rather not add a port to that list.

[kainino0x]

Also the name of the library looks a little odd. Libraries don't normally have an underscore after the lib part. e.g we call them libc and libz and not lib_c and lib_z

This name comes from the upstream port, so I'll take note and consider changing it at some point while I'm doing something else (doesn't seem important enough to make a whole CL to change).

[sbc100]

If you want a port to be available in PIC mode here I think you would need to add it to MINIMAL_PIC_TASKS in ./embuilder.py.

Thanks for the tip! It's probably not necessary, I think I'd rather not add a port to that list.

The point of that list is purely to enable this kind of testing. giflib (a port) is already in the list.

Users won't be using that list. And also ./embuilder ALL will already include your new port so its already in embuillder in that sense.

[sbc100]

Also the name of the library looks a little odd. Libraries don't normally have an underscore after the lib part. e.g we call them libc and libz and not lib_c and lib_z

This name comes from the upstream port, so I'll take note and consider changing it at some point while I'm doing something else (doesn't seem important enough to make a whole CL to change).

Indeed, not a blocker.

[kainino0x]

The point of that list is purely to enable this kind of testing. giflib (a port) is already in the list.

Users won't be using that list. And also ./embuilder ALL will already include your new port so its already in embuillder in that sense.

Ah, then it wouldn't be so bad. Though thinking about it, it looks like that's a list of filenames, and since we have a filename that changes constantly it would introduce friction to the roll (unless maybe we detect that we're being downloaded in "remote port" configuration and remove the hash). It's fine, we want the more rigorous testing in Dawn anyway so we catch issues before landing them.