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.
This required putting Queue::Submit on QueueBase which is something we
would want to do anyway, and removes the need for Queue::ValidateSubmit
being called in the ProcTable.
This removes the need for all the "GeneratedCodeIncludes" files and
leads to a bunch of simplifications in BindGroup as well as the
dawn_native CMakeLists.txt.
Finally this was done in order to simplify the writing of BUILD.gn
files.
Also moves the TerribleCommandBuffer to utils:: because it isn't part of
the implementation of the wire, renames dawn::wire to dawn_wire, moves
src/wire to src/dawn_wire and puts the interface of dawn_wire in
src/include/dawn_wire.
The dawn.h and dawncpp.h structure definitions references dawnFoo or
dawn::Foo respectively when it should reference dawn_native::FooBase* in
dawn_native. Autogenerate files to declare the dawn_native version of
the structs and change the ProcTable generation to use it instead.
This is important to make libdawn_native a shared library because
currently it was depending on dawncpp's definition of .Get().
libdawn will be one of the libraries produced but other libraries like
libdawn_native don't need to link against it. However they do need the
Dawn headers so we generate them separately.
This also makes all internal targets depend on the header generation and
have the include directories necessary for those headers.
Also has a small fix for setting compile flags only for C++ files.
When a MapReadRequestCallback arrived late and hit one of the early out
of the handler (for example if the buffer was already unmapped), the
handler wouldn't consume the data payload of the command. This would
cause the command buffer pointer to not be advanced enough and point to
random data instead of the next command.
Methods, when their arguments are stored in a structure, are very
similar to structures (duh?) Take advantage of this to factor the
[de]serialization code between them and not just memcpy structures
around. This will allow structures to contain objects, and pointers to
other structures / array of objects etc.
The flow of commands is a bit more involved than for MapReadAsync and
goes like this:
- C->S MapAsync isWrite = true
- S: Call MapWriteAsync
- S: MapWriteAsync callback fired
- S->C: MapWriteAsyncCallback (no data compared to the read case)
- C: Call the MapWriteAsync callback with a zeroed out buffer
- C: Application calls unmap.
- C->S: UpdateMappedData with the content of the mapped pointer
- S: Copy the data in the mapped pointer
- C->S: Regular unmap command
- S: Call unmap
Makes nxt_end2end_tests -w pass all tests.
Also duplicates the MapRead wire tests for the write cases
This will help with follow-up changes that add support for a more
complete grammer of types, including structures containing pointers
to objects or other structures.
Instead of having the wire::Client and wire::Server directly act on
buffer memory, a couple interfaces are introduced so that WireCmd can do
things like get the object<->id mapping and temporary allocations.
While the serialization and deserialization of most commands was moved
into WireCmd, the commands that don't directly correspond to NXT methods
have their logic moved inside Client and Server and will be made to
expose the new interface in a follow-up commit.
When calling unmap on a mapped buffer for which the callback hasn't
fired yet, the callback should be called with UNKNOWN. The code marked
the callback as called only after calling it, causing problems with
re-entrancy where the callback would be called twice.
This could also get triggered by destroying the buffer inside the
callback.
Fix this in backend::Buffer and the WireClient and add test for both.
The templates will live in the Chromium prototype. This also removes
the blink/ prefix from the Blink template filenames as this won't be
present in anymore.
* clang/gcc: enable -pedantic warnings
* suppress a GCC-specific warning in stb_image
* And some clang-specific warnings
* -Wconversion (clang) -Wold-style-cast (clang+gcc)
and fix a few warnings that show up with these (and a few more with
-Wconversion on gcc, even though that's not enabled by default)
* bunch more warnings
* fixes
* remove merge error
Corentin Wallez
Jimmy Casey
Kai Ninomiya
Kai Ninomiya
Austin Eng