Internally use BlockAllocator to allocate the types.
When we optimize the allocation patterns of BlockAllocator, this will now benefit both AST nodes and types.
Remove Reset(). It was not used.
Remove type::Manager::Get(std::unique_ptr<type::Type>) - this was used (via Module::unique_type) in one place, which has easily been migrated to using the standard Module::create<>.
Replace all remaining uses of std::unique_ptr<> of types in tests with the standard create<> so we can guarantee uniqueness of the types.
Change-Id: Ib0e1fe94e492b31816450df5de0c839a0aefcb9e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38362
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
This separates out the usage of the built module from the construction of the module.
Previously, we'd happily interleave generator testing with module construction statements. Once the AST / Program is made immutable, this will no longer be possible.
Bug: tint:390
Change-Id: Ib4538228e93ca816f5bb796d024f021116609213
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38360
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Despite `tint::ast::type::Type` being in the AST namespace, these classes are clearly not AST nodes:
* They don't derive from ast::Node
* They're deduplicated by the type manager
* None of the types have an Source - they have no lexical declaration point
* The fact we have `ast::Struct` and `ast::type::Struct` clearly demonstrates what is an AST node, and what is a type.
* We have code scattered in the codebase (TypeDeterminer, writers, etc) that create new types after parsing - so clearly not part of the original syntax tree.
Types in tint are closer to being semantic info, but due to the parse-time generation of types, and tight dependency of ast::Nodes to types, I'd be reluctant to class these as semantic info. Instead, put these into a separate root level `tint::type` namespace and `src/tint` directory.
The fact that types exist in the ast::Module has already caused bugs (https://dawn-review.googlesource.com/c/tint/+/37261). This is a first step in separating out types from the ast::Module.
Bug: tint:390
Change-Id: I8349bbbd1b19597b8e6d51d5cda0890de46ecaec
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38002
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
A container and allocator of objects of (or deriving from) the template type `T`.
Objects are allocated by calling Create(), and are owned by the BlockAllocator.
When the BlockAllocator is destructed, all constructed objects are automatically destructed and freed.
Objects held by the BlockAllocator can be iterated over using a View or ConstView.
Use this to hold the ast::Nodes in the ast::Module
This is called BlockAllocator as it can be optimized to hold objects in contiguous memory blocks, which will improve cache coherencey. Currently BlockAllocator is a straight port of the vector-of-unique-ptr, taken from ast::Module.
Change-Id: I4bf4d298aec3c70d2ddf833e2f168416cbb024c0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38001
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
When building for Windows with VS2019 (using 'is_clang=false') with the
default "warnings as errors" this occurs multiple times, halting the
build:
../../third_party/tint/samples/main.cc(88): error C2220:
the following warning is treated as an error
../../third_party/tint/samples/main.cc(88): warning C4068:
unknown pragma 'clang'
Since there's no shared macro for marking potential unused params the
simplest route of a (void) cast is chosen.
Bug: dawn:602
Change-Id: I4e6316df97dc3cd7e45260e2f7471cdd5a9b4b94
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37700
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Checks that multiple texture_storage types with different access modifiers only produces a single OpTypeImage.
This was broken before Ia944ed8
Bug: tint:286
Change-Id: Idbcd0189d46b78b31d5ec38f355d2369cb86327a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37707
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
This CL removes the access control value from the storage textures and,
instead, wraps in an type::AccessControl. This matches the current spec
where the access is an annotation on the type as opposed to part of the
type.
Bug: tint:286
Change-Id: Ia944ed8557fbf490d78db2a1b49c31d0aba08728
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37740
Auto-Submit: dan sinclair <dsinclair@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Offset requires the ImageGatherExtended capability, where as ConstOffset does not. WGSL enforces the offset range required by SPIRV.
Bug: tint:143
Change-Id: Ia098010ecdb8a4a01999b4e9a6faabf3f4d1251f
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37447
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
All shader backend languages describe cubes as width / height, but give no way to query depth. WGSL however returns a vec3<i32> for cube textures when calling textureDimensions().
As cube textures must be square (width == height == depth), just replicate the height for the depth.
See https://github.com/gpuweb/gpuweb/issues/1345
Bug: tint:140
Bug: tint:437
Change-Id: I76ef18ee4bd8b53d5f9d9d3f1c10c3f7cb23e137
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37446
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
This CL reverts the changes to use the top level namer in the various
backends. This is causing issues when rolling into Dawn in the case
where the tint generator is used to create SPIR-V which is sent to
SPIRV-Cross but then generator and inspector aren't used. The entry
points end up being incorrect as SPIRV-Cross gets the renamed entry
points.
Change-Id: I4749e1d773f2bd9edcce83e63555f07a443d5ca5
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37342
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Currently Dawn may use the tint generator or the SPIRV-Cross generator.
In the case of SPIRV-Cross, we need to generate the SPIR-V with the
original names otherwise SPIRV-Cross won't be able to match up the entry
point name with the names in the shader.
Change-Id: Ica473030009b282fee352f2d1c1acc93f1db592c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37222
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
