- Note that by default these are already errors, not warnings.
Change-Id: I46afa6e54e7915ba54aa6990cd641288609108c1
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128101
Reviewed-by: Shrek Shao <shrekshao@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
WebGPU clears [pending_map] before resolving or rejecting promises,
which means that the callback for .then or .catch is allowed to unmap,
remap, or do anything with the buffer assuming previous mapping
operations are entirely done the buffer.
Mimic this in Dawn by finishing all operations related to mapping
before calling callbacks they might trigger.
bug: dawn:1619
Change-Id: I9e5b82789a68f28a496a54c31bf9fe0ffde23ccf
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/116220
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Takahiro <hogehoge@gachapin.jp>
Reviewed-by: Austin Eng <enga@chromium.org>
WebGPU specification described that Buffer mapState must be
"unmapped" after destroyed because Destroy() must internally
call Unmap().
But in the current Wire implementation the mapState won't be
"unmapped". The root issue is that Destroy() doesn't update
mMapState in Wire.
This commit fixes the problem by updating mMapState in
Destroy() in Wire.
bug: dawn:1634
Change-Id: I7398510f83ebacfbc6bb33fcc070c2eab10b9c24
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/116820
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Takahiro <hogehoge@gachapin.jp>
Currently Buffer doesn't distinguish Map request callback fired
by device. For example if buffer.MapAsync(), buffer.Unmap(),
and buffer.MapAsync() are called in this order before the first
MapAsync() finishes the MapAsync callback provided by application
for the first MapAsync() is fired when Map request callback
for the first MapAsync() is fired by device although the first
MapAsync callback provided by application shouldn't be fired
because it is already unmapped.
This commit resolves this problem by assigning MapRequestId to
Map request and distinguishing the callback fired by device.
Change-Id: Ic29b02d27cffb254616dc7b48a60151c39f667e2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/113222
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Kokoro: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
This patch updates the validations about CreateBuffer() with dawn_wire
to match the latest WebGPU SPEC.
According to the SPEC, the validations in CreateBuffer() should be
executed in the below order:
1. If mappedAtCreation == true, return nullptr and a RangeError will be
generated in Chromium.
2. Validate BufferDescriptor and check if there is OOM at device timeline
3. Check if there is OOM at content timeline
Bug: dawn:1586
Change-Id: I97ff5f82a42208442ddf6e46e66381c3b3680450
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/109040
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Calling UnmapInternal would set the state to Unmapped, allowing the
buffer to be mapped again even though it is destroyed.
Bug: chromium:1388920
Change-Id: Ibb4da332bafd44a0d4900c8ea5bfbd674bbc35e0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/111121
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
WebGPU specification was updated that GPUBuffer.unmap()
shouldn't validate buffer state.
https://github.com/gpuweb/gpuweb/pull/3368
This commit reflects it to the Dawn implementation.
Bug: dawn:1528
Change-Id: Ie66f68214bd6896a4d674ed00addc3ffb539c235
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/106264
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Takahiro <hogehoge@gachapin.jp>
This happens when trying to allocate the backing storage for an error
buffer when the allocation would cause an OOM.
new (std::nothrow) doesn't work on Mac ARM64. The code in libc++ that's
compiled into dawn_unittests seems correct, but macOS's libunwind
returns "end of stack" when trying to unwind.
Bug: dawn:1506
Change-Id: Ibc5d7251ea7a411b0e3cc91646a059270d965a90
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/98122
Reviewed-by: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Changes dawn::native procs to correctly convert C++ enum and bitmask
returns values.
Bug: dawn:1451
Change-Id: I39a8d218f76e25b178a83eeb99d653222d39d040
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/92440
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This CL updates the clang format files to have a single shared format
between Dawn and Tint. The major changes are tabs are 4 spaces, lines
are 100 columns and namespaces are not indented.
Bug: dawn:1339
Change-Id: I4208742c95643998d9fd14e77a9cc558071ded39
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/87603
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Bug exposed by emscripten webgpu binding issue.
It seems the spec updated after the last code updates. Update the
validation part a bit (introduce rangeSize).
Bug: dawn:1400
Change-Id: I0ddefd5c1a0976cc34102a44514bccd70f7a1ac0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/88080
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Shrek Shao <shrekshao@google.com>
This CL fixes up various build/namespaces lint errors and enables
the lint check.
Bug: dawn:1339
Change-Id: Ib2edd0019cb010e2c6226abce6cfee50a0b4b763
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/87482
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
This CL adds the needed headers to pass the include what you use lint
check.
Bug: dawn:1339
Change-Id: Ib8df68e51b2c3711169b400e84768d4804568580
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/86941
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
This Cl moves the cpp includes to above the project includes fixing up
the build/include_order issues and enabling the lint check.
A couple includes are marked as NOLINT as the c header has to come after
the project header due to setting defines.
Bug: dawn:1339
Change-Id: Ia47499c94fff99106397b83f6c5c7fe100c44a0e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/86513
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
