[ios blink] Implement futures using WaitListEvent

Currently, most futures are implemented using SystemEvent. This includes
already completed and non-progressing events. This is problematic on iOS
where BrowserEngineKit child processes are not allowed to open fds, mach
ports, etc.

This CL introduces WaitListEvent which mimics the base::WaitableEvent
implementation in Chromium for POSIX platforms. The event internally
maintains a list of waiters corresponding to a WaitAny call. In WaitAny,
we create a SyncWaiter that's signaled using a condition variable. The
waiter is added to each event that the WaitAny is waiting on. The events
also have a mutex to allow multiple threads to wait on them. We acquire
the event locks in a globally consistent order (sorted by address) to
prevent lock order inversion. WaitListEvents can also be waited on
asynchronously by returning a SystemEventReceiver which allows mixing
waits on SystemEvents and WaitListEvents.

In addition, this CL changes how already signaled and non-progressing
TrackedEvents are represented. Already signaled events are backed by
WaitListEvents and non-progressing events become a flag on TrackedEvent.

The code in EventManager is also cleaned up to aid readability and fix
an edge case of waiting on multiple queues with zero timeout - we could
end up ticking the same queue multiple times causing a subtle race
between MapAsync and OnSubmittedWorkDone futures completion.

Bug: 407801085
Change-Id: I1c5deb8097339be5beb5e9021d753998a074bea3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/234277
Reviewed-by: Loko Kung <lokokung@google.com>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
18 files changed
tree: 660d78fbc370636703113b8efed7ea09bbd097ae
  1. .github/
  2. .vscode/
  3. build_overrides/
  4. docs/
  5. generator/
  6. include/
  7. infra/
  8. scripts/
  9. src/
  10. test/
  11. third_party/
  12. tools/
  13. webgpu-cts/
  14. .bazelrc
  15. .clang-format
  16. .clang-tidy
  17. .git-blame-ignore-revs
  18. .gitattributes
  19. .gitignore
  20. .gitmodules
  21. .gn
  22. .vpython3
  23. AUTHORS
  24. BUILD.bazel
  25. BUILD.gn
  26. CMakeLists.txt
  27. CMakeSettings.json
  28. CODE_OF_CONDUCT.md
  29. codereview.settings
  30. CONTRIBUTING.md
  31. CPPLINT.cfg
  32. DEPS
  33. DIR_METADATA
  34. go.mod
  35. go.sum
  36. go_presubmit_support.py
  37. LICENSE
  38. OWNERS
  39. PRESUBMIT.py
  40. README.chromium
  41. README.md
  42. WATCHLISTS
  43. WORKSPACE.bazel
README.md

Build Status Matrix Space

Dawn, a WebGPU implementation

Dawn is an open-source and cross-platform implementation of the WebGPU standard. More precisely it implements webgpu.h that is a one-to-one mapping with the WebGPU IDL. Dawn is meant to be integrated as part of a larger system and is the underlying implementation of WebGPU in Chromium.

Dawn provides several WebGPU building blocks:

  • WebGPU C/C++ headers that applications and other building blocks use.
    • The webgpu.h version that Dawn implements.
    • A C++ wrapper for the webgpu.h.
  • A “native” implementation of WebGPU using platforms' GPU APIs: D3D12, Metal, Vulkan and OpenGL. See per API support for more details.
  • A client-server implementation of WebGPU for applications that are in a sandbox without access to native drivers
  • Tint is a compiler for the WebGPU Shader Language (WGSL) that can be used in standalone to convert shaders from and to WGSL.

Helpful links:

Documentation table of content

Developer documentation:

User documentation: (TODO, figure out what overlaps with the webgpu.h docs)

License

BSD 3-Clause License, please see LICENSE.

Disclaimer

This is not an officially supported Google product.