Most of this change is fixing up the numerious tests that violated this rule.
Fixed: tint:1365
Issue: tint:1374
Change-Id: I38da27c7367277fe60857208170fec017e80bd25
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/76400
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
It seems we haven't run our e2e tests with FXC validation in a long time
- at least not since we've added the vk-gl-cts corpus.
Locally disabled exclusion of "/test/vk-gl-cts/" in test-runner/main.go,
and ran:
./test/test-all.sh out/build/x64-Debug/tint.exe --format hlsl --fxc --generate-skip
These will need to be manually removed once the skips aren't needed by
deleting them all, and re-running as above.
Bug: tint:940
Change-Id: I27e395e69f5e1bd7d234f3155f40396b751720d4
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/71981
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Migrate some of the validation logic over to use the results of behavior
analysis.
The most significant changes are:
* Unreachable-statements now consider merge-points of control flow. For
example, if all branches of a if-statement or switch-statement either
return or discard, the next statement will be considered unreachable.
* Unreachable statements are no longer an error, but a warning. See
https://github.com/gpuweb/gpuweb/issues/2378.
* Statements that follow a loops that does not break, or have a
conditional will now be considered unreachable.
* Unreachable statements produced by the SPIR-V reader are now removed
using the new RemoveUnreachableStatements transform.
Some other new changes include additional validation for the continuing
block for for-loops, to match the rules of a loop continuing block.
The new cases this validation is testing for are not expressible in
WGSL, but some transforms may produce complex continuing statements that
might violate these rules. All the writers are able to decay these
complex for-loop continuing statements to regular loops.
Bug: tint:1302
Change-Id: I0d8a48c73d5d5c30a1cddf92cc3383a692a58e61
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/71500
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Now that I've landed this change to Dawn to disable FXC optimizations:
https://dawn-review.googlesource.com/c/dawn/+/70700,, we can reland this
change. The Tint-into-Dawn roll was failing because FXC would miscompile
certain loops into infinite loops when not unrolled.
Also reland
test/bug/fxc/gradient_in_varying_loop/1112.wgsl.expected.hlsl
Bug: tint:1112
Bug: dawn:1203
Change-Id: I641d68864b833e0fbe3b117d397b89ae96482536
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/71000
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
This reverts commit 11d09f2fe7.
Reason for revert: Failing roll of Tint to Dawn: https://dawn-review.googlesource.com/c/dawn/+/70100
Original change's description:
> HLSL: force FXC to never unroll loops
>
> Emit the "[loop]" attribute on "for" and "while" so that FXC does not
> attempt to unroll them. This is to work around an FXC bug where it fails
> to unroll loops with gradient operations.
>
> FXC ostensibly unrolls such loops because gradient operations require
> uniform control flow, and loops that have varying iterations may
> possibly not be uniform. Tint will eventually validate that control flow
> is indeed uniform, so forcing FXC to avoid unrolling in these cases
> should be fine.
>
> Bug: tint:1112
> Change-Id: I10077f8b62fbbb230a0003f3864c75a8fe0e1d18
> Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/69880
> Kokoro: Kokoro <noreply+kokoro@google.com>
> Reviewed-by: Ben Clayton <bclayton@google.com>
> Commit-Queue: Antonio Maiorano <amaiorano@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: tint:1112
Change-Id: I8e8f3c0abfa6e6bc5d0e67af9428a46ef867d5c1
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/70540
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Emit the "[loop]" attribute on "for" and "while" so that FXC does not
attempt to unroll them. This is to work around an FXC bug where it fails
to unroll loops with gradient operations.
FXC ostensibly unrolls such loops because gradient operations require
uniform control flow, and loops that have varying iterations may
possibly not be uniform. Tint will eventually validate that control flow
is indeed uniform, so forcing FXC to avoid unrolling in these cases
should be fine.
Bug: tint:1112
Change-Id: I10077f8b62fbbb230a0003f3864c75a8fe0e1d18
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/69880
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Some pass DXC, but not FXC (e.g. continue_in_switch).
Some now pass (e.g intrinsics/gen/atan2/*.hlsl)
Some now fail gracefully instead of asserting (e.g. 807.spv)
Change-Id: I92b17fcadc7850de5bd93ff07507cea7e5487fc9
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/68820
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@chromium.org>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
The `Ignore()` intrinsic is about to be deprecated, so don't use it for testing.
Bug: tint:1213
Change-Id: I314ecaeb9a9c337c7b6980189054120a74807ebd
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/67066
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
Reviewed-by: James Price <jrprice@google.com>
Metal 1.x does not support swizzling on packed_vec types.
Use array-index for single element selection (permitted on LHS and RHS of assignment)
Cast the packed_vec to a vec for multiple element swizzles (not permitted as the LHS of an assignment).
Fixed: tint:1249
Change-Id: I70cbb0c22a935b06b3905d24484bdc2edfb95fc2
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/67060
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Ben Clayton <bclayton@google.com>
Reviewed-by: James Price <jrprice@google.com>
This reverts commit e5dbe24e94.
Reason for revert: Makes the Tint-Dawn roll fails because of
MSL compilation errors on as_type<uint>(-2147483648):
as_type cast from 'long' to 'uint' (aka 'unsigned int') is not allowed
as_type<uint>(-2147483647) compiles fine, so this is most
likely because the MSL compiler types the literal as a long
(since without the - it is larger than the max int32).
Original change's description:
> MSL writer: make signed int overflow defined behaviour
>
> Bug: tint:124
> Change-Id: Icf545b633d6390ceb7f639e80111390005e311a1
> Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/60100
> Kokoro: Kokoro <noreply+kokoro@google.com>
> Commit-Queue: Antonio Maiorano <amaiorano@google.com>
> Reviewed-by: David Neto <dneto@google.com>
TBR=dneto@google.com,bclayton@google.com,jrprice@google.com,amaiorano@google.com,noreply+kokoro@google.com,tint-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I3e3384a9185013bb141a1b7b9b22bad8571bbc50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: tint:124
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/60345
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
Auto-Submit: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
The new vk-gl-cts tests have uncovered a whole bunch of FXC issues,
which have been filed as tint bugs.
Bug: tint:998
Bug: tint:1080
Bug: tint:1038
Bug: tint:1081
Bug: tint:1082
Bug: tint:1083
Change-Id: I0d14370f94647dfd9c7088e0b782c3b415c78ee7
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/60211
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>