This removes the following for both Buffer and Texture:
- The builder's SetInitialUsage
- The object's FreezeUsage and TransitionUsage methods
- The CommandBuffer Transition<Object>Usage methods
All samples and tests are simplified as a result. This also obsoletes
the UsageValidationTest which is removed.
Some validation was dependent on "current usage" and hasn't been
reintroduced for implicit transitions yet:
- Buffers can be used while mapped
- Swapchain textures can be used after they have been presented.
Validation for these will involve collecting all the resources used by a
command buffer and will be done in a follow-up patch.
With this the backend ignores explicit usage transition hints from the
frontent and generates all the barriers automatically based on resource
usage.
The current implementation is very naive and encodes a barrier
immediately just before a resource is used in a new state.
With this commit the Vulkan backend completely ignores the explicit
barrier commands passed from the frontend, and generates its own
pipeline barriers.
Right now it encodes each barrier just before the resources are used,
which is quite bad but will be optimized later.
This commit also makes the frontend command buffer validation perform
the checks necessary for implicit barriers (although they are redundant
with checks for explicit barriers) because the tracking can pre-compute
pass usage information that's useful for the Vulkan backend.
Tests for usage validation inside passes will be added once the concept
of transition is removed from the API.
These should hopefully subsume the ComputeBoids demo for testing purposes. Not all of these tests pass currently:
* ComputeCopyStorageBufferTests.StructTest/D3D12 fails due to "Reading structs from ByteAddressBuffer not yet supported."
* The disabled tests fail for various reasons on various backends.
Previously, the renumbering loop would sometimes iterate in the wrong order. To fix this, instead use the binding info already correctly extracted by `ExtractSpirvInfo`.
Fixes ComputeCopyStorageBufferTests.BasicTest/D3D12.
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.
* Use a descriptor for BindGroupLayout
* Fix MatchesLambda
* Add WireTests.StructureOfStructureArrayArgument
* Add BindGroupValidationTests.BindGroupLayoutCache
I know there was some churn on which version of this shader was correct - but right now, this goes from broken on all 4 backends to working on all 4 backends. So this seems better.
The old code (accidentally?) uses descriptor arrays (I think), which are not trivial to support on all backends, so we won't use them for now.
This introduces a small amount of code duplication in the code that
handles push constants. On the plus side it removes the need for all the
asserts around which Metal encoder is active.
This changes the validation to have one iteration loop for the main
buffer that calls to pass-specific iteration loops for compute passes
and render passes. This is done to simplify code a bit and will help
implement implicit transitions that are "precomputed" per pass in the
command buffer validation and re-used in the backends.
A number of code simplifications were made to CommandBufferStateTracker
since it doesn't need to know if we are in a pass anymore. Further
simplifications will happen when implicit barriers are implemented.
Instead of initializing all of the bind group layouts in the pipeline
layout to default values, let them be nullptr and allow this elsewhere.
Follow-up on some changes in #206
However keep the following samples:
- CHelloTriangle that demonstrates the C API
- CppHelloTriangle that demonstrates the C++ API
- Animometer that matches the WebGL benchmark
- HelloDepthStencil that does more than just a triangle, renamed
to CubeReflection
- ComputeBoids as a cool graphics and compute interop demo
- glTFViewer that shows slightly more advanced usage of NXT
We are changing all object creation to use descriptors but there is no
creation argument to pass for queue, so instead Device::CreateQueue
takes no argument.
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.
This will be useful to provide additional coverage of the wire in
addition to the very focused WireTests unittests. All tests pass except
the MapWriteAsync ones that aren't implemented in the wire yet. They can
be skipped with --gtest_filter=-*MapWrite*
These types are meant to be used for computations that might but are not
expected to fail in backend/, such that the error case can be much
slower than the success case.
The NXT_TRY and NXT_TRY_RESULT macros are added to help write more
concise code that uses Error and ResultOrError.
Corentin Wallez
Kai Ninomiya
Kai Ninomiya
Stephen White