This removes a serialization optimization where structs could be
memcpy'ed. memcpy is still used for deserialization of structs.
Structs may contain padding bytes which when copied can leak
uninitialized data across a trusted boundary. In Chrome, this
means previously-written or uninitialized bytes in the GPU process
could leak into the Renderer process.
In the future, we may be able to bring this back by introducing
a concept of safe-to-memcpy structs, or by forking the code so
that Renderer->GPU process uses the unsafe memcpy, and
GPU->Renderer uses to the safe member-by-member version.
An alternative might be to ensure that everything returned from
the WebGPU API has initialized padding, but this invariant is not
trivial to guarantee.
Fixed: chromium:1359098
Change-Id: I91151251d1ab999e0f5552e1efccc472e451cc10
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/102461
Reviewed-by: Brandon Jones <bajones@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Austin Eng <enga@chromium.org>
It's not valid for an explicit template specialization to declare a storage class (`static`). GCC correctly catches this, while Clang is too relaxed.
Use C++17's 'inline' instead. The alternative is to push the initializers and values into the cpp file.
This breakage was introduced in: https://dawn-review.googlesource.com/c/dawn/+/93604
Bug: dawn:1451
Change-Id: Ib3e61d233e16fd7828f8a2ae0909eedbd24ee52e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/94320
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
This commit changes all the [Object]Allocators from the Client into a
PerType<ObjectStore> member that contains a bunch of ObjectStore acting
on ObjectBase.
Adds a new (template) member functions to the client, Make/Get/Free that
act on any object type, and update all the uses of previous
[Object]Allocator to use these new methods.
Also removes generated code that was generated per object type in favor
of using the type-generic ObjectAllocator.
Bug: dawn:1451
Change-Id: I6463b2fc4a827e3000c2a666abf08aa1a71c3b3b
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/93141
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
ObjectBase::refcount is no longer exposed and instead Reference() and
Release() methods are available to operate on it.
The client is now exposed through a GetClient() accessor.
Bug: dawn:1451
Change-Id: Ia47ed2de0a8f03ccc3275cb81d6335d2125060cb
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/93442
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Previously the ObjectAllocator was tracking the generation on the side
of the object. This was done to avoid the need to check that the objects
aren't null before accessing the generation in ClientHandlers. This is
only a very minor optimization for return commands so it is removed in
favor of simplifying the code.
The code is simplified in a bunch of place by getting the ObjectHandle
for an object directly (since it knows the generation now) instead of
walking the object graph returned by the allocator.
The ObjectBase class is also changed to store an ObjectHandle
interrnally that's only accessible via getters. Encapsulating the other
memebers will be done in follow-up CLs.
Also adds the generation to the ObjectBaseParams since all ObjectBases
now require it.
Bug: dawn:1451
Change-Id: Ic6c850fc989f715f7c80952ff447b7c29378cd27
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/93146
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This allows using it without including all of WireCmd_autogen.h. Start
using in client::ObjectBase to use the typedef for ObjectId.
Bug: dawn:1451
Change-Id: I80e7247cc0e83ae48818b0d73b5236c6980204d1
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/93145
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Austin Eng <enga@chromium.org>
This CL adds the `-Wsuggest-override` and
`-Wsuggest-destructor-override` warnings and fixes up the identified
issues.
Change-Id: I0ec1303a822abc258ce34d3bf1900e37ade6a8dc
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/89561
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
This CL changes several includes which were using the system include
syntax to the local syntax. This causes GN check to verify that the
headers are specified correctly in the dependencies.
Two missing dependencies are added to the BUILD.gn file for the
Dawn tests.
Bug: dawn:1373
Change-Id: I7afd5ab48f4f2e2ddaf1839058c6bbeec2b97fd0
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/86940
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Dan Sinclair <dsinclair@chromium.org>
Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
This is a small rework to try to make the template better handle
functions that aren't associated with an object, when during an
unrelated patch I got confused that APICreateInstance didn't appear in
dawn::native.
Change-Id: If5a2aa3f9e348d1847e48fec4e90e5966ddd489d
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/86530
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Austin Eng
Ben Clayton
Corentin Wallez
dan sinclair