When we do B2T or T2B copy from/to a buffer with paddings,
D3D12 may wrongly calculate the required buffer size.
For example, if copySize = {1, 1, 2}, offset = 0, bytesPerRow =
256, and rowsPerImage = 2 (there is 1-row padding for every image),
and we are copying a non-compressed format like rgba8unorm,
the required minimum buffer size should be:
offset + bytesPerRow * rowsPerImage * (copySize.depthOrArrayLayers - 1)
+ bytesPerRow * (copySize.height - 1) + bytesPerBlock * copySize.width.
It is 0 + 256 * 2 * (2 - 1) + 256 * (1 - 1) + 4 * 1 = 516.
The required minimum buffer on D3D12 (including WARP) size is:
offset + bytesPerRow * rowsPerImage * (copySize.depthOrArrayLayers - 1)
+ bytesPerRow * (rowsPerImage - 1) + bytesPerBlock * copySize.width.
Or offset + bytesPerRow * rowsPerImage * copySize.depthOrArrayLayers
+ bytesPerBlock * copySize.width - bytesPerRow.
It is 0 + 256 * 2 * (2 - 1) + 256 * (2 - 1) + 4 * 1 = 772.
It looks like D3D12 requires unnecessary buffer storage for
rowsPerImagePadding in the last image. It does respect
bytesPerRowPadding in the last row and doesn't require storage for
that part, though.
You can verify the buffer size requirement on D3D12 backend with the
new tests via --enable-backend-validation. The validation layer
says that D3D12 requires 772 bytes but we only provide a 516-bytes
buffer, and leads to E_INVALIDARG (Error code 0x80070057) when run
mD3d12CommandList->Close() in CommandRecordingContext::ExecuteCommandList
and causes device lost.
Bug: dawn:1278, dawn:1288, dawn:1289
Change-Id: Icfb792dec60ff7444cb20b3c283709cdb165f80a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85341
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Yunchao He <yunchao.he@intel.com>
This allows adding as an error context the name of the entry point, and
dedents the code a little bit.
Bug: dawn:563
Change-Id: I1ea9760fc1aca506826ca7ef5a65d40f8370136d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85500
Auto-Submit: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Brandon Jones <bajones@chromium.org>
The semantic of popErrorScope was changed from raising an exception on
validation errors to instead reject the promise.
Bug: dawn:1123
Bug: dawn:1324
Change-Id: I34322d8293e112eb2d1bfea784e2b2d6be33b604
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85506
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Provides a type to represent the CTS query strings.
100% test coverage.
Bug: dawn:1342
Change-Id: I3769b094ba64221a7b79dd38f76daf0125ee9e28
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85221
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Counts the size of expressions in the AST to avoid applying unary
wrapping to expressions that have already gotten large.
Change-Id: I0868d6f2bb3c6aaf99efdfb9574327d0af420456
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/84900
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Auto-Submit: Alastair Donaldson <afdx@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Alastair Donaldson <afdx@google.com>
This remove some interfaces like OffscreenCanvas from the global scope
because dawn.node is not capable to usefully create them. The CTS
uses the absence of these interfaces to skip tests when needed.
Bug: dawn:1123
Change-Id: I6d57600ba6b41be58c541d1f8091e7e88781f04f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85364
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Previously a new promise was created and new promises were never
resolved on creation, only on loss/destruction of the device. This made
the following code wait forever:
device.destroy();
await device.lost();
Bug: dawn:1123
Change-Id: I1e31cf9ccd466672eed4cad464c38cb9f8b3d724
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85362
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This is done by moving the set up of these attributes to the place where
the wrapper objects are created, by doing:
jsObject.DefineProperty("foo", impl->getOnceFoo());
Three alternatives that weren't chosen are:
- Caching a weak reference to the member's Napi::Value on the wrapper
struct, and recreate it only as needed. This is good because it
doesn't risk using the value after it is GCed, but it can result in
multiple calls to the getters, which could be unexpected (for example
for GPUDevice.lost in a follow-up CL).
- Caching a persistent reference to the member's Napi::Value on the
wrapper struct. This calls the getter once and doesn't risk using the
value after it is GCed. However if Javascript does something like
`myGPUDevice.limits.device = myGPUDevice`, a cycle is created that
the GC doesn't have visibility into, and that can't be collected.
(the origin of the edge of the reference graph that persistent
references make is unknown to the GC).
- Caching the member on a hidden variable of the JS object. I didn't
find a way to do this. The closest would have been to do
jsObject[Symbol(...)] = cachedValue but even symbols can be retrieved
with Object.getOwnPropertySymbols.
Bug: dawn:1123
Fixed: dawn:1144
Change-Id: I1bc82dd9d10be95bf2bdca73bdfb843bc556d2df
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85361
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Fix an assertion in SwitchCases that default case must be last in Switch().
Change-Id: I5ece5a20e22f8df607581373d1f0bb0bd44fb58b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85461
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Add a mutation that wraps an expression in a unary operator.
Valid unary operators depend on the type of the expression.
Fixes: tint:1111
Change-Id: If5a63c5da7e3c212acbec4e838d6542303e59481
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/62000
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: Alastair Donaldson <afdx@google.com>
Bug: dawn:549
Change-Id: Ie6b3ceb610b362adfed96a0982d7541002660809
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/84920
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Loko Kung <lokokung@google.com>
This patch sets depthWriteEnabled to its default value (false) in the
helper function DawnTest::ExpectAttachmentDepthStencilTestData() as all
the tests can pass with depthWriteEnabled == false on the Linux Intel
bots now.
Note that previously using depthWriteEnabled == false and writing into
FragDepth will cause Linux Intel Mesa driver crash on Mesa 19.0.2.
BUG=dawn:821
TEST=dawn_end2end_tests
Change-Id: I22cc0dcdb8521fd8eae436d99a7c06167af89b09
Change-Id: Id0dd1c31099c6aafad175bde038ba9662b02a160
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85322
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Use the ExpandCompoundAssignment transform to convert compound
assignments to regular assignments.
Bug: tint:1325
Change-Id: I0567131aa7c6b4beb6e25c0c6c559795e9c58c19
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85286
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Use the ExpandCompoundAssignment transform to convert compound
assignments to regular assignments.
Bug: tint:1325
Change-Id: I193a09815836755bc1f7138fe1947be39f7b7206
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85285
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: James Price <jrprice@google.com>
Use the ExpandCompoundAssignment transform to convert compound
assignments to regular assignments.
Bug: tint:1325
Change-Id: Ic843964ec24d8a2f00f801823f8f8bbf1c6fab5c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85284
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Use the ExpandCompoundAssignment transform to convert compound
assignments to regular assignments.
Bug: tint:1325
Change-Id: I960bf6cd0ec3490cd58685a7c13b6a7c86395080
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85283
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This transform converts compound assignment statements into regular
assignments, hoisting LHS expressions and converting for-loops and
else-if statements if necessary.
The vector-component case needs particular care, as we cannot take the
address of a vector component. We need to capture a pointer to the
whole vector and also the component index expression:
// Before
vector_array[foo()][bar()] *= 2.0;
// After:
let _vec = &vector_array[foo()];
let _idx = bar();
(*_vec)[_idx] = (*_vec)[_idx] * 2.0;
Bug: tint:1325
Change-Id: I8b9b31fc9ac4b3697f954100ceb4be24d063bca6
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85282
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This can be used to insert a new statement before an existing
statement, and will take care of converting for-loop and else-if
statements as necessary.
Change-Id: I5ef20f33cf36bb48ea5dabe1048c9d9b3c61b3ee
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85281
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Implemented in both the reader and writer with E2E tests. Other
backends detect compound assignment and ICE for now.
Bug: tint:1325
Change-Id: Ie3f51e03627a38b12bd1513c4bcf1bebb3282863
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/74363
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reuse the logic for resolving binary operator result types that was
implemented for binary expressions. This validates that the LHS and
RHS are compatible for the target operator. We then try to match the
resolved result type against the LHS store type.
Bug: tint:1325
Change-Id: If80a883079bb71fa6c4eb5545654279fefffacb4
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/74362
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This same logic will be used for resolving and validating compound
assignment statements, so pull the core out into a separate function
that decouples it from ast::BinaryExpression.
Bug: tint:1325
Change-Id: Ibdb5a7fc8153dac0dd7f9ae3d5164e23585068cd
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/74360
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This will ease rolling Dawn into Chromium, once Tint is merged in
BUG=dawn:1343
Change-Id: I53fa7b82a001ab3351f5366e8e045090c0fdb49b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85380
Auto-Submit: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Added a new transform::RemoveContinueInSwitch that replaces continue
statements in switch cases with setting a bool variable, and checking if
the variable is set after the switch to continue.
Bug: tint:1080
Change-Id: I3c0a6c790e1bb612fac3f927a4bd5beb2d0d4ed1
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/84960
Reviewed-by: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
The CMake file states c++17, Chromium is at c++17. This CL updates the
style guide documentation to specify c++17 as required for Tint.
Change-Id: I4dd8e9aa69de6f32a59ced2c5b861c83adf2edfe
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/85320
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Bug: dawn:549
Change-Id: I5d6306f33b7ad2247ee75a0c5387a2bc6fac0497
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/83901
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Loko Kung <lokokung@google.com>
Spec issue: https://github.com/gpuweb/gpuweb/issues/2715
Spec PR: https://github.com/gpuweb/gpuweb/pull/2716
This is invalid in the Metal API because MTLTextureType2DArray is
imcompatible with MTLTextureType2DMultisample, even if the layer
count is 1.
MTLTextureType2DMultisampleArray is not supported until macOS 10.14
and iOS 14.0.
Further, the view type must match between the API and the shader.
a 2D view array requires texture2d_array in MSL.
It would be inconsistent to allow 1-layer 2D arrays which internally
get translated as (non-array) MTLTextureType2DMultisample. You would
expect to need to use texture2d_ms_array in the shader.
Change-Id: Ib9268c1276d3d31e90d6c61118e27fa2afd0617d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85200
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
Loko Kung
Yunchao He
Austin Eng
Corentin Wallez
dawn-autoroll
Ben Clayton
Alastair Donaldson
Zhaoming Jiang
Shiyu Liu
Jiawei Shao
James Price
Ryan Harrison
Antonio Maiorano
dan sinclair