| commit | fe0be9e4b4f9b8ebe4c965f79b2ecf7deacaf546 | [log] [tgz] |
|---|---|---|
| author | James Price <jrprice@google.com> | Fri Apr 18 07:05:14 2025 -0700 |
| committer | Dawn LUCI CQ <dawn-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Apr 18 07:05:14 2025 -0700 |
| tree | 27e3b8f4448e986b07dd15e08a93d248d33a5e33 | |
| parent | a3a071b67f6876838e22727f6fa1dbc35e78bbad [diff] |
Revert "[ios blink] Implement futures using WaitListEvent" This reverts commit abc42736ef28ed8fcc11e66814907febff6ee930. Reason for revert: Breaks roll into Skia with both build and UBSan errors: https://skia-review.googlesource.com/c/skia/+/982121 Bug: 407801085 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> TBR=cwallez@chromium.org,kainino@chromium.org,dawn-scoped@luci-project-accounts.iam.gserviceaccount.com,sunnyps@chromium.org,lokokung@google.com No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 407801085 Change-Id: I5bf3fdd87bef0d30976a034cfd1fa3101c7d3154 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/237835 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: James Price <jrprice@google.com> Auto-Submit: James Price <jrprice@google.com> Commit-Queue: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
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.