Change-Id: I6b8c109ae67e230fea3fb14511c2b3562191c0fa
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/132300
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
This introduces the notion of FeatureLevel, currently consisting of
Core or Compatibility. Each AdapterBase is now constructed with the
FeatureLevel it supports.
When discovering PhysicalDevices, create an AdapterBase for each of
the FeaturLevels which that PhysicalDevice supports. For most of the
backends, this will mean Core and Compatibility, while OpenGL and
D3D11 support only Compatibility.
Bug: dawn:1796.
Change-Id: I828247ef43e2220805ccf6c08827aa5e2382a026
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/118240
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Stephen White <senorblanco@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
The problem is becasue a resource can not be set as input and
output at same time on device context. So we have to track used
slots and unset related slots before binding a group.
This CL also unset all affect slots when a render pass or compute
pass is end, so all related resources could be unref from the
device context.
Bug: dawn:1705
Change-Id: I597762ad8afa3b8df7139b0070f0b457d7319836
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/131380
Commit-Queue: Peng Huang <penghuang@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This CL fix an issue related to tiering the maxBufferSize and
maxStorageBufferBindingSize limits. In detail, this CL:
1. Fix the maxStorageBufferBindingSize tiers to [128MB, 1GB, 2GB-4,
4GB-4] instead of the original last two 2GB-1 and 4GB-1, holding the
guarantee that maxStorageBufferBindingSize is a multiple of 4 bytes.
2. Add a maxBufferSize tier 4GB, ensuring the guarantee that
maxStorageBufferBindingSize must be no larger than maxBufferSize in
case of it tiered to 4GB-4. Previously the largest maxBufferSize tier
is 2GB, making this guarantee broken after tiering.
3. Move the adapter limits normalization logics in adapter initializing
to Limits.cpp to allow unittest. Related unittests implemented.
4. Normalize tiered limits to ensure that tiered
maxStorageBufferBindingSize and maxUniformBufferBindingSize are no
larger than tiered maxBufferSize. Related unittests implemented.
Issue: dawn:1780
Change-Id: I4821f196fa89c7f18ebbf8e5e45df1c3268db895
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/130120
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
- Note unsafe API paths currently check both AllowUnsafeAPIs and
DisallowUnsafeAPIs toggle, allowing unsafe APIs if either is set to
explicitly allow them. This will be removed once users have been
updated.
Bug: dawn:1685
Change-Id: If322cc6dbe5ac3a02a31956df6fed0f5d3ec8e8f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/131400
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Loko Kung <lokokung@google.com>
This CL raises "mapping already pending", "offset out of range", and
"size out of range", and "validation error" error to make it easier
for developers to know why APIMapAsync fail in those cases.
Bug: chromium:1431622
Change-Id: I6f04751b2d67420a51d94aeac39ffbfd6e126fbf
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129740
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Fr <beaufort.francois@gmail.com>
Reviewed-by: Austin Eng <enga@chromium.org>
- Adds a deprecation warning for the incorrect usage.
- Adds test to verify that the warning is emitted and that the results
are equal.
- Fixes all existing tests to use the newer code path.
Change-Id: I01bf85137ad1c66966e1aa0259ae03fc5247ba25
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/130320
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Change AdapterBase from an alias to PhysicalDeviceBase to a thin
wrapper class holding a ref to a PhysicalDeviceBase. This way,
mutiple AdapterBases can point at the same PhysicalDeviceBase.
For now, InstanceBase wraps all PhysicalDeviceBases discovered by a
backend in a single AdapterBase. In the future, this relationship will
become many-to-one.
Since Devices now maintain a ref on the AdapterBase wrapper (in order to
query toggles, etc), PhysicalDeviceBase::CreateDeviceImpl() now takes
the AdapterBase as an argument, so that the PhysicalDeviceBase knows
which AdapterBase to vend a Device for.
Note that the Toggles also still remain on the PhysicalDeviceBase, to
be moved up to the AdapterBase in a future change.
Bug: dawn:1774
Change-Id: Idef5d24fbd66d8552959230e246e453abddcc736
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/131001
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
In case of misalignment, we write to a temp staging buffer first,
and then copy to the dest buffer using CopySubresourceRegion.
Bug: dawn:1776
Bug: dawn:1705
Change-Id: Iba44dd79d9ee4b02f8cc83263bcfc911e1cce136
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/130140
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Jie A Chen <jie.a.chen@intel.com>
- Note: Any future deprecations should directly use
device->EmitDeprecationWarning and switch to a ValidationError after
the deprecation period if applicable.
Bug: dawn:1685
Change-Id: Ia2e51eca32a9645ce362718200c50240d51d6ea0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/130840
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Set Toggle::ApplyClearBigIntegerColorValueWithDraw for device,
since D3D11 can only clear RTV with float values. It workarounds
issues for clearing some RTV with really big integer values.
Bug: dawn:1705
Change-Id: I2e7ec7f527b9a41edc28a004f7989842c6ced3b7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/130600
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Peng Huang <penghuang@chromium.org>
AdapterBase will become a (thin) wrapper class in an upcoming patch,
allowing a single PhysicalDeviceBase to be wrapped in multiple AdapterBases,
each with different toggles and flags.
For now, alias AdapterBase to PhysicalDeviceBase.
Design doc: https://docs.google.com/document/d/1Ag3UAD6D1OVt9-MwKltzLefVhwKRdX0RqML2etrYVS4/edit
Change-Id: Ie77e99508be5285b651aa24ccb412bc9ff8b0111
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/130300
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
To make B2B, B2T and T2B testes work, this CL implements several
missed functions:
- Texture::Clear() is need for initializing texture data
- Texture::Read() is need for readback data from 2d and 3d textures
Bug: dawn:1740,dawn:1768
Change-Id: Ib9e354c82fcdc8cc4e86b1699fa652cfc4a50721
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128621
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Peng Huang <penghuang@chromium.org>
The cases can pass now with a few fixes.
Bug: dawn:1776
Bug: dawn:1705
Change-Id: I4a38887c51d003b4e9b782fd9217c9ce2c7dd423
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128980
Commit-Queue: Jie A Chen <jie.a.chen@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
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 reverts commit f8ef5e95ac.
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>
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>
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>
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>
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>
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>
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>
- Note that by default these are already errors, not warnings.
Change-Id: If35284041963cd387839fe102efe4dca73e594dc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128064
Reviewed-by: Shrek Shao <shrekshao@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
BufferBase uses a staging buffer to upload data for non-mappable
buffer created with mappedAtCreation. However BufferBase doesn't
unmap staging buffer before copy data from it. But d3d11 debug
layer complain this illegal usage. It causes test failures.
Bug: dawn:1772
Change-Id: Id1c386ac7c45f41487f9cc7ef4e431eab87ba1c2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128480
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
- Note that by default these are already errors, not warnings.
Change-Id: Iab9ecf3cfd54c0219777c2d1587a7752c3173595
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128102
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Shrek Shao <shrekshao@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
- Note that by default these are already errors, not warnings.
Change-Id: I46afa6e54e7915ba54aa6990cd641288609108c1
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128101
Reviewed-by: Shrek Shao <shrekshao@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
- Note that by default these are already errors, not warnings.
Change-Id: I4eadbb6f71b2d2a39efe5755dbb6b8c329f1674f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128063
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Shrek Shao <shrekshao@google.com>
- Note that by default these are already errors, not warnings.
Change-Id: I33202a0cca8167c4c79e4aeee680b6b7cf1ff830
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128062
Reviewed-by: Shrek Shao <shrekshao@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This reverts commit 8cc6205bf7.
Reason for revert: Graphite actually reuses the bind groups between
draw calls using different pipelines and this change prevents it
from happening.
Original change's description:
> Disable frontend cache when implicit device sync is on.
>
> 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 disables caching when ImplicitDeviceSynchronization is turned on
> until we find a better solution.
>
> Bug: dawn:1769
> Change-Id: Ideb2a717ece0a40e18bd1c2bef00817262bd25da
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127900
> Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
> Reviewed-by: Austin Eng <enga@chromium.org>
> Kokoro: Kokoro <noreply+kokoro@google.com>
TBR=cwallez@chromium.org,enga@chromium.org,noreply+kokoro@google.com,dawn-scoped@luci-project-accounts.iam.gserviceaccount.com,lehoangquyen@chromium.org
Change-Id: Ib13bba8005402d06963865fae919388a91e718f0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: dawn:1769
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128440
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
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 disables caching when ImplicitDeviceSynchronization is turned on
until we find a better solution.
Bug: dawn:1769
Change-Id: Ideb2a717ece0a40e18bd1c2bef00817262bd25da
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127900
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This method will return supported usage flags that can be used to create
a swap chain.
Bug: dawn:1760
Change-Id: I7699c2c4ef7142c6bd06e72239d6e4f9112f15a3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127440
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This CL consolidates the unicode code into utils. These are utility
libraries, so the extra namespace doesn't add much.
Change-Id: Id0de612b6be036392a3cb018bfe66733f2f1ebcb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127403
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Add alphaToCoverage validation regards to targets[0] has alpha channel.
This change reflecting WebGPU V1 spec update is aimed to ship together
with WebGPU in Chromium.
Bug: dawn:1759
Change-Id: I0aef60cf8c4dc828e05d6027644ffed35b33f652
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128061
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Auto-Submit: Shrek Shao <shrekshao@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Don't skip the TruncateInterstageVariables transform when
user defined interstage attribute input for fragment stage
is empty. Because builtin inputs could also cause register
mismatch for D3D12 HLSL compiler.
Add a boolean flag to Tint hlsl generator option to indicate
whether to run TruncateInterstageVariables or not.
This defaults to false in Tint, while Dawn always set
this to true for vertex stage.
Bug: dawn:1733
Change-Id: Ie4c3648b226513bf15f0e03ae4ce7f3cc09fdef4
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127206
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Shrek Shao <shrekshao@google.com>
The initial test tests bind group layout creation of
different sizes, cache / no-cache hit, with and without
multiple threads.
Change-Id: Ic9ed6c6f1c298d35cd1358c7ff492027c83649a7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127346
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This CL enable build d3d11 by default, if dawn is not build with
chromium. d3d11 backend is not full implemented yet, so no tests
will run against d3d11 backend.
Bug: dawn:1705
Change-Id: Id689ab5168511af0f75f0b3537f246713de5ca45
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127260
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
This reverts commit 3fcf96dd8c.
Reason for revert: want to enable end2end test piece by piece on bots for d3d11
Original change's description:
> d3d11: add d3d11 backend in end2end tests
>
> Right now, many tests are not passed becasue unimplemented
> features in d3d11 backend. HoweverD3D11 backend is disabled on
> bots by default, so this CL will not break out bots.
>
> Bug: dawn:1705
> Change-Id: I57321b86a404bc245b71c467479fdee0464dee9b
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/126260
> Commit-Queue: Peng Huang <penghuang@chromium.org>
> Reviewed-by: Austin Eng <enga@chromium.org>
> Kokoro: Kokoro <noreply+kokoro@google.com>
Bug: dawn:1705
Change-Id: I95a1cc9a0962b01a6b31ea32b6129f109f4b3e42
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127240
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
This option will allow tests to be run with
ImplicitiDeviceSynchronization feature.
Bug: dawn:1662
Change-Id: Ic001b2fa175f63e8d77eeb3b23d4d2cf52bb224e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/126580
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
1. Auto-generate mutex locking code in DawnNative's ProcTable's
functions. Using a mutex owned by the related Device.
- Unless the function/class has "no autolock" attribute (new) in
dawn.json. In which cases, no locking code will be auto-generated.
- Currently Instance, Adapter, Surface, Encoder classes and
Reference/Release method have "no autolock".
2. Added Feature::ImplicitDeviceSynchronization to enable Device's
mutex.
- If this feature is disabled, lock/unlock Device's mutex is no-op.
Auto-generated locking code will have no effect. This is the default.
- This approach is used instead of generating two sets of ProcTable
because it's cleaner and the internal code doesn't need to care about
whether there is a mutex being locked or not. Furthermore, if there
were two sets of ProcTable, and user used dawnProcSetProcs() to set
global ProcTable, it would affect all other modules using different
Devices. Even though those modules don't need thread safety.
Bug: dawn:1662
Change-Id: I75f0d28959f333318e4159916b259131581f79f5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/119940
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
With the wire, callbacks reference device-related data which is
freed when the device is unregistered from the wire. However,
the device that the wire refers to can live longer than this
and have its callbacks invoked at a later time, leading to a
use-after-free. Always flush the callbacks so that when the
wire unregisters a device and clears its callbacks, they are
called immediately and no dangling pointers remain.
Bug: chromium:1430221
Change-Id: Ib753b58cee5e7cb4d90ebd703958a0ddd5873573
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/126481
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Right now, many tests are not passed becasue unimplemented
features in d3d11 backend. HoweverD3D11 backend is disabled on
bots by default, so this CL will not break out bots.
Bug: dawn:1705
Change-Id: I57321b86a404bc245b71c467479fdee0464dee9b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/126260
Commit-Queue: Peng Huang <penghuang@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
InstanceBase has two seperate ref counts: external & internal.
When we return it to the external user, we need to increase external
ref count as well.
Bug: chromium:1429835
Change-Id: I4b585d04149180418bd620e6e4d86522e033b64e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/126080
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
CopyExternalTextureForBrowser() uses external texture visible rect
as source size in previous.
But video frame natural size is the only one developer could get
from HTMLVideoElement and it means the size browser present video
on screen.
This CL add "natural size" in imageCopyExternalTexture and uses this
size as CopyExternalTextureForBrowser() source size.
Bug:dawn:1694
Change-Id: I2a3bfa8e689df11d1d13320d40ad02c7090425e5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/123380
Commit-Queue: Shaobo Yan <shaobo.yan@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
When InstanceBase::ProcessEvents() iterates through list of devices, one
device might be being destructed on another thread. Even if we try to
increase ref count of that device inside the ProcessEvents(), the device
might be in the middle of destructor call on another thread, increasing
the ref count is invalid in this case.
This CL attempts to fix this issue by removing the device's pointer
from InstanceBase earlier: when DeviceBase::WillDropLastExternalRef()
is called. After this point, any callback registered to this device will
be forwarded to InstanceBase's callback queue instead.
Bug: dawn:752
Change-Id: I8ae86575e34f753e52a76f5fc774bbb5366a1b85
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/124281
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
This was fixed a while ago in
https://dawn-review.googlesource.com/c/dawn/+/48320
which filled the resolve buffer with 0 and only
resolved the available queries.
Bug: dawn:973
Change-Id: Icf6f83eeca65507ba3e6dda9e9f910d684465622
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/125140
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Auto-Submit: Austin Eng <enga@chromium.org>
This CL enable using f16 override, and also fix related tests in Dawn
and Tint.
Bug: tint:1473, tint:1502
Change-Id: I8336770e8a73e5023c1aba224b7b5f21692fbaa6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/124544
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Fixes a bug where Dawn incorrectly did not re-apply state
when transitioning between compute and render passes. If
a compute and render pipeline share the same pipeline layout,
all of the resources for the graphics pipeline need to be rebound
since the graphics state in D3D12 is disjoint from the compute
state.
Fixed: dawn:1689
Change-Id: I7d25a1c7954039c4130e67b682ebc05324353e9a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/124540
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
This CL make adapter base holds it supported features set as private
instead of protected and provide a method to set features enabled. This
CL also rename SetSupportedFeatures in null adapter to
SetSupportedFeaturesForTesting.
This is a pre-CL for implementing UseDXC as instance toggle, which may
require further refactor and adapter features logic to handle the toggles.
Bug: dawn:1495
Change-Id: I0a07e5653b43f18278cb4a2fe90985cc90b66068
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/124421
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
In most backends, MultiplanarExternalTexture must run before the
BindingRemapper. The exception is the Vulkan SPIR-V backend where
it has to run before Multiplanar. This CL moves both of the transforms
to backend transforms and sets up the ordering as needed in the
generators.
Bug: tint:1855 chromium:1421379
Change-Id: I8223bce40babe901fe08bb1e8f033243837d7b18
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/123522
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Since https://dawn-review.googlesource.com/c/dawn/+/120940, callbacks
will be deferred to be executed in next device.APITick() instead of
immediately.
However, if the device is already destroyed (last ref dropped),
user/wire_server has no chance to call device.APITick() anymore, leading
to the callbacks waiting in queue forever.
This is also possibly the cause of memory leaks in cluserfuzz tests.
This CL attempt to fix it by implementing Instance::ProcessEvents():
In this method, every created device will invoke APITick() even if it is
already lost/externally released.
bug: chromium:1422507
bug: dawn:752
Change-Id: Iec69ad3b547a7e88c6e1a2225b13ad060a501a4f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/123420
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
The Vulkan spec mandates the use of a fragment shader unless
rasterizer discard is enabled. For now, enable the placeholder
fragment shader in all cases, with a bug logged to optimize it
for the rasterizer discard case.
Bug: dawn:1696 dawn:1698
Change-Id: I9e85e6308a9952fc505382488c618897bd9abc7b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/123503
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Bug: dawn:1696
Change-Id: Ie14e3d124342228edef17a122f380e2bdfaf1e57
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/123502
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Auto-Submit: Stephen White <senorblanco@chromium.org>
Reviewed-by: dan sinclair <dsinclair@google.com>
- Adds an e2e test to test writing to outputs when at the limit.
Bug: dawn:1665
Change-Id: I2b2b9c2d700be0e454dc945ed8e3e1fe6b191974
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/122801
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Loko Kung <lokokung@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
This replicates a subset of the flow control CTS tests. The purpose of
this is to provide relatively easy-to-repro cases to demonstrate flow
control bugs on Intel Graphics UHD 630 GPUs.
Bug: tint:1868
Change-Id: I34d692230b44d8a0a917dc773cc748bbf288d55a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/122940
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
This CL moves the `using` statement for `BindingPoint` out to its own
file in `src/tint/writer/binding_point.h`. Usages of
`tint::transform::BindingPoint` have been updated to
`tint::writer::BindingPoint`.
Bug: tint:1855
Change-Id: Ife7d92807e0a65b93f21158d73a60d5068fc5da9
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/123000
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
- Suppresses maxStorageTexturesPerShaderStage CTS test because it needs
to be modified to adhere to the new limit as well.
Bug: dawn:1665
Change-Id: I66c62bd94b613059633888210ec7e7b42dc3a1dc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/122461
Commit-Queue: Loko Kung <lokokung@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This CL add Instance and Adapter toggle stage, and promote
DisallowUnsafeAPIs as an instance toggle, and can be required using
DawnTogglesDescriptor chained in instance descriptor when creating
instance. The instance's toggles state will get inherited to adapters
and devices it create. Related tests are implemented and updated.
Toggles inheritance can be overriden if not forced, so requiring
DisallowUnsafeAPIs when creating device is still available and working
like before.
Note that currently we don't have toggle of adapter stage, and can not
require toggles when creating adapter, until follow up CLs implement it.
Currently the toggles state of a adapter is simply inherited from
instance.
Bug: dawn:1495
Change-Id: I6bf7aa0f950a99451afcc2cab5322c924b7d9520
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/122021
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
There are some scenarios where buffers can be used in pending
commands that are not retained by a command buffer.
They must be retained in the set of mappable buffers for eager
transition to prevent a use-after-free violation.
Fixed: chromium:1421170
Change-Id: I452d80b2513a7726a003d44e2a7850292d798bb1
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/122580
Auto-Submit: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Loko Kung <lokokung@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Peng Huang <penghuang@chromium.org>
Currently in the middle of some functions, we execute callbacks
immediately such as inside Buffer::APIMapAsync(), Device::HandleError()
or Queue::Submit().
Firstly, this has risks. The functions might be in a middle of modifying
internal states. By triggering callbacks, users might call API
functions again which could further modify the internal states
unexpectedly or access the states in an inconsistent way.
Secondly, upcoming thread safe API which locks the public functions with
a mutex might encounter deadlock. Because callbacks might cause
re-entrances which would unexpectedly lock the public function again.
This CL attempts to limit number of functions that are allowed to
trigger callbacks. Other functions that want to trigger callbacks will
instead enqueue a request to execute callbacks in the next
Device::APITick() call.
Currently the functions that will be allowed to trigger callbacks are:
- Device::WillDropLastExternalRef()
- Device::APITick()
- Device::APISetLoggingCallback()
- Device::APISetUncapturedErrorCallback()
- Device::APISetDeviceLostCallback()
Bug: dawn:1672
Change-Id: Iabca00f1b6f8f69eb5e966ffaa43dda5ae20fa8b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/120940
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Austin Eng
jchen10
Peng Huang
Stephen White
Loko Kung
Zhaoming Jiang
François Beaufort
Colin Blundell
Sunny Sachanandani
Takahiro
Le Hoang Quyen
dan sinclair
Shrek Shao
Corentin Wallez
Yan,Shaobo
Antonio Maiorano
Marshall Greenblatt