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>
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>
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>
Offset > 0 is already implicitly included in this if statement
(when `offset == 0` then `size > mDataLength` could safely assert it's invalid).
So we could remove it and use `offset > mDataLength` instead of `>=`.
Bug: chromium:1340654
Change-Id: Ieafe1ea6bef5aae29bc6ef2bd9702d6f7a92d8b5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95820
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Shrek Shao <shrekshao@google.com>
Materialize() was re-evaluating the constant values for the incoming
semantic expression, despite this already being evaluated. Just use the
sem::Expression::ConstantValue().
resolver.cc already has all the semantic pointers, so pass them in
instead of pointlessly hitting the ast -> sem map.
Change-Id: If2bc7cd10f79079fb811e9d83c5150dd3c0c244c
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95764
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Any AST expression may map to a sem::Materialize, so the inferred
mapping is bug-prone (the implicit sem type may mismatch and Get() may
return nullptr).
Change-Id: I34485a4a067635df930a407316fae8b2e9628c3d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95763
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
This CL add methods that return the binary16 bit pattern for a
constructed Number<detail::NumberKindF16>. This is required for
generating SIPR-V oprand.
Bug: tint:1473, tint:1502
Change-Id: Ia3680cdb5a0e64d31bfe2f48432cda3850c1f5a7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95240
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
The structured CFG rule was revised/clarified in SPIR-V 1.6 Rev2
Validation now rejects a few cases.
SpvParserTest, ValueFromBlockNotInBlockOrder
SpvParserFunctionVarTest, EmitStatement_Phi_ValueFromBlockNotInBlockOrderIgnored
SpvParserFunctionVarTest_EmitStatement_Phi_ValueFromBlockNotInBlockOrderIgnored
- Originally from crbug.com/tint/804
Invalid by SPIR-V 1.6 Rev2 update to validation rules:
- Block 80 is a structurally reachable continue target
- Block 25 is not structually reachable, and not part of the loop,
but branches to 80.
vk-gl-cts/graphicsfuzz/cov-dead-branch-func-return-arg/0-opt.*
- The continue construct with the continue target 37[%37]
is not structurally post dominated by the back-edge block 64[%64]
- The SPIRV-Tools inliner no longer creates such cases. It splits the
single-block loop and pushes the continue target down.
vk-gl-cts/graphicsfuzz/nested-for-loops-with-return/0-opt.spvasm
- The loop headed at block 46 does not structurally dominate its merge
block 44. There is a continue-target edge from 41 to 44.
SpvParserCFGTest_ClassifyCFGEdges_BackEdge_MultiBlockLoop_MultiBlockContinueConstruct_ContinueIsHeader.spvasm
SpvParserCFGTest_EmitBody_Loop_MultiBlockContinueIsEntireLoop.spvasm
SpvParserCFGTest_LabelControlFlowConstructs_MultiBlockLoop_HeaderIsContinue.spvasm
SpvParserCFGTest_SiblingLoopConstruct_ContinueIsWholeMultiBlockLoop.spvasm
SpvParserCFGTest, ClassifyCFGEdges_BackEdge_MultiBlockLoop_MultiBlockContinueConstruct_ContinueIsHeader
SpvParserCFGTest, EmitBody_Loop_MultiBlockContinueIsEntireLoop
SpvParserCFGTest, LabelControlFlowConstructs_MultiBlockLoop_HeaderIsContinue
SpvParserCFGTest, SiblingLoopConstruct_ContinueIsWholeMultiBlockLoop
- Continue target 20 also its own loop header, but is not structurally
post-dominated by the backedge block.
- Delete the end-to-end test.
- Keep the unit test because it's about classifying edges, but disable dumping
into the end2end suites.
Change-Id: I9ec2504aadd2fec9ea463901af7dc1b5f47481b5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95580
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: David Neto <dneto@google.com>
