Running test in a Chromium build requires using their gtest and gmock
targets as well as a harness that is in //base. Since we want to run
Dawn tests on the Chromium GPU bots, we need to support two
configurations both building tests standalone and in Chromium.
BUG=chromium:870747
Change-Id: I862e62a607e193a27562ece0f1f6d46d8728e446
Reviewed-on: https://dawn-review.googlesource.com/c/2080
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
ObjectBase will contain data that all WebGPU objects have such as a
pointer back to the device, a refcount (via inheriting from RefCounted),
a name, an error status etc.
BUG=dawn:24
Change-Id: I919e1a6d4a68811ceb6e503b2a793815c92f2528
Reviewed-on: https://dawn-review.googlesource.com/c/1620
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
This patch adds the entry point creating texture view with a
TextureViewDescriptor and all the validations on the parameters
according to https://github.com/gpuweb/gpuweb/issues/79.
BUG=dawn:16
TEST=dawn_unittests
Change-Id: Ibc04a0f7b9f334c57da191606313ab156e18af1f
Reviewed-on: https://dawn-review.googlesource.com/c/1800
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This rolls glslang and shaderc to be able to use their BUILD.gn files,
and also rolls SPIRV-Tools and spirv-headers to have compatible
versions.
BUG=chromium:870747
Change-Id: I13c615f6f3d148c9b69f06547992bf5910e04e62
Reviewed-on: https://dawn-review.googlesource.com/c/1680
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
If a bindgroup was re-used in multiple command buffers in a single call
to queue.Submit(), it was skipping the creation of the corresponding
descriptor heap for that bind group in the second command buffer.
The fix is to use the command buffer's index into the submit command as
part of the key for the bind group's descriptor heap.
Change-Id: Ie66a0e772b10cc72bf040f090dac4c4a10f24266
Reviewed-on: https://dawn-review.googlesource.com/c/1740
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
This splits off part of CommandBufferBuilder in separate
RenderPassEncoder and ComputePassEncoder objects. To match the WebGPU
IDL and factor some code, both these encoders inherit from
ProgrammablePassEncoder.
These encoders are pure frontend objects and record into the
CommandBufferBuilder command allocator objects, so no changes to the
backends were needed.
Error handling is still ew, because the "builder" mechanism we had
doesn't allow for "split builders". Nicer error handling will have to
wait on Dawn matching WebGPU.
All the tests and samples were updated to the new structure.
BUG=dawn:5
Change-Id: I5f5d4ad866e2c07fedd1ba7a122258c6610941f1
Reviewed-on: https://dawn-review.googlesource.com/1543
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
This integrates spirv-val in dawn_native so that regular and
WebGPU-specific validation of shaders is done.
Also adds tests to check OpUndef is correctly rejected so we know
WebGPU-specific validation is working.
Change-Id: If49d276c98bca8cd3c6c1a420903fe34923a2942
Linking against their .lib makes loading Dawn fail on systems that don't
have the DLLs. This happens for example on Windows7 that doesn't have
d3d12.dll. Instead we dynamically load functions pointers from these
DLLs at d3d12::Device startup.
Change-Id: I4d01a12d0f91bec45bf125450d2c08aaa9ff9fac
Chromium's BUILD files try to avoid uses of exec_script when possible
because they slow down every GN invocation. In preparation for building
Dawn inside Chromium, the calls to exec_script for the code generator
are removed.
In GN, the generator now outputs a "JSON tarball", a dictionnary mapping
filenames to content. This allows us to use the "depfile" feature of GN
to avoid the exec_script call to gather the script's inputs.
Outputs of the generator are now listed in the BUILD.gn files. To keep
it in sync with the generator, GN outputs a file containing "expected
outputs" that is checked by the code generator.
Finally the dawn_generator GN template doesn't create a target anymore,
but users are expected to gather outputs using get_target_outputs.
This includes a bunch of fixes for clang warnings in Windows specific
code that was only compiled by MSVC previously. This also tidies up some
BUILD.gn issues on Windows.
This makes the Jinja2 (and MarkupSafe) installation hermetic by
adding it to the DEPS and making the code generator add them in the
first spot of the python path.
This required adding some missing dependencies, splitting public headers
of libdawn_[native|wire] so they aren't hidden in the
libdawn_[native|wire]_sources targets, and making unittests depend on
sources directly instead of static libraries (which is almost equivalent).
As a byproduct, Empty.cpp is no longer needed and is removed.
The code generator doesn't need to load the JSON file to compute the
dependencies our outputs for a codegen target. To better integrate in
noop builds, the lazy-write of generated file is removed because it led
to the code generator running even in noop build (the timestamp of
generated file not being updated).
Also document what could be done to avoid exec_script calls for the Dawn
code generator.
Corentin Wallez
Jiawei Shao
Stephen White
Yan,Shaobo