This reverts commit 48183b8f58.
Reason for revert: Part of Dawn->Chromium breakage
BUG=dawn:950
Original change's description:
> Vulkan: honor bufferImageGranularity the simplest way.
>
> Vulkan requires that linear and opaque resources be placed in different
> "pages" of bufferImageGranularity size, as some hardware uses the page
> table to contain some compression bits or other stuff. Make Dawn honor
> this limit by aligning all allocations to bufferImageGranularity. This
> is pretty bad and should be improved later.
>
> Also does some cleanups:
> - Add kMappableBufferUsage to represent all mappable usages.
> - Remove the proxy function for resource management from
> vulkan::Device and call ResourceMemoryAllocator directly.
> - Use an enum to make the difference between mappable, linear and
> opaque resources.
>
> This issue was found while doing a change of the memory type selection
> in Vulkan, that started failing some unrelated tests on Nvidia. Without
> knowing the details of the HW or the driver it is really hard to write
> tests, except by copy-pasting a failing test. This is why there is no
> test added in this CL, and instead will rely on tests not failing with
> the follow-up CL.
>
> Bug: dawn:659
>
> Change-Id: Ib7c1f3f1949457e04ca8e23d212dc60af7046213
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/52920
> Commit-Queue: Corentin Wallez <cwallez@chromium.org>
> Reviewed-by: Austin Eng <enga@chromium.org>
TBR=cwallez@chromium.org,senorblanco@chromium.org,enga@chromium.org,dawn-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I133f6a44227819bf262ad2b6e8e9d0d7bfaaefaa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: dawn:659
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/55642
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Previously when comparing a "bestType" that's device-local with a
"current" that's non-device-local, the logic to favor device-local
memory would be skipped and the types compared on their size. This lead
to incorrect memory types selection on some configurations (where the
small device local heap was selected).
Bug: dawn:659
Change-Id: Ie764815082ebeef845b70077fe630df05bcdb92b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/39500
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Vulkan requires that linear and opaque resources be placed in different
"pages" of bufferImageGranularity size, as some hardware uses the page
table to contain some compression bits or other stuff. Make Dawn honor
this limit by aligning all allocations to bufferImageGranularity. This
is pretty bad and should be improved later.
Also does some cleanups:
- Add kMappableBufferUsage to represent all mappable usages.
- Remove the proxy function for resource management from
vulkan::Device and call ResourceMemoryAllocator directly.
- Use an enum to make the difference between mappable, linear and
opaque resources.
This issue was found while doing a change of the memory type selection
in Vulkan, that started failing some unrelated tests on Nvidia. Without
knowing the details of the HW or the driver it is really hard to write
tests, except by copy-pasting a failing test. This is why there is no
test added in this CL, and instead will rely on tests not failing with
the follow-up CL.
Bug: dawn:659
Change-Id: Ib7c1f3f1949457e04ca8e23d212dc60af7046213
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/52920
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Composite insert normally inserts a temporary variable.
But if the composite value is already a hoisted variable,
then reuse that instead. This avoids defining the same name twice.
Also add AddressOfIfNeeded and use it when processing the operand
of an OpCopyObject or when making a let-declaration. Only take the
address in these cases when the corresponding SPIR-V type is a
pointer.
Bug: tint:804
Change-Id: I44f4289a557db919d8f1805e187a9b2a95c1efe0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/55361
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
After adding some e2e tests for 3D texture T2T copy on non-zero mip
levels, it turns out that there is a bug in the e2e test itself.
The 3D texture copy splitter works well.
Bug: dawn:547
Change-Id: I51aef7aaca4caf9c86bfb0590eb0288d17731ba5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/55144
Commit-Queue: Yunchao He <yunchao.he@intel.com>
Reviewed-by: Jiawei Shao <jiawei.shao@intel.com>
Tint now matches the behavior of spirv-cross for shaders to use the
arrayLength builtin, and so needs a uniform buffer containing storage
buffer lengths to be passed to shaders that use this builtin.
Fixed: tint:256
Change-Id: Ib51cc4a3c6f7c2cdea867a23ed868d9d3740d734
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/55181
Auto-Submit: James Price <jrprice@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Remove special case handling of pointers and values related
to builtins SampleId, VertexIndex, and InstanceIndex.
These map to private variables with store type matching the
type stated in the SPIR-V code. There is no need to generate
special case code for user-written functions accessing those variables.
Therefore:
- Remove SkipReason enums associated with those builtin inputs
- Remove newly unreachable code.
Bug: tint:508
Change-Id: I22ea86d49e14f171a92863d9f02145606ad37683
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/55321
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: James Price <jrprice@google.com>
Auto-Submit: David Neto <dneto@google.com>
This CL adds the support ofwgpu::CopyTextureForBrowserOptions::alphaOps
for CopyTextureForBrowser(), which allows the user to specify the alpha
operations (DontChange, Premultiply, Unpremultiply) when calling
CopyTextureForBrowser().
BUG=chromium:1217153
Change-Id: Idb5dd4482b33f2ada9aafc24380afeb48f2e26bc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/54800
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Shaobo Yan <shaobo.yan@intel.com>
ShaderRobustnessPerf:
SPIRV-Cross apparently generates incorrect code for MSL and OpenGL, when
attempting to initialize workgroup memory. Disable these tests when not
running with use_tint_generator.
D3D12DescriptorHeapTest:
The UBO layout for a mat2x2 was incorrect, but the test relied upon this.
Temporarily disable the test so we can roll the fix.
Bug: dawn:945
Bug: dawn:946
Change-Id: I810249b26a8a0b583796c0ba63b8a703eb9540e4
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/55248
Auto-Submit: Ben Clayton <bclayton@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Generate a uniform buffer that will receive the lengths of all storage
buffers, and use this to implement calls to arrayLength(). The
transform is provided with a set of mappings from storage buffer
binding points to the corresponding index into the array of buffer
lengths. The transform reports whether it generated the uniform
buffers or not.
Use this transform from the MSL sanitizer, using the binding number as
the index into the array. This matches the behavior of spirv-cross,
and so works with how Dawn already produces this uniform buffer.
Bug: tint:256
Change-Id: I2682d2d024e8daa30f78270b8cfb6bbb32632133
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54480
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: James Price <jrprice@google.com>
Reviewed-by: 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>
If during clone, we register a type, function or global declaration, we could end up with the declaration held twice by the AST Module.
AST nodes must only be referenced once.
Change-Id: I5c517699ea80422800639088b97a50ba9ac27b70
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/55245
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Removing parsing support for the 'in' and 'out' storage classes is
enough to prevent anyone from using the old syntax. The Input and
Output storage classes will remain in the AST for now, as the SPIR-V
reader still has codepaths that use them, and the SPIR-V writer
currently still relies on them.
Bug: tint:697
Change-Id: Ifef9eda8bcbf2f243b1e1d8d4fab25784cd3f80e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54841
Auto-Submit: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: James Price <jrprice@google.com>
Storage buffers are emitted as `ByteAddressBuffer`s in HLSL, so we have to jump through hoops to support atomic ops on storage buffer atomics.
Workgroup atomics are far more conventional, but very little code can be shared between these two code paths.
Bug: tint:892
Change-Id: If10ea866e3b67a093e87aca689d34065fd49b705
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54651
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: David Neto <dneto@google.com>
After implementing validation and fairly exhaustive tests, discovered
that conversion of scalar vector to bool vector did not work in the
spir-v backend. For module scope variables, we use and rely on the
FoldConstants transform to ensure no conversion needs to take place.
This is necessary because we cannot easily introduce temporary values
and refer to them when casting at module scope. Note that for the same
reason, module-level conversions are always constant foldable, so this
works. For function-level conversions, implemented support to emit a
comparison against a zero value, and store the result in the bool
vector.
Bug: tint:865
Change-Id: I0528045e803f176e03428bc7eac31ae06920bbd7
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/54744
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Add the formatted tint messages in OwnedCompilationMessages, which will be emit after creating the shader module succeeds of fails.
This patch also change the compilation messages handling in creating shader modules. Now the compilation messages are separated from sparseResult, and should be handled manually. A new method, ShaderModuleBase::InjectCompilationMessages, is introduced to move a given OwnedCompilationMessages into the shader module, and emit the formatted tint errors and warnings. This method should be called explicitly on a valid or error shader module.
Bug: dawn:753
Change-Id: I5825186c6d9c4aa7725aebd0c302bfce5e1f37cf
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/53890
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Copies between 3D and 2DArray textures need to be done depth/array
slice by slice via CopyTextureRegion() API on D3D12 because this
API can copy one single subresource every time.
However, if both src and dst textures are 3D texture, we can copy
all depth slices in one shot, which is a fast path for this
copy scenario.
Bug: dawn:547
Change-Id: I950ed58319fb0f30dfc8a2de3e57e8a64406f7e4
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/55140
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jiawei Shao <jiawei.shao@intel.com>
