vkCreateImage when bound to imported memory, must also have
a VkExternalImageCreateInfo struct in its pNext chain that
has VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT as a
handleType.
This was discovered when tests started failing after a roll
of the Vulkan validation layers.
Tbr=cwallez@chromium.org, senorblanco@chromium.com
Bug: none
Change-Id: I4692d650af27b9325342baeda34a0d982fc49041
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24200
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
This unblocks a roll into Skia.
Allow comparison against type limits that might be tautological on
32bit or 64bit systems. Without this the following produces an error
on 64bit:
if (myUint64 > std::numeric_limits<size_t>::max()) {...}
Bug: None
Change-Id: I31fc579738b6fb85b40cfeac8f30936161a15da1
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24162
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Added a constraint in ValidateBufferBinding function checking for too
large uniform buffer bindings. Added MaxUniformBufferBindingSize
test in BindGroupValidationTest.
Bug: dawn:436
Change-Id: I31c6e2236ce928d5e81c43455eb18cf4eacdc0f1
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24081
Commit-Queue: Tomek Ponitka <tommek@google.com>
Reviewed-by: Austin Eng <enga@chromium.org>
SetSubData's count is a uint64_t while Queue::WriteBuffer's is a size_t
so we add a small validation check that no narrowing will occur.
No test is added because SetSubData will be removed soon, and it will be
hard to test because of the Null backend's artificial OOM.
This was found while debugging an unrelated fuzzer issue.
Bug: chromium:1099621
Change-Id: I27a9da2b94f51e889c5573f88d4a0a73fea5985c
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/23961
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
In the client code, we often need to translate between WGPUObject (the
API type) to Object* (the internal client type). This added a bunch of
reinterpret_casts that make the code less readable and more fragile.
This CL adds FromAPI and ToAPI helpers in the autogenerated
ApiObjects_autogen.h header, that convert between API and internal types
in a type-safe way.
Bug: dawn:445
Change-Id: Ia1bf624f0315ced496b95cb660adf88abd916d71
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24063
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This header was only used to call DeviceCreateErrorBuffer and
DeviceInjectError that are used in some handwritten client commands.
We remove the need for the header by making these two commands
handwritten.
This also improves readability, previously injecting errors read:
ClientDeviceInjectError(reinterpret_cast<WGPUDevice>(device),
WGPUErrorType_Validation,
"Some validation message");
And now reads:
device->InjectError(WGPUErrorType_Validation, "Some validation message");
Bug: dawn:445
Change-Id: Ie11570aacf3036e13abd174d91670ecb84661226
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24080
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This CL modifies code generation so that the generated client procs call
the handwritten methods on client objects directly.
Previously the flow was:
- wgpuBarDoStuff
- ClientBarDoStuff
- ClientHandwrittenBarDoStuff
- client::Bar::DoStuff
With this CL the flow is:
- wgpuBarDoStuff
- ClientBarDoStuff
- client::Bar::DoStuff
This required adding Buffer creation methods on client::Device instead
of calling client::Buffer static methods directly.
Bug: dawn:445
Change-Id: I1b332b71ac7a03685afcf8fd0617d3d27da468cf
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24062
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This CL only moves code, renames client::Fence members, and introduces
client::Queue. Additional fence methods are added for the interaction
with the queue. There are no functional changes.
With this ApiProcs.cpp is almost passthrough and will be removed in a
follow-up CL.
Bug: dawn:445
Change-Id: I65544ef76b54614452cf7c74a948a96cb35a4cfe
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24061
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Compensate for the fact that dominance does not correspond
exactly to scoping. A definition can dominate a use, but when mapped
in a naive way to constant definitiion and its use, the definition
name goes out of scope by the time you reach the use.
This is correct for storable types.
Bug: tint:3
Change-Id: I03e6c5ba68393151485ed4cdbe6b2b3d7773d1ad
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/24141
Reviewed-by: dan sinclair <dsinclair@google.com>
Avoid sinking expensive operations into control flow such as loops.
The heuristic way to achieve that is to avoid moving combinatorial
values across *any* structured construct boundaries.
Bug: tint:3
Change-Id: I91502b01166a0db64c0e652331591850df75f9d4
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/24140
Reviewed-by: dan sinclair <dsinclair@google.com>
This also removes the reliance on BufferBase::IsMapped to know whether
to unmap on destroy. This call was confusing because it was used by the
D3D12 backend to know if its own storage was mapped, but semantically
seemed to check for Buffer::State::Mapped (and not MappedAtCreation).
Bug: dawn:445
Change-Id: I3d6fde1d2996798d53264d5643545f0efb90551a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24060
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Brandon Jones <brandon1.jones@intel.com>
This CL adds GetMappedRange reusing the existing GetMappedPointerImpl
call in dawn_native. In dawn_wire tracking is added to keep a
Buffer::mMappedData around.
Tests are added to test the result of Get[|Const]MappedRange in all
buffer states.
Bug: dawn:445
Change-Id: I3737dc4d36f31d392839952da0b5c0d10c7c8a88
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/23861
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
In a follow-up CL we need to know if the buffer is in the
MappedAtCreation state for validation of GetMappedRange. Having the
state not 100% reflect the state in the spec meant that validation if
GetMappedRange would fail for buffers mapped at creation for which
IsMapWritable is true.
Bug: dawn:445
Change-Id: I4a64335a708b838526da8d65f907b21c782816e0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/23981
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
In a render/compute pass, if a texture is used as the same usages
across its subresources, and it is also used as different usages
across its subresources. We should mark that it is not used as the
same usages across its subresources for this pass, and we need to
visit every single subresource to track its usages transition.
Bug: dawn:462
Change-Id: Ide0770db62a3b7b85664757b21eb3280a0bb646c
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/23300
Commit-Queue: Yunchao He <yunchao.he@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
The current `cast` conversion code only handles scalar types and fails
if provided with vectors. This CL updates the logic to accept scalars
along with the provided scalar cases.
Bug: tint:96
Change-Id: I60772e75286fc3ee7a9dfba6634db069062b22d0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/23820
Reviewed-by: David Neto <dneto@google.com>
Added Device::GetOrCreateEmptyBindGroupLayout which caches the result
after being run and modified PipelineBase::getBindGroupLayout to use
that instead of creating a new empty bind group layout each time.
Bug: dawn:466
Change-Id: I70a5719265784eb8f60c2eedf6db7596462b21bd
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/23980
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Tomek Ponitka <tommek@google.com>
- Add googletest and spirv-tools local builds only if their CMake targets
are not already configured.
- Add local spirv-headers as an include directory only if the associated
CMake directory does not already point to a directory.
Change-Id: I53ebb0d8fdf7703e8219000b78c75c30859c91a4
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/24020
Reviewed-by: dan sinclair <dsinclair@google.com>
This Cl adds emission of the Kill statement as `discard_fragment`. This
may need to be revised when the semantics of Kill are agreed upon.
Bug: tint:8
Change-Id: I2d09f09143b2acd0139d876e873e3c70abbc84a3
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/23841
Reviewed-by: David Neto <dneto@google.com>
The process of passing the module through this reader, the WGSL semantics,
and the SPIR-V writer will sanitize the module such that the end result
should satisfy SPV_ENV_WEBGPU_0 requirements.
Being more forgiving about the input SPIR-V will be a quality-of-life
improvement.
Bug: tint:3
Change-Id: Ib54cbf729b9e078d797a1ef31422bad497daa5a0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/23942
Reviewed-by: dan sinclair <dsinclair@google.com>
Commit-Queue: dan sinclair <dsinclair@google.com>
This patch moves the computation of TextureBufferCopySplit outside of
the loop over each copy texture array layer so that we only need to do
the computation once for each B2T and T2B copy command.
BUG=dawn:453
TEST=dawn_end2end_tests
Change-Id: I1fcfc972504f845467af92a77bc37870ed7b52a7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/23720
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This Cl adds the code to emit functions from the metal writer. Note,
this does not handle entry points yet.
Bug: tint:8
Change-Id: Ie665771169261f6839de5eb1b66dc511bf47616a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/23704
Reviewed-by: David Neto <dneto@google.com>
This CL adds the start of identifier expressions to the Metal backend.
Identifiers with paths are currently not supported.
Bug: tint:8
Change-Id: I4df8b6a3c32251d454d3dae5fa8933dad36094f8
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/23703
Reviewed-by: David Neto <dneto@google.com>
