Add shared worker support

[beaufortfrancois]

Spec PR: gpuweb/gpuweb#4465

---

Requirements for PR author:

• All missing test coverage is tracked with "TODO" or .unimplemented().
• New helpers are /** documented */ and new helper files are found in helper_index.txt.
• Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)

Requirements for reviewer sign-off:

• Tests are properly located in the test tree.
• Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[beaufortfrancois]

@kainino0x The file src/common/runtime/helper/test_worker-worker.ts fails to load as a service worker with the following error:

file_loader.ts:101 Uncaught (in promise) TypeError: import() is disallowed on ServiceWorkerGlobalScope by the HTML specification. See https://github.com/w3c/ServiceWorker/issues/1356.
    at DefaultTestFileLoader.listing (file_loader.ts:101:36)
    at loadTreeForQuery (tree.ts:294:30)
    at DefaultTestFileLoader.loadTree (file_loader.ts:80:24)
    at DefaultTestFileLoader.loadCases (file_loader.ts:94:29)
    at WindowClient.reportTestResults (test_worker-worker.ts:43:45)
    at self.onmessage (test_worker-worker.ts:55:21)

I believe the error comes from the existing code below as dynamic import is not supported in the context of a service worker (unlike shared and dedicated worker):

export class DefaultTestFileLoader extends TestFileLoader {
  async listing(suite: string): Promise<TestSuiteListing> {
    return ((await import(`../../${suite}/listing.js`)) as ListingFile).listing;
  }

  import(path: string): Promise<SpecFile> {
    return import(`../../${path}`);
  }
}

Do you know by any chance how to solve this?

[kainino0x]

Ugh, that's an unfortunate limitation. CTS is heavily built around dynamic imports - it's the only way we can run a subset of tests without loading every JS file in the entire repository.

In order to work around this, proxying to ServiceWorker probably has to look something like, make one ServiceWorker for each .spec.ts that we want to run:

• Generate a JavaScript string that statically imports the .spec.ts file and wraps it in a thing that communicates with the main page to run the test (like DedicatedWorker does now)
• Launch a service worker using that generated JavaScript
• Run whatever tests from that file that we need to run
• Shut down the service worker (I have no idea how this works - can we safely do it on page unload?)

[beaufortfrancois]

Thank you @kainino0x. I have to admit I'm not sure how to apply your suggestions yet.

[beaufortfrancois]

• Launch a service worker using that generated JavaScript

Are you thinking of postMessage() the generated JavaScript and use eval() in service worker?

• Shut down the service worker (I have no idea how this works - can we safely do it on page unload?)

I believe* we can use https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/unregister in cleanup stages.

[kainino0x]

• Launch a service worker using that generated JavaScript

Are you thinking of postMessage() the generated JavaScript and use eval() in service worker?

No, I don't think you can eval a static import. That would be a dynamic import which ServiceWorker is supposed to disallow, presumably for some good reason.

I mean create the worker from a blob from a string: https://web.dev/articles/workers-basics#inline_workers

[beaufortfrancois]

• Launch a service worker using that generated JavaScript

Are you thinking of postMessage() the generated JavaScript and use eval() in service worker?

No, I don't think you can eval a static import. That would be a dynamic import which ServiceWorker is supposed to disallow, presumably for some good reason.

I mean create the worker from a blob from a string: https://web.dev/articles/workers-basics#inline_workers

I wish I could do that but Chrome throws this error when I create a service worker from a blob URL:

Uncaught (in promise) TypeError: Failed to register a ServiceWorker: The URL protocol of the script ('blob:http://localhost:8080/a3ad9992-eb30-487c-818b-c9304f926f14') is not supported.

[beaufortfrancois]

@kainino0x Can you think of other ways to properly test service worker support in the CTS?

[kainino0x]

We could:

• build-time generate one file which statically imports every test file. It would be slow to load though so it wouldn't be suitable for running many tests in separate page loads (as is done in all automated test environments).
• build-time generate a worker wrapper foreach .spec.ts file which statically imports the test file and provides the message interface to run it. This would generate a lot of files in the output and need custom support in the dev-server, but is otherwise much better.

[beaufortfrancois]

build-time generate a worker wrapper foreach .spec.ts file which statically imports the test file and provides the message interface to run it. This would generate a lot of files in the output and need custom support in the dev-server, but is otherwise much better.

I don't know how to apply this suggestion sadly. Could you provide detailed instructions? Or a similar example in the CTS?

[kainino0x]

Sorry, I haven't had time this week because I'll be out next week.
Can we add SharedWorker first and solve ServiceWorker later? Or does SharedWorker have the same constraints?
It would be great to land this PR first and the complicated ServiceWorker one later.
(Though of course I won't be available to review until I'm back. You can get someone else to review.)

I have opened a draft PR which hopefully does the annoying build configuration stuff for you. #3415

[beaufortfrancois]

Can we add SharedWorker first and solve ServiceWorker later? Or does SharedWorker have the same constraints?
It would be great to land this PR first and the complicated ServiceWorker one later.

Got it. I've updated this PR for Shared Worker support only.
I've opened a new one for ServiceWorker at #3419. Thank you @kainino0x

[greggman]

Do we need all the tests to run in a ServiceWorker? I feel like maybe we only need to test that you can create a device and you can do a few basic things (run a render pass, run a compute pass, create a buffer, texture, ....) We have a basic test for regular workers that runs in the main suite when running in the main thread. Maybe we should just add the same for shared and service workers?

src/webgpu/web_platform/worker/worker.spec.ts

[greggman]

lgtm

[beaufortfrancois]

Do we need all the tests to run in a ServiceWorker? I feel like maybe we only need to test that you can create a device and you can do a few basic things (run a render pass, run a compute pass, create a buffer, texture, ....) We have a basic test for regular workers that runs in the main suite when running in the main thread. Maybe we should just add the same for shared and service workers?

Basic tests for shared workers (in this PR) and service workers are available in http://localhost:8080/standalone/?q=webgpu:web_platform,worker,worker:*

[beaufortfrancois]

@greggman Please merge if it looks good to you.