Signaling a fence in Dawn without waiting can cause a race between Dawn
and Chromium over who signals the fence. Since D3D12 fences are allowed
to be rewound this can cause future waits to hang indefinitely if Dawn
loses the race and signals a lower value than what Chromium expects.
The signal without wait case happens when Dawn submits no command lists
e.g. when CopyExternalImageToTexture uses a zero-sized dimension. This
is the reason for the test failures in https://crrev.com/c/3700811 e.g.
https://ci.chromium.org/ui/p/chromium/builders/try/dawn-win10-x64-deps-rel/24617/overview
To fix the race, it's sufficient to wait before signaling if not already
waited which is what this CL does. This CL also makes the fence stay
alive until pending signals are done - this wasn't the root cause of the
hang described above, but it's still a good idea for robustness, and
also recommended based on discussion around past Chromium XR fence use.
Bug: dawn:576
Change-Id: I8c1d1a19fdb022ae28d26f6723c2f2bfc9c1c3c7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96321
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Add a 'NodeID' to each ast::Node which is the sequentially allocated
index of the node. Use this in sem::Info to map the AST node to the
semantic node, instead of using a std::unordered_map.
Optimised very hot code by entirely eliminating map lookups, and
dramatically reducing cache misses (lookups are usually sequentually
ordered).
Timings running
'webgpu:shader,execution,expression,call,builtin,atan2:f32:inputSource="const";vectorize="_undef_"'
with dawn/node, using SwiftShader:
Without change: 3.22647107s
With change: 3.10578879s
Bug: tint:1613
Change-Id: I22ec48d933b2e5f9da04494bff4e979e6f7b1982
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96140
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Use the @const annotations to more efficently dispatch to the right
method of the ConstEval class.
Reduces a whole lot of dynamic casting logic.
Change-Id: I6791aac51b935b46d63af29abd1e577b3306a0ff
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95950
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Update:
- expectations.txt
- ts_sources.txt
- resource_files.txt
- webtest .html files
8cfc317e23..a41bc407a8
- a41bc4 Implement val:render_pass_descriptor:timestampWrite,same_query_index (#1656)
- 167076 Implement val:render_pass_descriptor:timestamp_writes_query_set_type (#1653)
- 06954d Implement val:render_pass_descriptor:timestampWrite,query_index (#1654)
- deec4f Implement val:render_pass_descriptor:occlusion_query_set_type (#1652)
- 3bef26 Succinct the test names of render_pass_descriptor.spec.ts (3/3) (#1651)
- 425fc8 Convert `clamp` f32 tests to use interval framework (#1645)
- 46fce2 Add support for multiple intervals to FP testing framework (#1643)
- 09c7fb Address feedback from Kai
- f803ff Add context configuration tests
- d620a1 Address feedback from Kai
- 77633d Add tests for getCurrentTexture and getPreferredCanvasFormat
- 781ad8 Succinct the test names of render_pass_descriptor.spec.ts (2/n) (#1639)
- d7ca02 Implement val:render_pass_descriptor:timestamp_writes_location (#1630)
- 09793f Test zero levels or layers is invalid in render_pass,resolve:resolve_attachment (#1600)
- daf0da Split shader_stages_and_visibility and add control cases
- 496182 Rewrite usage validation scope tests
- f4e9a3 refactor: split out makeConflictingBindGroups from testValidationScope
- bc278d nits: simplify a few things in this file
- a65914 Implement val:render_pass_descriptor:depth_stencil_attachment_depth_clear_value (#1640)
- a6bab7 Implement api,validation,capability_checks,features,texture_formats:canvas_configuration_view_formats (#1593)
- e7f8fe Succinct the test names of render_pass_descriptor.spec.ts (1/n) (#1619)
- 7f3683 Convert `fract` tests to use interval framework (#1612)
- d8009f Correct logInterval & log2Interval handling of out of bounds inputs (#1629)
Created with './tools/run cts roll'
Change-Id: I10d895c4a11252317619f7ea480c97d821cbf81c
Cq-Include-Trybots: luci.chromium.try:dawn-try-win10-x86-rel,linux-dawn-rel,mac-dawn-rel,win-dawn-rel
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96200
Commit-Queue: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Auto-Submit: Ben Clayton <bclayton@google.com>
Extract out the methods of Resolver::EvaluateXXXValue() to a new
tint::resolver::ConstEval class.
Removes more bloat from Resolver, and creates a centralized class for
constant evaluation, which can be referred to by the IntrinsicTable.
Change-Id: I3b58882ef293fe07f019ad2138a7e9dbbac8de53
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95951
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Restructure the logic so there's less, pointless dynamic casting, and the complexity is reduced.
This alters the order in which variables are validated, hence the change of test.
Change-Id: I9a3120c0278faa5ac9f1db65eeb71a8e4a705596
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95948
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
This patch fix the GLSL writer issue that emit only one helper function
when using both `v % s`, `s % v` and `v % vs in the shader, where `s` is
of `f32` and `v` is a vector of `f32`. Unittests are added for GLSL.
Bug: tint:1614
Change-Id: Ia89ae010341b9c88b8101cc6febab7d83c96bb17
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96085
Reviewed-by: Ben Clayton <bclayton@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
This patch adds a toggle to force initializing depth stencil textures
to 0 on Intel D3D12 drivers as a driver issue will occur when we
create and copy into a depth stencil texture that is just created with
CreatePlacedResources() on Intel D3D12 drivers:
- For the depth stencil textures with RenderAttachment usage, they will
always be cleared with ClearDepthStencilView() instead of copy, then
the following copies will be correct.
In next patch we will handle the situation when the depth stencil
texture is not created with RenderAttachment usage.
Bug: dawn:1487
Test: dawn_end2end_tests
Change-Id: I0f7db86a2e6db55e4b82defb510ccc829c6b0d38
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95989
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
This helps output in the headers information about which structure can
be used to extend which. In the future it could also be used to generate
helpers that validate that the chain for a root structure contains only
allowed extension structs.
Fixed: dawn:1486
Change-Id: I6134332d477503e242b3bec9f8e9bedeeb352351
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96000
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
• Add `intel-hd-630-family` to the list of GPU tags (crbug.com/dawn/1444).
• `[ Skip ]` all the `inputSource="const"` expression tests for now (crbug.com/tint/1613).
• Reorder / normalize the rest of the expectations with `./tools/run cts update`.
Bug: dawn:1444
Bug: tint:1613
Change-Id: I39efc454ecff6e804417bcade744a4251acbda07
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95842
Reviewed-by: Austin Eng <enga@chromium.org>
Auto-Submit: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
The `el_count` will match the WGSL declared array size *before validation*.
Fuzzers have started triggering out-of-memory cases by constructing large constant arrays, just to then error out.
Bug: chromium:1343963
Change-Id: I537ff3a570fe56b40e510b3bc6dfcd9b9752386a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96102
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
D3D12 objects can have implicit dependencies on device resources that
are not captured by holding ComPtrs:
"Direct3D 12 uses COM-style reference counting only for the lifetimes of
interfaces (by using the weak reference model of Direct3D tied to the
lifetime of the device). All resource and description memory lifetimes
are the sole responsibly of the app to maintain for the proper duration,
and are not reference counted. Direct3D 11 uses reference counting to
manage the lifetimes of interface dependencies as well."
Source: https://docs.microsoft.com/en-us/windows/win32/direct3d12/important-changes-from-directx-11-to-directx-12
ExternalImageDXGI can outlive the device it was created on e.g. the D3D
shared image backing holds on to the ExternalImageDXGI for its lifetime.
ExternalImageDXGI destructor can invoke code that depends on D3D12
resources that might have already been destroyed. In particular, this
shows up as ComPtr::Release for ID3D12Fence crashing mysteriously, and
is also speculated as the cause for a racy invalid function pointer
dereference in crbug.com/1338470.
This CL makes the D3D12 backend device destroy the ExternalImageDXGI's
resources on device destruction making it effectively a weak pointer.
This unblocks landing https://crrev.com/c/3700811 and hopefully fixes
crbug.com/1338470 as well.
This CL also deprecates unnecessary WGPUDevice param to ProduceTexture,
and adds an IsValid() method so that the shared image can check it and
decide to recreate the ExternalImageDXGI if needed.
Bug: dawn:576, chromium:1338470
Change-Id: I2122cf807587cf3b1218ba29ea291263df0cf698
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95860
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This patch make SPIRV writer support emitting f16 types, f16 literals,
f16 constructor and convertor. Unittests are also implemented.
Currently SPIRV writer will require 4 capabilities in generated SPIRV:
`Float16`, `UniformAndStorageBuffer16BitAccess`,
`StorageBuffer16BitAccess`, and `storageInputOutput16`.
Bug: tint:1473, tint:1502
Change-Id: Ia1af04f1f4a02bf1b1c2599a5d89791854eabc16
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95920
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
In Mach engine we compile Dawn's d3d12 backend using Zig as a C/C++
compiler, effectively clang with MinGW windows headers. Unfortunately,
this `static constexpr` fails to compile:
```
error: constexpr variable 'kD3D12PromotableReadOnlyStates' must be initialized by a constant expression
```
As kangz previously noted, the reason appears to be because `D3D12_RESOURCE_STATE_COPY_SOURCE`
is not `constexpr` [in MinGW headers](1de9cc347d/mingw-w64-headers/include/winnt.h (L682)).
The thought process is that making this just `const` is fine because
constant propagation would make it a constant anyway.
If we're comfortable merging this, it'd be one less change we have to
maintain on our side - and probably no impact otherwise. On the other
hand, I understand the most-correct fix would be in MinGW headers
themselves. I'd love to land this change, but it's no big deal if you
prefer not.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Change-Id: I772f1cb7e2b4f1b200820cd50f6b7df45850abbb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/87381
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
