This change adds more tests to exercise the code of the workaround for
array texture corruption issue. Because texture memory layout and tile
alignment vary accordingly if array textures have mipmaps, and/or
different dimensions, etc.
It also does some slight changes in the workaround itself for array
textures with non-32-or-16-bit-wise formats.
Bug: dawn: 949, dawn: 1507
Change-Id: I22e87830ba59f2a2814e6786aa9a1a55a15c95cb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/105241
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Yunchao He <yunchao.he@intel.com>
This CL add a `Backend::IsDXCAvailable` method that check not only the
DXC binary is available but also its version is no older than a given
minimum version, and use this function to replace all previous
`PlatformFunctions::IsDXCAvailable` to ensure that we always check the
DXC version. By giving the minimum version 1.4, this CL also forbid
using DXC older than 1.4.
Issue: tint:1719
Change-Id: I6ab0a3791ac734c4e8b13570c55194573f111e61
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/105900
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
The D3D12 fence share handle should be closed when the device is
deleted.
A future change will make it valid to call EndAccess after the device
is destroyed, thus the handle is closed in ~Device instead of
Device::DestroyImpl. It needs to live as long as ExternalImageDXGI
holds a reference onto the device.
Bug: chromium:1359106
Change-Id: Ib9c9aaa7fb0b5a3de035b512f8fc0316d4bd225e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/104540
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
In D3D12, objects need to be kept alive until they're done being used on
the GPU. This is particularly important for wait fences imported into
Dawn otherwise the waits don't happen sometimes.
Bug: dawn:576
Change-Id: Id2d8af59f1530a1e507471cf2e4653ac5cfbae06
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/104425
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
This change works around the array texture corruption issue for
some Windows Intel devices on some old drivers. The number of
extra layer for a given texture is precisely calculated according
to texture memory layout on these devices.
It also adds one more test: clearTexture.
Bug: dawn:949, dawn:1507
Change-Id: I0b2a6497c77f3edf45c49220517e13be76c6b608
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/103120
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Yunchao He <yunchao.he@intel.com>
Calling ID3D12SharingContract::Present issues GPU work on the command
queue which needs to be synchronized with resource deallocation. This
seems to work now perhaps due to the keyed mutex semantics keeping the
D3D11 texture alive for longer than necessary. With fences, this missing
synchronization causes the validation layers to complain about early
deallocation of the ID3D12Resource.
Moving the Present to SynchronizeImportTextureBeforeUse ensures that it
happens before NextSerial and hence the signal fence that's recorded
will include any GPU work issued by Present. Also, resource deallocation
will happen after this work. However, this has the side-effect of PIX
seeing more frames, once per ExecuteCommandLists, but it could be argued
that's more accurate and useful.
Bug: dawn:1544
Change-Id: I1b417049045a812837f67072d7f09ac47bc18125
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/103841
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
The previous driver version I got from Intel driver team is
not correct. That driver does contain the fix but it is not the
first version with the fix.
Bug: dawn:949, dawn:1507
Change-Id: I0044a181e4266b50f77734bbbf9cc8755a8334d9
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/103502
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Yunchao He <yunchao.he@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reverts to the code flow before fences were implemented. NextSerial is
now the reponsibility of the caller of ExecutePendingCommandContext like
it was before. We now use GetPendingCommandSerial to store the signal
fence value instead of GetLastSubmittedCommandSerial and check that the
signal fence value was submitted in EndAccess.
Bug: dawn:576
Change-Id: I616840a0932ec17f77fcab38058773006dfae32f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/103501
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Implement "rg11b10ufloat-renderable" feature that allows
the RENDER_ATTACHMENT usage on textures with format
"rg11b10ufloat", and also allows textures of that format
to be multisampled.
Bug: dawn:1518
Change-Id: I4109dc0e9d90f4c0803219292edea554927a187a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/102000
Commit-Queue: Takahiro <hogehoge@gachapin.jp>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
This patch replaces NULL with nullptr as nullptr is preferred as null
pointers in Chromium coding style.
Bug: None
Change-Id: Ie6ab9d606d791bad2c50001815062c22e9ec0d25
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/102102
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
As we are using SubstituteOverride, it is easy to add
overridable constants support for OpenGL/OpenGLES.
Also add validate workgroup size for null backend.
Bug: dawn:1537, dawn:1504
Change-Id: I293f10b9a6c606aee6c0ed25b1d966bc56a0b88d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/101800
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Shrek Shao <shrekshao@google.com>
This CL modifies the way adapter creating devices, adds `shader-f16`
feature, and deprecates the `dawn-shader-float16` feature which is no
longer used.
Details:
1. Parse the toggles chained with device descriptor in
`adapter::CreateDeviceInternal`, which are then used to validate
features requirement within `CreateDeviceInternal` and passed to device
constructor as initializer.
2. When creating device, validate features requirement in
`CreateDeviceInternal` with toggles known, make sure to fail the device
creation if a required feature is not supported by adapter or is guarded
by certain toggles which were not enabled/disabled. Feature ShaderF16
and ChromiumExperimentalDp4a are validated in this way. Unittest is
added to check creating devices with toggles-guarded features required.
3. Add `shader-f16` feature, which allow `using f16;` in WGSL code.
End-to-end tests are added to test a trival f16 WGSL shader could be
used if and only if the device has `shader-f16` feature.
4. Deprecate the `dawn-shader-float16` feature, which will be completely
removed after cleaning up Blink code.
Bug: dawn:1510
Change-Id: I6cb2dcbe1ee584fdd6131c62df1ee850b881dbd2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/100802
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Zhaoming Jiang <zhaoming.jiang@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Remove the old backend specific implementation for
overrides. Use tint SubstituteOverride transform to replace
overrides with const expressions and use the updated program
at pipeline creation time.
This CL also adds support for overrides used as workgroup size
and related tests. Workgroup size validation now happens
in backend code and at compute pipeline creation time.
Bug: dawn:1504
Change-Id: I7df1fe9c3e358caa23235eacd6d13ba0b2998aec
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/99821
Commit-Queue: Shrek Shao <shrekshao@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
To support concurrent readers on multiple command queues/devices, Dawn
must support importing via wait multiple fences and also export a signal
fence. The previous implementation of using a single fence for waiting
and signaling doesn't work for concurrent reads across queues.
This CL adds support for specifying multiple wait fences for
ExternalImageDXGI via a BeginAccess method that's meant to replace
ProduceTexture. There's also an EndAccess method that returns a signal
fence for the client.
For performance reasons, we use the same fence as the signal fence that
the Device uses internally, and record its value on the texture after
ExecuteCommandLists. Therefore, the CL also makes the Device's internal
fence a shared fence so that we can export it to the client.
This CL also expands the ConcurrentExternalImageReadAccess test so that
it tests fence synchronization across multiple devices. A number of test
helpers also now take an optional device parameter so that we can use
pixel value expectations with secondary devices.
Bug: dawn:576
Change-Id: I6bc86808ede9b5aacf87667106cbd16731a12516
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/99746
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This patch disables Toggle::D3D12DontSetClearValueOnDepthTextureCreation
on Intel Gen11 GPUs as we find it not needed after further tests.
Bug: dawn:1487
Test: dawn_end2end_tests
Change-Id: I2c378568328b758e83484cff514073b052cf5004
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/101300
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Done with changes to Error.h and the following command:
git grep -l DAWN_FORMAT_VALIDATION_ERROR | xargs sed -i "" "s/DAWN_FORMAT_VALIDATION_ERROR/DAWN_VALIDATION_ERROR/"
then fixing compilation errors in ErrorTests.cpp, Pipeline.cpp and
CommandEncoder.cpp.
Bug: dawn:563
Change-Id: I081a514d662e81f4842b6d7fadfcea67c12720d6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/100468
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Before destroying ExternalImageDXGI we should execute all the pending
commands before calling NextSerial(), or the device will be lost as
the CommandAllocator will be destroyed before the pending commands are
executed.
Bug: dawn:576
Test: dawn_end2end_tests
Change-Id: I6e291586cd78a7e0feaf2f8dfee87a289ec27f77
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/100100
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
ExternalImageDXGIImpl holds a weak reference to the device. If the
device is destroyed before the image is created, the image will have a
dangling reference to the device which can cause a use-after-free.
This CL fixes that by adding a ValidateIsAlive() check before creating
the image similar to creating other API objects.
Bug: chromium:1352802
Change-Id: I477f15680ffd27e1ad0166835c4debb80b4be761
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/99384
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This patch enables the workaround about using a temporary buffer in
the T2T copy on Intel Gen11 GPUs after running WebGPU CTS on these
platforms.
Bug: chromium:1161355
Change-Id: Id4a4f189b4a7a3954dc66062d27e9b226d1409f6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/99320
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
On the D3D12 platforms that don't support programmable sample positions,
the source box specifying a portion of the depth texture must all be 0,
or an error and a device lost will occur. This patch adds a workaround
for this issue by alignning the offset of internal staging buffer to 512
when calling Queue.WriteTexture() with depth stencil textures
Bug: dawn:727
Test: dawn_end2end_tests
Change-Id: I6bc5843d62d0aec3964ee5b544a06c0b2657031a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/98601
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
This patch implements the use of big integer values (>2^24 or <-2^24) as
the clear values of a render pass with an internal draw call as D3D12 API
only supports using float numbers as clear values.
Bug: dawn:537
Test: dawn_end2end_tests
Change-Id: Id0a7835d611f598fb77950915f69919f804a8702
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/98104
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
On the D3D12 platforms that don't support programmable sample positions,
the source box specifying a portion of the depth texture must all be 0, or
an error and a device lost will occur. This patch adds a workaround for this
issue by splitting the original buffer-texture copy into two copies:
1. copy from the source resource into a temporary buffer at offset 0
2. copy from the temporary buffer at offset 0 into the destination resource.
In the next patch we will fix the corresponding issue in Queue.WriteTexture.
Note that on newer version of D3D12 the restrictions about
D3D12_TEXTURE_DATA_PLACEMENT_ALIGNMENT and D3D12_TEXTURE_DATA_PITCH_ALIGNMENT
have all been lifted out, so the workaround added in this patch will also be
disabled on the platforms that don't support programmable sample positions
but the restrictions about D3D12_TEXTURE_DATA_PLACEMENT_ALIGNMENT and
D3D12_TEXTURE_DATA_PITCH_ALIGNMENT are no longer available.
Bug: dawn:727
Test: dawn_end2end_test
Change-Id: I9f1d848a0eeac5bd52c9219af6992a2821307746
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/97182
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Intel Xe is also called Intel Gen 12. Quite a few Intel architectures
are classified into Gen 12. Some of these architectures are Gen 12
LP (low power), while the others are Gen 12 HP (high performance,
for example, some Intel discrete GPUs). For more details, see
https://en.wikipedia.org/wiki/Intel_Xe. We need to separate Intel Gen
12 LP from Intel Gen 12 HP for some toggles on D3D12 backend.
Bug: dawn:949
Change-Id: Id5d10c0ecb31ca9e323ede65c3d55e6d4954370e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/97901
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: yang gu <yang.gu@intel.com>
Commit-Queue: Yunchao He <yunchao.he@intel.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Metal implementation is more complex and has more issues, submit D3D12
and Vulkan frist and another CL for Metal.
Bug: dawn:1250
Change-Id: I718d323e01bb41b0209bfd1f1026faf64b4f1076
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/97640
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Hao Li <hao.x.li@intel.com>
2D Array texture might corrupt on some devices, making out-of-bound
texture access and memory information leak from another texture.
This is a critical security issue.
This change aim at mitigating the security issue via allocating
sufficent extra memory for each texture allocation for 2D array
texture on such devices.
Bug: dawn:949
Change-Id: I3629eeb13be872b2107effa55539e5c24522d0fc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96220
Commit-Queue: Yunchao He <yunchao.he@intel.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Bug: dawn:1480, dawn:1481
Change-Id: If61f0466d79e7759ed32c4ddf541ad0c17247996
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96904
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
Storing values into the cache will need to serialize and deserialize
values in addition to keys. This patch factors the serialization
utilities out of CacheKey into a more general "Stream" utility that
supports both input and output for serialization and deserialization.
Multiple files are not renamed to make parsing the diff easier. They
will be renamed in Change If61f0466d79e7759ed32c4ddf541ad0c17247996.
Bug: dawn:1480, dawn:1481
Change-Id: If7594c4ff7117454c1ab3d0afaeee5653120add8
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96480
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
This patch adds RENDER_ATTACHMENT to the internal usage of D3D12 depth
stencil textures on Intel GPU because due to a driver bug we have to
initialize all the depth stencil textures with clear on Intel GPUs
before copying with them. Otherwise, if a depth stencil texture is created
without RENDER_ATTACHMENT usage, it will be initialized by copies, which
will still trigger the driver bug mentioned above.
Bug: 1487
Test: dawn_end2end_test
Change-Id: I78b9a3e2bc4098d6f3f2619644c80fd54dafd4e8
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96985
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
This patch adds a check in the creation of D3D12 texture that we should
always use typeless formats for castable textures on the platforms where
CastingFullyTypedFormatSupported is false.
With this patch the test TextureViewSamplingTest.SRGBReinterpretation will
pass on Intel HD530 GPUs.
Bug: dawn:1276
Test: dawn_end2end_tests
Change-Id: I3f49b1c5aac9a0b881469968e22a5228aac9f35f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/97184
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
This is a public API definition of a program-unique override identifier.
Bug: tint:1155
Change-Id: I6e55d43208e72a7a316557a89e2169d1b952f9bf
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/97006
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
This patch adds a workaround for Intel Gen12 GPUs that we don't set
D3D12_CLEAR_VALUE when creating a texture with any DXGI depth formats
(DXGI_FORMAT_D16_UNORM, DXGI_FORMAT_D32_FLOAT,
DXGI_FORMAT_D24_UNORM_S8_UINT, DXGI_FORMAT_D32_FLOAT_S8X24_UINT)
because on these GPUs the texture data may be corrupted after several
call of ClearDepthStencilView() if D3D12_CLEAR_VALUE is set in the
call of CreatePlacedResource() or CreateCommittedResource().
Bug: dawn:1487
Test: dawn_end2end_tests
Change-Id: Id44af0f6fe31773820f5e20d05edd275dd921e53
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96482
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Signaling a fence in Dawn without waiting can cause a race between Dawn
and Chromium over who signals the fence. Since D3D12 fences are allowed
to be rewound this can cause future waits to hang indefinitely if Dawn
loses the race and signals a lower value than what Chromium expects.
The signal without wait case happens when Dawn submits no command lists
e.g. when CopyExternalImageToTexture uses a zero-sized dimension. This
is the reason for the test failures in https://crrev.com/c/3700811 e.g.
https://ci.chromium.org/ui/p/chromium/builders/try/dawn-win10-x64-deps-rel/24617/overview
To fix the race, it's sufficient to wait before signaling if not already
waited which is what this CL does. This CL also makes the fence stay
alive until pending signals are done - this wasn't the root cause of the
hang described above, but it's still a good idea for robustness, and
also recommended based on discussion around past Chromium XR fence use.
Bug: dawn:576
Change-Id: I8c1d1a19fdb022ae28d26f6723c2f2bfc9c1c3c7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/96321
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
This patch adds a toggle to force initializing depth stencil textures
to 0 on Intel D3D12 drivers as a driver issue will occur when we
create and copy into a depth stencil texture that is just created with
CreatePlacedResources() on Intel D3D12 drivers:
- For the depth stencil textures with RenderAttachment usage, they will
always be cleared with ClearDepthStencilView() instead of copy, then
the following copies will be correct.
In next patch we will handle the situation when the depth stencil
texture is not created with RenderAttachment usage.
Bug: dawn:1487
Test: dawn_end2end_tests
Change-Id: I0f7db86a2e6db55e4b82defb510ccc829c6b0d38
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95989
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
This code uses `_uuidof` (single undescore) instead of `__uuidof`
(two underscores), only the latter is documented as the officially
supported operator by Microsoft:
https://docs.microsoft.com/en-us/cpp/cpp/uuidof-operator?view=msvc-170
I suspect `_uuidof` and `__uuidof` are the same under the msvc compiler,
but in other compilers (Zig/clang/MinGW) only the officially supported
`__uuidof` is exposed. This change improves compatability with such
compilers.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Change-Id: If2850a1a98507161739fcd5f52ebd4ceaefffe75
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/87309
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
D3D12 objects can have implicit dependencies on device resources that
are not captured by holding ComPtrs:
"Direct3D 12 uses COM-style reference counting only for the lifetimes of
interfaces (by using the weak reference model of Direct3D tied to the
lifetime of the device). All resource and description memory lifetimes
are the sole responsibly of the app to maintain for the proper duration,
and are not reference counted. Direct3D 11 uses reference counting to
manage the lifetimes of interface dependencies as well."
Source: https://docs.microsoft.com/en-us/windows/win32/direct3d12/important-changes-from-directx-11-to-directx-12
ExternalImageDXGI can outlive the device it was created on e.g. the D3D
shared image backing holds on to the ExternalImageDXGI for its lifetime.
ExternalImageDXGI destructor can invoke code that depends on D3D12
resources that might have already been destroyed. In particular, this
shows up as ComPtr::Release for ID3D12Fence crashing mysteriously, and
is also speculated as the cause for a racy invalid function pointer
dereference in crbug.com/1338470.
This CL makes the D3D12 backend device destroy the ExternalImageDXGI's
resources on device destruction making it effectively a weak pointer.
This unblocks landing https://crrev.com/c/3700811 and hopefully fixes
crbug.com/1338470 as well.
This CL also deprecates unnecessary WGPUDevice param to ProduceTexture,
and adds an IsValid() method so that the shared image can check it and
decide to recreate the ExternalImageDXGI if needed.
Bug: dawn:576, chromium:1338470
Change-Id: I2122cf807587cf3b1218ba29ea291263df0cf698
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/95860
Kokoro: Kokoro <noreply+kokoro@google.com>
Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
In Mach engine we compile Dawn's d3d12 backend using Zig as a C/C++
compiler, effectively clang with MinGW windows headers. Unfortunately,
this `static constexpr` fails to compile:
```
error: constexpr variable 'kD3D12PromotableReadOnlyStates' must be initialized by a constant expression
```
As kangz previously noted, the reason appears to be because `D3D12_RESOURCE_STATE_COPY_SOURCE`
is not `constexpr` [in MinGW headers](1de9cc347d/mingw-w64-headers/include/winnt.h (L682)).
The thought process is that making this just `const` is fine because
constant propagation would make it a constant anyway.
If we're comfortable merging this, it'd be one less change we have to
maintain on our side - and probably no impact otherwise. On the other
hand, I understand the most-correct fix would be in MinGW headers
themselves. I'd love to land this change, but it's no big deal if you
prefer not.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Change-Id: I772f1cb7e2b4f1b200820cd50f6b7df45850abbb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/87381
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This patch re-enables the workaround for T2T copy issue on Intel
GPUs as we have found there are still other issues about T2T copies
on latest Intel D3D12 driver when we investigate the WebGPU CTS
failures on Intel Gen9 and Gen9.5 GPUs.
Bug: chromium:1161355
Change-Id: Ibd8a8c299453dff6a5432b3c4ab5350558c5313f
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94980
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
This patch clears mTempBuffers everytime after d3d12CommandList
is executed in CommandRecordingContext. Previously mTempBuffers
won't be cleaned up until device is destroyed, which will
consume lots of unnecessary GPU memory.
Bug: chromium:1161355
Change-Id: Ie03d43847ed56e7f2b4bfc5b0f8244dfd7012625
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94820
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Will statically report the base limit of 16 for now. Important to note
that this is not validated properly within Tint at this point, and the
current constant associated with this limit is actually 15.
Bug: dawn:1448
Change-Id: I74a5815cc34439ccc3b6ff9cd0afbc56590148fe
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94661
Commit-Queue: Brandon Jones <bajones@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
It was removed from the spec after determining it didn't provide any
additional capabilities beyond depth24plus-stencil8.
Bug: dawn:1454
Change-Id: Ifba62f22cd38bea88866c849c8d1754a2aa683e2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/92963
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Brandon Jones <bajones@chromium.org>
DXGI external images can now be imported with both fence and texture
shared handles. Fence wait and signal values can be specified for
ProduceTexture. Keyed mutex functionality is kept as is with no change.
The D3D12 resource wrapping tests now run in both keyed mutex and fence
modes.
Bug: dawn:576
Change-Id: Ic793bcc828e5a8850c1367ecffabedd1c67184d9
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/78604
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
