This is a reland of b04a92f01b
with the deletion of a duplicate exported function in dawn_wire that
was causing a compilation failure on Windows.
Original change's description:
> Add a per-thread proc table using thread local storage
>
> In situations where both dawn_wire and dawn_native are used on separate
> threads (Chrome with --single-process or --in-process-gpu), it's
> desirable to have a per-thread proc table so that the WebGPU C++ API can
> still be used. This eliminates classes of bugs with manual
> reference/release errors.
>
> This also changes many of the GetProcs functions to return const
> references to the static proc tables known at compile time, instead of a
> copy.
>
> Bug: none
> Change-Id: I8775bb715b312dd9476a1903fbd797d4b1302614
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/29240
> Reviewed-by: Stephen White <senorblanco@chromium.org>
> Reviewed-by: Corentin Wallez <cwallez@chromium.org>
> Commit-Queue: Austin Eng <enga@chromium.org>
Bug: none
Change-Id: Id90e5372132cd93a2f8631c8185d0e71b01bc1af
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/29443
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
This reverts commit b04a92f01b.
Reason for revert: Build failed on win-archive-dbg; see:
https://chromium-review.googlesource.com/c/chromium/src/+/2450792
Original change's description:
> Add a per-thread proc table using thread local storage
>
> In situations where both dawn_wire and dawn_native are used on separate
> threads (Chrome with --single-process or --in-process-gpu), it's
> desirable to have a per-thread proc table so that the WebGPU C++ API can
> still be used. This eliminates classes of bugs with manual
> reference/release errors.
>
> This also changes many of the GetProcs functions to return const
> references to the static proc tables known at compile time, instead of a
> copy.
>
> Bug: none
> Change-Id: I8775bb715b312dd9476a1903fbd797d4b1302614
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/29240
> Reviewed-by: Stephen White <senorblanco@chromium.org>
> Reviewed-by: Corentin Wallez <cwallez@chromium.org>
> Commit-Queue: Austin Eng <enga@chromium.org>
TBR=cwallez@chromium.org,senorblanco@chromium.org,enga@chromium.org
Change-Id: I4587b457b7b2dd5d3c7457065bf4e77b95af59d7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: none
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/29442
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
In situations where both dawn_wire and dawn_native are used on separate
threads (Chrome with --single-process or --in-process-gpu), it's
desirable to have a per-thread proc table so that the WebGPU C++ API can
still be used. This eliminates classes of bugs with manual
reference/release errors.
This also changes many of the GetProcs functions to return const
references to the static proc tables known at compile time, instead of a
copy.
Bug: none
Change-Id: I8775bb715b312dd9476a1903fbd797d4b1302614
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/29240
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Convention in CMake land is that libraries default to STATIC or
SHARED based on BUILD_SHARED_LIBS. Do that for Dawn components
that users will link against, but make sure to correctly set
macros used for the export headers.
Bug: None
Change-Id: I6a96cb95706b63c18942424baada11ff81691866
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/28503
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Done by:
- Appending an extra newline at the end of src/**/*.{cpp,h,mm,gn}
except src/tests/*
- Running git cl format --full to format the full contents of every
changed file
Bug: none
Change-Id: Id88fc5ed0c5efbbc93b2c6a305c2f98465fe646d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/24641
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
It also changes remaining deps for internal targets
from libdawn_proc to dawn_proc.
Bug: chromium:1064305
Change-Id: I36df2b5d7793be9d6c878b6a1f2ec238603a8205
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/19289
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
When the libdawn_native target was renamed to dawn_native, the output
library name stayed the same (GN inserts a lib prefix if it isn't
present) but the @rpath annotation changed to be just dawn_native.dylib.
Fix this by adding the lib prefix in the rpath annotation. This requires
changing libdawn_proc to dawn_proc otherwise the rpath annotation would
be liblibdawn_proc.dylib.
Bug: dawn:380
Change-Id: Id8610a6318af3468dcc486ee8d3c035f0273fe0d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/19200
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Headers only INTERFACE library with generated headers don't work in CMake
because the GENERATED property is local to a directory. Instead we make a
STATIC library with a Dummy cpp file.
INTERFACE libraries can only have INTERFACE sources so the sources get added
to the dependant's list of sources. If these dependents are in another
directory, they don't see the GENERATED property and fail to configure
because the file doesn't exist on disk.
Use this trick for both dawn_headers and dawncpp_headers that are header
only libraries with generated headers.
Bug: dawn:333
Change-Id: Ib0d6dcc5f351a638d1c5360214c0ce14a28fee3e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15921
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Adds CMake support for:
- Generating the Dawn headers and C++ wrappers
- libdawn_wire
- libdawn_native with the Metal backend for now
- All the examples.
Bug: dawn:333
Change-Id: I6ffbe090b0bd21d6a805c03a507ad51fda0275ca
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/15720
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
webgpu.h is the "official" header for WebGPU in native and is being
developed in https://github.com/webgpu-native/webgpu-headers
dawn.h and dawncpp.h are changed to become webgpu.h and webgpu_cpp.h
respectively and use the new naming convention. New dawn.h and dawncpp.h
headers are created that just proxy the types, constants and functions
to their WebGPU counterpart.
Almost no naming change is done in Dawn in this commit, which help check
that the proxying headers work correctly. A couple changes were
necessary, in particular for tests of the internal of dawncpp.h, and a
workaround for a standard library bug for std::underlying_type was
removed because it is no longer needed and got in the way.
Finally since some templates were renamed to match the name of the file
they create instead of using the generic "api" name.
BUG=dawn:22
Change-Id: I12ee22d0b02ccb5b8a52ceccabb3e63ce74da007
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/12480
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
libdawn_native also requires the dawncpp headers. When we separated
libdawn_cpp from the dawn_headers, libdawn_native lost the cpp headers
and caused a compile failure. This patch separates the dawncpp headers
as a separate target so both libdawncpp and libdawn_native can depend
on them.
Bug: dawn:22
Change-Id: I4172f1654377afac8c4314123ee8b5b81dc7c928
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/12300
Reviewed-by: David Turner <digit@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
The functionality of the dawn_headers and libdawn targets are split into
the following targets:
- dawn_headers: the new version only exposes the "dawn.h" C API and no
longer includes the C++ API.
- dawncpp: the header and implementation of the C++ API that wraps the
C API. This is unbundled from the rest so the C++ API can be used
with libdawn_proc or other libraries implementing the C API.
- libdawn_proc: A DawnProcTable-backend implementation of the C API.
This is needed because in follow-up commit there will be three libraries
implementing the C API: libdawn_proc that trampolines where we want, and
libdawn_native/wire that don't have trampolines for better perf.
BUG=dawn:22
Change-Id: I5d941f0d98e5a4b633e14d67eb5269f7924f0647
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/12160
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This normalizes even more the directory structure of generated files in
Dawn and removes stale autogenerated files that could be included
wrongly using a GN action.
See comment on top of dawn_generator.gni in this commit for more
context.
BUG=dawn:22
Change-Id: I8ec038f949c048431b2b643af4462f98c4ae610b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/11361
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Previously dawn_native files were in src/dawn_native/ while generated
files were in dawn_native/. This makes some things complicated when
integrating in other source trees so normalize all generated files to be
in paths that match the main tree.
BUG=dawn:225
Change-Id: I5b3e04d37a16251143578dfb7a31445b229fe4ac
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/11300
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This merges all the files for main.py together again except
generator_lib.py because there doesn't seeem to be a good way to
separate the pure dawn.json generators and the dawn wire generator.
Also updates the GN templates to make it easier to define new generators
based on generator_lib, and move the Jinja2 template "stdlib" to
generator_lib.py
BUG=dawn:165
Change-Id: I1b5b2ef0a59cb142e214f3af9a58048a88ae949a
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/7880
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
The public include dirs for Dawn were in the dawn_public config but it
would only be added to targets as a part of public_configs. This meant
that second-level dependencies that ended up needing to include
dawn/dawn.h wouldn't know where to find it.
Fixed this by adding include dirs in all_dependent_configs and renamed
the config to be very explicit that it is for include dirs only.
BUG=chromium:938895
Change-Id: Iad70f3ce1f8a02b96bf341e7dd7d6068ce645af7
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/5920
Reviewed-by: Austin Eng <enga@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This adds an option to dawn_generator to generate files in a different
directory so the generated stay at the same place. Otherwise compilation
errors occur because of stale versions of the headers on the CQ
builders.
BUG=dawn:61
Change-Id: I71ceb3172b5a4e35911973a03be29d90fa684416
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/5304
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>