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>