Fixed: chromium:1312780
Change-Id: I29f13a2df3ef1db6961a5760a6c1bb05ab3fa89b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85680
Commit-Queue: Austin Eng <enga@chromium.org>
Auto-Submit: Austin Eng <enga@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
This removes a little bit of noise from the reflection of shader
metadata in Dawn. Tests are added to make sure that Tint does the
correct validation (it does).
Bug: None
Change-Id: I334e7c23b723cf5b5985c9914cc9f8d79a7c0568
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85502
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
A list of errors, `infringingLimits`, is added to EntryPointMetadata.
During shader reflection, instead of directly bubbling limit errors up,
they are stored in this list and check only later during pipeline
creation.
Several ShaderModule tests are reworked to create a pipeline to check
for the validation of these limits. For the IO variable limits the tests
needed to be reworked to check for strings in the error messages because
since IO structs have to match between VS and FS, if one failed the
other failed too. (so it's no possible to target the validation of one
of these in particular)
Bug: dawn:986
Change-Id: I689e16454488d4a3c746ece53828555ed72ed561
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85501
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
These are implemented by wrapping the integer types in transparent
ClampedInteger<> and EnforceRangeInteger<> structures.
Some parts of the core needed to be updated after this, either to
disambiguate conversions, or because of bugs (u32 vs u64).
To make the CTS tests checking for this pass, the errors returned when
conversion FromJS failed needed to be updated to TypeError and not just
the generic Napi::Error.
Bug: dawn:1123
Change-Id: Ife1d0baa7687e43d735a1814ec41883c49ae74a6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85640
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Queue labels can be set by the defaultQueue.label member of the device
descriptor or the setQueue method.
Device labels can be set label member of the device
descriptor or the setQueue method.
D3D12 and VK backend label support included.
Change-Id: Id12dd6e1fc8f1519c55e4efb35e1ead67c085e46
Bug: dawn:1323
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85540
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Brandon Jones <bajones@chromium.org>
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>
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>
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>
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>
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>
Disable the scissor test during clear.
Change-Id: Ia6945304c257867ed5cb6a6ae0c2c49998a33ca7
Bug: dawn:1340
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85143
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Addressing issues that showed up after the initial stencil8 CL landed.
D3D12:
- Selecting the `all` aspect of a `stencil8` texture was ASSERTing
Metal:
- Using the `stencil` aspect of a `stencil8` texture was hitting an
UNREACHABLE().
Bug: dawn:666
Change-Id: Ic2931dbb915e109727ca24e3216a661fba84e508
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85021
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Brandon Jones <bajones@chromium.org>
Change-Id: Iee67027431d791d6425e0cc502f6b6a23bc160d6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85141
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
glBlitFramebuffer() takes min and max coordinates, not min and size.
Bug: dawn:1084
Change-Id: I7b8b53ecd9c5ade20d4d7a909bd134c13a2d960b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85081
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Move texture allocation in an AllocateTexture() local.
Use the GL target to determine the choice of allocation call, not
the Dawn TextureDimension. This leaves TargetForTexture() and
TargetForTextureViewDimension() as the authorities on Dawn -> GL
conversion.
Change-Id: Ia31fbba9a8e71a9ce8dd9c89676dbc51d8848bb5
Bug: dawn:593
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85080
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
This simplifies reference management and make the swapchain's reentrant
code avoid APIEntryPoints.
Bug: dawn:723
Change-Id: I6c456b9ec349c73d783dbb12a284f322d0be4e1a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/84763
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
On D3D12 backend, external texture holds mD3D11on12Resource which caches
D3D11on12Resources and guarding by refptr. The texture will released this ref
until destructor works.
This model leaks the gpu memory if client fails to release all the ref to
the texture.
Instead, external texture also provides a method called "Destroy". It is
called more eagerly and means the external texture is in the end of lifecycle.
So thid CL moves the ref reset of D3D11on12Resource into Destroy(). This prevents
unexpected gpu memory leak caused by client missing ref release call.
Bug: 1308405
Change-Id: I253e1eda192256e4bd1c470e26dcc6af3c234447
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85000
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Shaobo Yan <shaobo.yan@intel.com>
And reject the device creation promise with an error that looks like an
OperationError to make the CTS happy.
Bug: dawn:1242
Change-Id: I43ec3ebc030cb4178520c9174e164a42b94f6bf8
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/85060
Reviewed-by: Brandon Jones <bajones@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Now the message will report the details of both the expected and
incompatible attachment states, helping developers see what the source
of the error was.
Bug: dawn:563
Change-Id: I58eea166cb2da634f0295fb4660c982f96c62a2d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/84940
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Brandon Jones <bajones@chromium.org>
External textures are handled purely in the frontend so there is no need
to update the backend BGL to handle them. The TODOs can just be removed.
Bug: dawn:728
Change-Id: I319cf2a79bdc06a1457f3ec5746b07b5d05eef62
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/84767
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
This CL supports wrapping multiplanar iosurface in wgpuTexture.
It also provides mechanism to create TextureView on each planes.
Bug:1307194
Change-Id: I5e82f47944fdea542abba097240c880628b1181f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/81482
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Shaobo Yan <shaobo.yan@intel.com>
Should help make a couple of previously ambiguous error messages clearer
for developers.
Bug: dawn:1259
Change-Id: I09a4598153d3340407c5a318dcf6be6d03efd2bd
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/84780
Commit-Queue: Brandon Jones <bajones@chromium.org>
Auto-Submit: Brandon Jones <bajones@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Change-Id: I6210b192c0676dacecc0d0b1026905b31e869d72
Bug: dawn:593
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/84440
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Corentin Wallez
Austin Eng
Brandon Jones
Loko Kung
Yunchao He
Jiawei Shao
Ryan Harrison
Antonio Maiorano
Stephen White
AlexVestin
Shaobo
Ben Clayton