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>
This patch adds ResolveDeferredExpectationsNow() as a helper
function of dawn_end2end_tests to let all the deferred expectations
be resolved and cleared immediately to avoid consuming too much
memory for all the deferred expectations before the exit of the test
body.
We use ResolveDeferredExpectationsNow() in the end2end test
CopyFromNonZeroMipLevelWithTexelBlockSizeLessThan4Bytes because
previously because this test will always consume too much memory to
allocate vectors and the allocation of std:vector will sometimes fail
on the bots.
Bug: chromium:1312066
Test: dawn_end2end_tests
Change-Id: I5a87338b0683a3a821eef888fb6469e6ac2dc075
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94986
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Change sem::Constant to be an interface to the constant data. Implement
this so that zero-initialized data doesn't need to allocate the full
size of the type.
This also makes usage a lot cleaner (no more flattened-list of
elements!), and gives us a clear path for supporting constant
structures if/when we want to support them.
Bug: chromium:1339558
Bug: chromium:1339561
Bug: chromium:1339580
Bug: chromium:1339597
Change-Id: Ifcd456f69aee18d5b84befa896d7b0189d68c2dd
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94942
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
An abstract base class (Device::Context) is used to avoid adding dependencies to Device, with ContextEGL derived from it. This also
leaves open the possibility of supporting other native GL contexts
in the future (e.g., glX). One temporary EGLContext is created by opengl::Backend during Adapter discovery, then one is created for and
owned by each Device.
Contexts for the desktop GL backend are also managed via EGL, which
works for most modern drivers. This also means that GLFW is now
always used in GLFW_NO_API mode.
Since contexts are now per-device, all of the default GL state
setting and debug output setup was moved from Adapter to Device.
Bug: dawn:810
Change-Id: Idfe30939f155d026fcad549787fc167cc43aa3cb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/93981
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
When enabling the SPIR-V reader or SPIR-V writer we were suppressing
-Wnewline-eof, -Wold-style-cast, -Wsign-conversion, and -Wweak-vtables
for the `libtint` cmake target and anything that depended on that
target. Because we'd build all readers/ writers by default this caused
us to never hit those warnings.
A recent change to the cmake build sets the Tint backend based on
the Dawn backend. So, there is a much higher chance of not building
the SPIR-V support if you're on a Mac or Windows machine.
This CL removes the suppression of the warnings, adds specific pragmas
into the SPIR-V reader code which imports the SPIRV-Tools headers
and fixes up the warnings which were then firing due to checking
for the new warnings.
Change-Id: I0d0be6aa3d0b692e939ce8ff924dfb82c82792fc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94901
Reviewed-by: Ben Clayton <bclayton@google.com>
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
This function was attempting to pick a higher-precision type by using
the decltype() of FROM + TO. This doesn't work if FROM and TO are both
similar bit-widths, and of a different signness, as the picked type may
not be wide enough to hold both the signed and unsigned representation.
Just use AInt or AFloat (both 64-bit), which are the largest types
supported by WGSL.
Change-Id: Ic76475d98bad8def12a0283a1c83c62f2ed58b5d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95041
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@google.com>
This patch re-enables the workaround for T2T copy issue on Intel
GPUs as we have found there are still other issues about T2T copies
on latest Intel D3D12 driver when we investigate the WebGPU CTS
failures on Intel Gen9 and Gen9.5 GPUs.
Bug: chromium:1161355
Change-Id: Ibd8a8c299453dff6a5432b3c4ab5350558c5313f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94980
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
