Don't generate them either, which generated a lot of test churn.
Fixed: tint:1380
Change-Id: I0a7cfdd2ef0ffe8e7fda111fbc57997b36b949e0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/77165
Auto-Submit: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This has been deprecated and will soon be removed.
Bug: tint:1324
Change-Id: If5dbbc3a40d7591591fb2802dbe9c8dd5f96d299
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/72087
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@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>
This removes a lot of awkward logic from the MSL writer, and means
that we now handle all module-scope variables with the same transform.
Change-Id: I782e36a4b88dafbc3f8364f7caa7f95c6ae3f5f1
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/67643
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Change ast::Array to use an ast::Expression for its `size` field. The
WGSL frontend now parses the array size as an `primary_expression`,
and the Resolver is responsible for validating the expression is a
signed or unsigned integer, and either a literal or a non-overridable
module-scope constant.
The Resolver evaluates the constant value of the size expression, and
so the resolved sem::Array type still has a constant size as before.
Fixed: tint:1068
Fixed: tint:1117
Change-Id: Icfa141482ea1e47ea8c21a25e9eb48221f176e9a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/63061
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@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>
Arrays can be extremely large, and having the load and store functions unroll the elements can make the complier explode.
Fixed: chromium:1229233
Change-Id: Ieb5654254e16f5ce724a205d21d954ef9a0cd053
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/58382
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
Auto-Submit: Ben Clayton <bclayton@google.com>
CloneContext::Replace(T* what, T* with) is bug-prone, as complex transforms may want to clone `what` multiple times, or not at all. In both cases, this will likely result in an ICE as either the replacement will be reachable multiple times, or not at all.
The CTS test: webgpu:shader,execution,robust_access:linear_memory:storageClass="storage";storageMode="read_write";access="read";atomic=true;baseType="i32"
Was triggering this brokenness with DecomposeMemoryAccess's use of CloneContext::Replace(T*, T*).
Switch the usage of CloneContext::Replace(T*, T*) to the new function form.
As std::function is copyable, it cannot hold a captured std::unique_ptr.
This prevented the Replace() lambdas from capturing the necessary `BufferAccess` data, as this held a `std::unique_ptr<Offset>`.
To fix this, use a `BlockAllocator` for Offsets, and use raw pointers instead.
Because the function passed to Replace() is called just before the node is cloned, insertion of new functions will occur just before the currently evaluated module-scope entity.
This allows us to remove the "insert_after" arguments to LoadFunc(), StoreFunc(), and AtomicFunc().
We can also kill the icky InsertGlobal() and TypeDeclOf() helpers.
Bug: tint:993
Change-Id: I60972bc13a2fa819a163ee2671f61e82d0e68d2a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/58222
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
FXC has trouble dealing with these.
This was originally added to handle returning arrays as structures.
HLSL supports typedefs, which is a much simpiler solution, and doesn't upset FXC.
Bug: tint:848
Bug: tint:904
Change-Id: Ie841c9c454461a885a35c41476fd4d05d3f34cbf
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/56774
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
These indices were a mix of signed and unsigned.
Modulus on the signed integers was producing FXC warnings about performance.
Change-Id: Ib82f4296199a09d2f03be8b06314feefce0022e2
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/56765
Auto-Submit: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
For structures and arrays.
This behaves identically to the per-element zero-initialization, but can be significantly less verbose.
Change-Id: I380ef86f16c2b3f37a9de2820e707f368955b761
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/56764
Auto-Submit: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
UniqueIdentifier() will generate a program-global unique symbol.
MslGeneratorImplTest.AttemptTintPadSymbolCollision tests for collisions with the field names.
TextGeneratorTest.UniqueIdentifier_ConflictWithExisting tests for collisions between general symbols.
Fixed: tint:654
Change-Id: If2ba75d04ff0e2a9975e878596ac114d51adcd46
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/56580
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Sarah Mashayekhi <sarahmashay@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: James Price <jrprice@google.com>
Auto-Submit: Ben Clayton <bclayton@google.com>
Also remove the unreachanble constructor logic in EmitHandleVariable.
Variables of the handle storage class cannot have initializers.
Fixed: tint:173
Change-Id: I7c997a8b6a70308ff9b5c42fa1198810ee365bac
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/55258
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Instead of a ConstantBuffer.
HLSL requires that each structure field in a UBO is 16 byte aligned.
WGSL has much looser constraints with its UBO field alignment rules.
Instead generate an array of uint4 vectors, and index into this, much
like we index into [RW]ByteAddressBuffers for SSBOs.
Extend the DecomposeStorageAccess transform to support uniforms too.
This has been renamed to DecomposeMemoryAccess.
Change-Id: I3868ff80af1ab3b3dddfbf5b969724cb87ef0744
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/55246
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
This will be relied on by the upcoming arrayLength transform.
Update test expectations.
Change-Id: Ib74b647abcd6f4393f9899ce40bbf06f6e53e7f4
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/55180
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
- When storing to sample_mask output, write to the 0th element
- Only make a return struct if it has members
- Adjust type signedness coercion when loading special builtins.
- Adapt tests
- Update expectations for end-to-end tests
- Handle sample_mask with stride
Input variables normally don't have layout. But they can have it
up through SPIR-V 1.4.
Handle this case in the SPIR-V reader, by seeing through the
intermediate alias type created for the strided array type.
Bug: tint:508
Change-Id: I0f19dc1305d3f250dbbc0698a602288c34245274
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54743
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Combined with the new PadArrayElements transform, arrays with strides
are now correctly emitted.
Fixed: tint:182
Fixed: tint:895
Change-Id: I26a1be94dee6e4c9d9747c8317a932fc1fb3c810
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54640
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Replaces arrays with an explicit stride with an array to a structure holding the element padded with a `[[size]]` decoration.
Note that the HLSL writer is still not correctly emitting structure fields with a `[[size]]`, which will be fixed in a follow up change.
Bug: tint:182
Bug: tint:895
Fixed: tint:180
Fixed: tint:649
Change-Id: Ic135dfc89309ac805507e9f39392577c7f82d154
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54582
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Reviewed-by: James Price <jrprice@google.com>
Fixes issues with using arrays as function return types.
Fixed: tint:848
Change-Id: Iee8af0f2cea9d19e448176446c6599be2bd32316
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54321
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
And replace the MSL writer's logic to do this with the transform.
We need to do the same thing in HLSL, and in the future GLSL too.
Partially reverts fbfde720
Change-Id: Ie280e011bc3ded8e15ccacc0aeb12da3c2407389
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54242
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
And fix issues where global variables would not be emitted unless they were transitively referenced by an entry point.
This change requires crbug.com/tint/697 to be fixed before landing.
Change-Id: I712bd9d369e08c9a3cdfb0f114c3609584f91f28
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54241
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
arrayLength() will take a pointer to a storage buffer array.
This pointer may pass through function scoped let statements.
To make this intrinsic easier to generate, inline the pointer lets and
remove chains of &*&*.
Bug: tint:806
Change-Id: Ib2c79a9c38cba7391cbb4313986af9a72b0f0435
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54060
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
This also completes the work to resolve the access controls for each
storage type.
Fixed: tint:846
Change-Id: Iab24057ec14620a2978ec63c4a91ba12d1bc6e9b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/53381
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: James Price <jrprice@google.com>
Handle access control on var declarations instead of via [[access]]
decorations. This change does the minimal work to migrate the WGSL
parser over to the new syntax. Additional changes will be needed
to correctly generate defaulted access qualifiers, as well as
validating access usage.
The [[access]] decorations are still supported by the WGSL parser,
with new deprecated warnings, but not for aliases. Example:
var x : [[access(x)]] alias_to_struct;
Making this work is far more effort than I want to dedicate to backwards
compatibility, and I do not beleive any real-world usage will be doing
this.
Still TODO:
* Adding access control as the optional, third parameter to ptr<>.
* Calculating default accesses for the various storage types.
* Validating usage of variables against the different accesses.
Bug: tint:846
Change-Id: If8ca82e5d16ec319ecd01f9a2cafffd930963bde
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/53088
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: James Price <jrprice@google.com>
Reviewed-by: David Neto <dneto@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This allows them to be used in various places that WGSL allows, such
as function return types and parameters, and as the type of the RHS of
an assignment.
Fixed: tint:814
Fixed: tint:820
Change-Id: Idb6a901b9a34e96bb9733cc158191e7b3bafaa0e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/52844
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Pull the HLSL transformation out to a standalone transform that can be
used by both HLSL and MSL.
The new E2E tests do not yet pass for MSL because they produce array
assignments, which will be addressed in the next patch.
Fixed: tint:826
Change-Id: Idc27c81ad45e3d4ab96d82663927d2fc1384618e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/52842
Auto-Submit: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>