| commit | a218ceac197ff55273d80942e114eea9d6dcc90c | [log] [tgz] |
|---|---|---|
| author | Sunny Sachanandani <sunnyps@chromium.org> | Fri Apr 18 14:28:19 2025 -0700 |
| committer | Dawn LUCI CQ <dawn-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Apr 18 14:28:19 2025 -0700 |
| tree | 4f70c85e36654a61690a321ed4273a2d48e2fd9c | |
| parent | 293da05b1e523cd9a2cc931db22934a94c42735d [diff] |
Reland "[ios blink] Implement futures using WaitListEvent" This is a reland of commit abc42736ef28ed8fcc11e66814907febff6ee930 The only change over the original is the correct initialization of the `mSignaled` atomic_bool in WaitListEvent. Original change's description: > [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> Bug: 407801085 Change-Id: I254398256851f2310ddfe906c79d389dae1d3d77 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/237719 Commit-Queue: Corentin Wallez <cwallez@chromium.org> Reviewed-by: Kai Ninomiya <kainino@chromium.org> Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Kai Ninomiya <kainino@chromium.org> Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
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.h version that Dawn implements.webgpu.h.Helpful links:
Developer documentation:
User documentation: (TODO, figure out what overlaps with the webgpu.h docs)
BSD 3-Clause License, please see LICENSE.
This is not an officially supported Google product.