This CL moves `ir::Bitcast` from `ir::Instruction` to `ir::Call`. The
`bitcast` is, essentially, a templated call instruction.
Bug: tint:1904
Change-Id: Iab8ccffaa484767318433f5fc6c33670c5f6375e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129940
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
The `discard` statement is, essentially, a function call. This CL moves
the `ir` node from being under `Instruction` to be under `Call`.
Bug: tint:1905
Change-Id: I8098dfc6047286b1c5249679139bcc83aa1cb21d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129681
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
type::Struct is the base class of sem::Struct.
type::Struct does not have a Declaration() member, so it does not make sense for it to have a Source.
Given that sem::Struct has a Declaration() method, use this to obtain the source.
Same logic applies to StructMember.
Change-Id: I693f659c35216ebe5eac5ea2a5b6457773077ddc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129480
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Ben Clayton <bclayton@google.com>
type::Struct does not have an ast::Struct declaration, so use that for
builtin structures.
Fix up logic that assumed sem::Struct for both user-declared and builtin
structures to use type::Struct instead.
Assert in the sem::Struct and sem::StructMember that the AST node is not
nullptr.
Change-Id: Ic8fcf27d5610c814ea3b504694c6a94db6cf1191
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129483
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Ben Clayton <bclayton@google.com>
Removes the need to examine AST attributes.
Change-Id: Iaaa6b10fd56baf732057c4c3960c1bfc5bbdeaa6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129621
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Attributes resolving was done ad-hoc throughout the resolver, with the
validator ensuring that attributes were only applied to the correct nodes.
The ad-hoc nature meant that attributes were inconsistently marked and
resolved, and the attribute arguments were not always validated
(especially when used internally).
This change inlines the attribute processing into the appropriate places
in the resolver, and uses a standardized error message for attributes
that cannot be applied.
Change-Id: Ic084820949bbf8276fb2d33c103fa29b77824a69
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129620
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
If an expression has a `sem::ValueExpression` attached we can use it to
directly obtain the result of the expression and stop emission. This Cl
updates the IR builder to pull the expression result if possible.
Several of the tests have been updated to go through a function in order
to stop const-eval from removing all the test content.
Bug: tint:1924
Change-Id: I6458cc297efc7789ac200069c18f75e8eb70c63b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129680
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
This CL does the following:
* Adds a "transient attachment" bit to texture usage. This bit
specifies that the created texture will be used only during
this render pass.
* Adds a TransientAttachments Feature that gates the usage of
transient attachments.
* Adds support for transient attachments on Metal, where they're
used to create textures as memoryless.
* Adds validation tests and an E2T test of the feature.
A followup CL will add support in Vulkan.
Bug: dawn:1695
Change-Id: I3c7322dd1e4bee113062aae2e0494d292ee8cbc3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129080
Commit-Queue: Colin Blundell <blundell@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Keyed mutex support was deprecated and the only known client using it,
Chromium, has migrated to fences. Remove all related keyed mutex related
code and tests. The useFenceSynchronization field is still present in
the external image descriptor since it's set by Chromium (to true) -
it'll be removed once Chromium stops setting it.
Bug: dawn:1612
Change-Id: Iaec3c16b18bb8ddbde55a7f54eaf4b944d0f06c6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129300
Reviewed-by: Austin Eng <enga@chromium.org>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
This CL removes the `ir::Runtime` and inherits `ir::Instruction` from
`ir::Value`. This means that any `Value` can be an `Instruction`. The
instruction id is used for debugging purposes.
Bug: tint:1895
Change-Id: I2b79cd6721268712d78a47d383a30f82aa3aa07e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129660
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
This CL moves the need to pull in SEM and AST into a specific
`libtint_ir_builder_src` library. This will make it a GN error if we
accidentally try to use the SEM or AST inside the IR after the initial
construction.
This required move the `ToProgram`/`FromProgram` methods out of
`ir::Module` and into an `ir::Converter` class.
Bug: tint:1921
Change-Id: I2e6ae195f9a100030b43f35a2c5dad634433147f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129661
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
This reverts commit f8ef5e95ac8ab6f8024aed26405bf25c6446c08e.
Reason for revert: Not the cause of flakes.
Original change's description:
> Disable SamplerTests on NVIDIA D3D11
>
> Suspect to be causing flakes in D3D12 sampler tests
>
> Bug: dawn:1779
> Change-Id: I7a8518683142191e05c7befed078d69abdaf9b77
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129280
> Reviewed-by: Loko Kung <lokokung@google.com>
> Kokoro: Kokoro <noreply+kokoro@google.com>
> Commit-Queue: Austin Eng <enga@chromium.org>
Change-Id: I72630f21d861acd9e266a0ac0c80e917f4f440bb
Bug: dawn:1779
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129600
Reviewed-by: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: Austin Eng <enga@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
This currently requires that we are not building with Chromium.
Bug: tint:1911
Change-Id: I6c37afe6c2b8250b30d244e8cc2274253b6ce8f6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129560
Commit-Queue: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Having labels like [CommandBuffer from CommandEncoder "B"] will
provide greater context when developers don't provide labels to
every tier of object.
Bug: dawn:1746
Change-Id: Ibf72f97e054ff943b33c210e457422466e46a013
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127120
Commit-Queue: Brandon Jones <bajones@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Allow the resolver to understand builtin structures, like
__frexp_result_f16. This allows backend transforms to declare the types,
even if they're "untypable" by the user.
Bug: chromium:1430309
Change-Id: I392709118182a058f737ccf1b7b46fc6b0b7264d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129482
Kokoro: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Contains the builtin structure creation logic moved out from
intrinsic_table.cc.
Bug: chromium:1430309
Change-Id: I2207f9ae42c6d7343c2f2ffa81effde59e6023fe
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129481
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Change-Id: I81ac6e70e086e1f5839733d2dd35c283ed6eba68
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128681
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
These tests seem to cause flakiness in other sampling tests on NVIDIA.
Bug: dawn:1779
Change-Id: Ide341033a4f13d8294021752ad3d18850a7369d6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129400
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This Cl renames the `instr` variables to `inst`.
Bug: tint:1718
Change-Id: Icf3b8c2f612c8dfe4b469d90327fef90ad813a0d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129460
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Change-Id: I77044ee7f0ce1b066dd8c8a1ee1b34e07f5e9766
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128660
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This fixes a linking problem.
The conversion function should be a member of the Convert class,
not a freestanding function.
Change-Id: Ifa351e4ba6fb0e95fed311a11e9dc56e13eb1a0b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129260
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Suspect to be causing flakes in D3D12 sampler tests
Bug: dawn:1779
Change-Id: I7a8518683142191e05c7befed078d69abdaf9b77
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129280
Reviewed-by: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
This CL adds Assignment and CompoundAssignment statements to the IR
builder.
Bug: tint:1718
Change-Id: I3037da0115c7f4fe68941565b7e48866d421bbbf
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129201
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
The const variables should all have been const-eval'd and turned into
`constants` at the usage sites. This CL updates the IR to skip constants
when emitting.
A TODO is added to validate they aren't used when identifier expressions
are supported.
Bug: tint:1718
Change-Id: I77328a0cbd3d7f6692d1d1057d6953fcf762cfd7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129240
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
This CL adds support for UnaryOpExpressions and converts them into Unary
instructions in the IR.
Bug: tint:1718
Change-Id: I736e29cec5e722b7c7f1b0f4f22ce55a3d3e4109
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129221
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
This CL updates the IR builder implementation to remove the `bool`
return values and use the diagnostics as the source of truth for if the
conversion works.
This requires disabling a couple tests as they depend on identifiers
which aren't implemented. Previously the `worked` because it would just
return an ID value that would be emitted, but now they end up being an
error.
Bug: tint:1718
Change-Id: I00bc8845393cf4fae7b3eb0f5cfffb8c5fc1dec0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129220
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
This CL adds support for discard into the IR. The `discard` statement is
handled as an instruction in the current block. The `discard` is a
`demote_to_helper` in WGSL so control flow has to continue after the
discard, it just predicates writes. So, an instruction seems like the
most logical way to express.
Bug: tint:1718
Change-Id: I0d2fb029631523d72a7811d0be0715732427c302
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129200
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
D3D11 requires that buffers are unmapped before being used in a copy.
Bug: dawn:1772
Change-Id: I58c6d587538836a6aa70abecd8a764fc50c1e9ec
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128740
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
When an OpConstantComposite result is used by multiple instructions,
declare it as a module-scope `const` instead of inlining the constant
at each use site. This fixes an issue whereby the spirv-reader was
massively inflating the size of the WGSL it produces, which was caught
via an OOM fuzzer bug.
Bug: oss-fuzz:57795
Change-Id: Iac8c6a2147a7e2ebfddbaacae9fcb1dbe0b59e9d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128881
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
Commit-Queue: David Neto <dneto@google.com>
This prevents us from crashing when a module-scope private variable
has an inferred type that is a built-in struct. We instead fail to
resolve the generated code.
Bug: chromium:1430309
Change-Id: I71c6eacf28096380227ed1043821ecc3d33ffb40
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129140
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
The declaration may be nullptr, so doing this avoids a potential
nullptr deref when the struct is an internal type (e.g. frexp
result). In these cases we will now fail to resolve the resulting
code, which is a little better than just crashing.
A future change will update the resolver to allow us to use the
internal struct names from our transforms.
Bug: chromium:1430309
Change-Id: Ic72b5105bf3159c448c20dd9228d73b25a632b69
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129120
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
This CL renames ir::Temp to ir::Runtime to better reflect that this is a
runtime generated ID.
Bug: tint:1718
Change-Id: I24edbe0e2e19303f50355117ec7cd4b5b8f45aef
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129100
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Whitebox tests call internal functions directly. However, when
implicit device synchronization feature is turned on, some of these
functions will expect that the device is already locked. Thus leading
to assertion failures.
So we need to disable the tests when this feature is turned on.
Bug: dawn:1662
Change-Id: I1d65b4779c933313b5835f1bddbc57703b3ced53
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127180
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Produce a meaningful error instead of just crashing.
Bug: oss-fuzz:55170
Change-Id: I09d94a910835839ce9407849446cf2928231a114
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128540
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: David Neto <dneto@google.com>
When `invariant` is enabled on MSL was was incorrectly setting
`@invariant` instead of `[[invariant]]`. We test with metal1.2 which
does not have invariant, so this only showed up when using metal2.1 or
higher.
Bug: chromium:1439273
Change-Id: Iab866608195e697b0370d465f350b25277d904a3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128880
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Normal behavior of ApiObjectBase's APIRelease() which only locks the
device when last ref dropped is not thread safe if the object is cached
as raw pointers by the device. Example of cached objects: bind group
layout, pipeline, sampler, shader module.
The following scenario could happen:
- thread A:
- shaderModuleA.APIRealease()
- shaderModuleA.refCount.Decrement() == true (ref count has reached zero)
- going to call shaderModuleA.LockAndDeleteThis().
- thread B:
- device.CreateShaderModule().
- lock()
- device.GetOrCreateShaderModule()
- shaderModuleA is in the cache, so return it.
- unlock()
- thread A:
- starting to call shaderModuleA.LockAndDeleteThis()
- lock()
- erase shaderModuleA from the cache.
- delete shaderModuleA.
- unlock()
This CL fixes this bug by locking the entire APIRelease() method until
we find a better solution.
Bug: dawn:1769
Change-Id: I1161af66fc24f3a7bafee22b9614b783e0dc4503
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128441
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
