The shader source can be very large and this is causing excessively
large error messages that get truncated in some applications that use
Dawn native. We don't need to see the whole shader in the error
message.
Change-Id: I15ad7fa7814d19875a7c28b39e5fa9a24f265b98
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/90161
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This patch:
1. Add the `f16` WGSL extension.
2. Add `f16` as keyword, and remove it from reserved word list.
3. Add ast::f16 and sem::f16, and implement validation that using `f16`
type must be with `f16` extension enabled.
4. Add `Number<NumberKindF16>` for f16 literal and constant, and add
`ast::FloatLiteralExpression::Suffix::kH`.
5. Add placeholder in all writer which report error when try to emit f16
type.
Bugs: tint:1473, tint:1502
Change-Id: Ifb363beeb2699ed7cac57e07227d1b2cfa8050b4
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89922
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
The WebGPU spec says that a validation error is produced if there is a
color target in the pipeline descriptor that has writeMask!=0 while
there are no shader outputs for this target. In Dawn format==undefined
is used as a tag that the color target is not present, so writeMask is
allowed to be 0 if format==undefined. (the validation in the case where
format!=undefined was already present).
Fixed: dawn:1376
Change-Id: I7737b6557223e0fc31740fd4ec2cbfaa54b77a71
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/90040
Auto-Submit: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
If the function has no return statements, we need to do this to
capture the potential non-uniformity coming from nested function
calls.
This also removes the need to add explicit edges for discard
statements, so remove them.
Bug: tint:880
Change-Id: I88b1132faf35a6d36460ef353912f77a15f8abaa
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89861
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Chromium tracks the devices which live on the wire so it can
automatically call tick on devices that have pending work. This used
to be done by querying an (id, generation) pair and checking if it
resolves to a non-null device.
This CL adds a new way to query directly using the device, since a
refactor in Chrome will change creation such that the id and generation
is not known when a new device is requested.
Also fixes a bug for device callbacks where the required callback
userdata wasn't fully populated for devices created with
requestAdapter. Update a test to check for this as well.
Bug: chromium:1315260
Change-Id: I7468edc3e77bade191e1e9f3eaadebbf4441d88a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89520
Reviewed-by: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
When producing an error from the uniformity analysis, add notes to
show the underlying reason for the uniformity requirement.
For function calls that are required-to-be-uniform, show the innermost
builtin call that has the requirement.
For function parameters that are required-to-be-uniform, recurse into
that function to show where its requirement comes from.
Add some new tests to specifically test the error messages.
Bug: tint:880
Change-Id: Ib166fdeceaffb156a3afc50ebc5a4ad0860dc002
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89722
Reviewed-by: Ben Clayton <bclayton@google.com>
Move the control flow graphs to `FunctionInfo` so that they are not
destroyed when we finish processing the function.
This will make it easier to produce more detailed diagnostics for
uniformity issues, which will be coming in subsequent CLs.
There is no functional change in this CL.
Bug: tint:880
Change-Id: I1322fb54b16bd1c660799a62435fbdcd7fb39cb2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89822
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
This implements the uniformity analysis as currently described in the
WGSL specification. Uniformity issues are presented as warnings, and
will be switched to errors in a future release.
A follow-up patch will improve the error messages, which currently
just show the point at which a uniformity was detected.
In a future release, once we have obtained initial feedback from
users, uniformity issues will become errors.
Bug: tint:880
Change-Id: I7d0b3080932c786c5d50b55720fec6d19f00d356
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/88368
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Baker <alanbaker@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
There is currently a race condition in the metal backend with the
updating of `mCompletedSerial`. It is currently possible for the
`addCompletedHandler` to set to one value and then have the
`CheckAndUpdateCompletedSerial` call immediately set it back to
a lower value. This can then cause hangs as the serial never
correctly updates again.
This was happening on `dawn.node` when running a large number of
CTS test cases all at the same time.
Change-Id: I28fc58ab2b3737ca8039559718e539ce819e88bb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89780
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Otherwise, calling `Sem().Get()` on an empty loop continuing block
will return nullptr, which causes issues when inspecting the semantic
information of ast::BlockStatement nodes generically.
Change-Id: Ib3665b750c96eda02355fa879cf6300b8d69293a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89721
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
This is done via a new extension, which in the future could also be
used by shader authors as an escape hatch while we are still refining
the analysis.
The transform is run by the sanitizers for all of the non-WGSL
backends.
Bug: tint:880
Change-Id: Ibe90d7437d34c741a91eda65dff6d21d8469b9c7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/88464
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Unsuffixed float literals are currently treated as f32,
but will shortly become AbstractFloat. To keep tests behaving
identically to how they are currently, change all float literals
to explicitly use the f32 '_f' suffix.
Bug: tint:1504
Change-Id: I2a00725ee1b34a6efbe15ac4ba438c00c4416dd8
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89402
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Generate different tokens for:
• 'f' suffixed float literals
• unsuffixed integer literals
'f' and unsuffixed are currently both treated as f32 by the resolver,
but this is the first step to supporting abstract floats.
Bug: tint:1504
Change-Id: Id3b1fe420b6eb8901f88d6a5de06ef4f54aa3edf
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89031
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
• Declare all the unary ops in the intrinsics.def file.
• Reimplement the bulk of Resolver::UnaryOp() with the IntrinsicTable.
This will simplify maintenance of the operators, and will greatly
simplify the [AbstractInt -> i32|u32] [AbstractFloat -> f32|f16] logic.
Bug: tint:1504
Change-Id: Ifc646d086fc93cfbe3f3f861b8c447178664c1f7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89028
Reviewed-by: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
• Declare all the binary ops in the intrinsics.def file.
• Reimplement Resolver::BinaryOpType() with the IntrinsicTable.
This will simplify maintenance of the operators, and will greatly
simplify the [AbstractInt -> i32|u32] [AbstractFloat -> f32|f16] logic.
Bug: tint:1504
Change-Id: Ie028602e05b59916c3f2168c92f200f10e402b96
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89027
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Adapt the builtin parsing and resolving to also support operators.
Will be used to generate intrinsic table entries for operators.
This will simplify maintenance of the operators, and will greatly
simplify the [AbstractInt -> i32|u32] [AbstractFloat -> f32|f16] logic.
Bug: tint:1504
Change-Id: Id75735ea24e501877418812185796f3fba88a521
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89026
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
