This CL adds in fuzzers for SPIRV-Cross for HLSL, GLSL, and MSL
outputs. These fuzzers live in Dawn because there is not appropriate
location in the Chromium source repo for them and it is unlikely they
would be land-able in the SPIRV-Cross repo, because it is not coupled
with Chromium's build system and thus Clusterfuzz so would be
effectively dead code. Dawn depends on this code, but it is also
integrated into the Chromium build system, so this was the best place
I could find for them
The code under fuzz unfortunately uses exceptions/aborting as its
error reporting mechanism. This is an acknowledge short coming and
there are efforts to remove this behaviour. To work around this and
reduce the number of false positives found by the fuzzers, a signal
trap has been implemented which will be removed once the code under
fuzz has been updated.
The trap replaces the existing signal handler and silencing signals
while running the code under test. This allows the code under test to
call abort() and not crash the fuzzing process. Theoretically, only
SIGABRT should need to be trapped, but something is causing the signal
from abort() to be converted to SIGSEGV when running under ASAN.
This signal trap has been tested with the fuzzing/sanitizers by
intentionally inserting bad calls that will occur after a few thousand
test cases. It was confirmed that the fuzzer detected the issue and
stops fuzzing.
The alternate to implementing this signal trap would be to turn on
exceptions for the fuzzer. This was attempted, but proved to be
fruitless due to what was reported as an ODR issue, but couldn't
couldn't be silenced. The likely underlying issue was a pre-built
library or other object being built without exceptions was causing
different versions of symbols or the exception version of the standard
library not being instrumented by ASAN. Given the majority of Chromium
eco-system turns off exceptions, fixing this issue would not be
helpful to the larger community and was looking like it would require
significant effort.
BUG=chromium:903380
Change-Id: I63a5595383f99b7a0e150d72bb04c89b8d722631
Reviewed-on: https://dawn-review.googlesource.com/c/2260
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Likewise "presented" textures won't be available for use in submits so
this sets up state-tracking and validation for textures too.
Command buffer resource usage is now stored in the frontend instead of
done per-backend because it is used to validate resources are allowed in
the submits.
Also adds a test.
BUG=dawn:9
Change-Id: I0537c5113bb33a089509b4f2af4ddf4eff8051ea
Reviewed-on: https://dawn-review.googlesource.com/c/2142
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
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
Ryan Harrison
Jiawei Shao
Stephen White
Yan,Shaobo