This CL adds support for discard into the IR. The `discard` statement is
handled as an instruction in the current block. The `discard` is a
`demote_to_helper` in WGSL so control flow has to continue after the
discard, it just predicates writes. So, an instruction seems like the
most logical way to express.
Bug: tint:1718
Change-Id: I0d2fb029631523d72a7811d0be0715732427c302
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129200
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
When an OpConstantComposite result is used by multiple instructions,
declare it as a module-scope `const` instead of inlining the constant
at each use site. This fixes an issue whereby the spirv-reader was
massively inflating the size of the WGSL it produces, which was caught
via an OOM fuzzer bug.
Bug: oss-fuzz:57795
Change-Id: Iac8c6a2147a7e2ebfddbaacae9fcb1dbe0b59e9d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128881
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Commit-Queue: David Neto <dneto@google.com>
The declaration may be nullptr, so doing this avoids a potential
nullptr deref when the struct is an internal type (e.g. frexp
result). In these cases we will now fail to resolve the resulting
code, which is a little better than just crashing.
A future change will update the resolver to allow us to use the
internal struct names from our transforms.
Bug: chromium:1430309
Change-Id: Ic72b5105bf3159c448c20dd9228d73b25a632b69
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129120
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Whitebox tests call internal functions directly. However, when
implicit device synchronization feature is turned on, some of these
functions will expect that the device is already locked. Thus leading
to assertion failures.
So we need to disable the tests when this feature is turned on.
Bug: dawn:1662
Change-Id: I1d65b4779c933313b5835f1bddbc57703b3ced53
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127180
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
When `invariant` is enabled on MSL was was incorrectly setting
`@invariant` instead of `[[invariant]]`. We test with metal1.2 which
does not have invariant, so this only showed up when using metal2.1 or
higher.
Bug: chromium:1439273
Change-Id: Iab866608195e697b0370d465f350b25277d904a3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128880
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Normal behavior of ApiObjectBase's APIRelease() which only locks the
device when last ref dropped is not thread safe if the object is cached
as raw pointers by the device. Example of cached objects: bind group
layout, pipeline, sampler, shader module.
The following scenario could happen:
- thread A:
- shaderModuleA.APIRealease()
- shaderModuleA.refCount.Decrement() == true (ref count has reached zero)
- going to call shaderModuleA.LockAndDeleteThis().
- thread B:
- device.CreateShaderModule().
- lock()
- device.GetOrCreateShaderModule()
- shaderModuleA is in the cache, so return it.
- unlock()
- thread A:
- starting to call shaderModuleA.LockAndDeleteThis()
- lock()
- erase shaderModuleA from the cache.
- delete shaderModuleA.
- unlock()
This CL fixes this bug by locking the entire APIRelease() method until
we find a better solution.
Bug: dawn:1769
Change-Id: I1161af66fc24f3a7bafee22b9614b783e0dc4503
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128441
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
BufferBase uses a staging buffer to upload data for non-mappable
buffer created with mappedAtCreation. However BufferBase doesn't
unmap staging buffer before copy data from it. But d3d11 debug
layer complain this illegal usage. It causes test failures.
Bug: dawn:1772
Change-Id: Id1c386ac7c45f41487f9cc7ef4e431eab87ba1c2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128480
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
This reverts commit 8cc6205bf7.
Reason for revert: Graphite actually reuses the bind groups between
draw calls using different pipelines and this change prevents it
from happening.
Original change's description:
> Disable frontend cache when implicit device sync is on.
>
> Normal behavior of ApiObjectBase's APIRelease() which only locks the
> device when last ref dropped is not thread safe if the object is cached
> as raw pointers by the device. Example of cached objects: bind group
> layout, pipeline, sampler, shader module.
>
> The following scenario could happen:
> - thread A:
> - shaderModuleA.APIRealease()
> - shaderModuleA.refCount.Decrement() == true (ref count has reached zero)
> - going to call shaderModuleA.LockAndDeleteThis().
> - thread B:
> - device.CreateShaderModule().
> - lock()
> - device.GetOrCreateShaderModule()
> - shaderModuleA is in the cache, so return it.
> - unlock()
> - thread A:
> - starting to call shaderModuleA.LockAndDeleteThis()
> - lock()
> - erase shaderModuleA from the cache.
> - delete shaderModuleA.
> - unlock()
>
> This CL disables caching when ImplicitDeviceSynchronization is turned on
> until we find a better solution.
>
> Bug: dawn:1769
> Change-Id: Ideb2a717ece0a40e18bd1c2bef00817262bd25da
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127900
> Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
> Reviewed-by: Austin Eng <enga@chromium.org>
> Kokoro: Kokoro <noreply+kokoro@google.com>
TBR=cwallez@chromium.org,enga@chromium.org,noreply+kokoro@google.com,dawn-scoped@luci-project-accounts.iam.gserviceaccount.com,lehoangquyen@chromium.org
Change-Id: Ib13bba8005402d06963865fae919388a91e718f0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: dawn:1769
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128440
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Normal behavior of ApiObjectBase's APIRelease() which only locks the
device when last ref dropped is not thread safe if the object is cached
as raw pointers by the device. Example of cached objects: bind group
layout, pipeline, sampler, shader module.
The following scenario could happen:
- thread A:
- shaderModuleA.APIRealease()
- shaderModuleA.refCount.Decrement() == true (ref count has reached zero)
- going to call shaderModuleA.LockAndDeleteThis().
- thread B:
- device.CreateShaderModule().
- lock()
- device.GetOrCreateShaderModule()
- shaderModuleA is in the cache, so return it.
- unlock()
- thread A:
- starting to call shaderModuleA.LockAndDeleteThis()
- lock()
- erase shaderModuleA from the cache.
- delete shaderModuleA.
- unlock()
This CL disables caching when ImplicitDeviceSynchronization is turned on
until we find a better solution.
Bug: dawn:1769
Change-Id: Ideb2a717ece0a40e18bd1c2bef00817262bd25da
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127900
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Fixes 2 CMake issues:
1. GLFW subdirectory was added regardless of
DAWN_SUPPORTS_GLFW_FOR_WINDOWING.
2. Android uses the AHardwareBuffer implementation of
memory service. But in the CMake MemoryServiceOpaqueFD.cpp
was added instead of MemoryServiceAHardwareBuffer.cpp .
Bug: dawn:286
Change-Id: I6d81976a5c12717b3e565c4d9f8d5ae54f4e0446
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128260
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
BufferTests.CreateBufferOOM/D3D11_Intel_R_UHD_Graphics_630 fails on
trybots due to buffer size overflow UINT which is used as size for
create ID3D11Buffer.
This CL fixes above issue and also uses CheckOutOfMemoryHRESULT()
to handle hresult from texture and buffer creation. It makes OOM
an allowed error.
Bug: dawn:1705
Change-Id: I2c4a4841cac15934fe83b7f7d6e568e9f3c8d210
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128280
Reviewed-by: Austin Eng <enga@chromium.org>
Auto-Submit: Peng Huang <penghuang@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Peng Huang <penghuang@chromium.org>
Currently the `is_reserved` method in the WGSL parser uses the
`operator==` on the token to check the reserved words. This ends up
re-doing a bunch of work as it checks the token type, then gets the
`string_view` or `string` from the variant, then compares.
This CL adds a precondition that the token is an identifier (which is
true in the only case we call this method) and then extracts the string
from the token once and uses that for all the comparisons.
Change-Id: If425afea38e727169de7991a84f6fa1e47f660ef
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128140
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>