1198: Fix command allocator race condition with maintenance r=kvark a=kvark
**Connections**
Fixes#1196
**Description**
This was a recent change, where I thought it would be more pure to just prepare the pool but not create anything right away. It looked more elegant, but now we see it was flowed.
**Testing**
Not really tested the concurrent aspect of it, but it should work.
Perhaps, we can hook up Loom in the future for this task?
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1194: Isolate binding compatibility logic into a separate module r=cwfitzgerald a=kvark
**Connections**
Fixes#1188
**Description**
The actual problem was the following: when a pipeline changed, we used to go through the binding entries and re-bind only those that *became* compatible. However, we were missing ones that were already compatible, but were not activated because they were behind some previously incompatible ones.
So it's not a very complex fix. However, working with the binding code had me concerned that it wasn't isolated enough. It got quite a few issues discovered in it over the time, which only proven the point that it was way too fragile. So I took this opportunity to bring us closer to the world I want wgpu to be in: the world of semi-independent testable components.
This PR makes the binding compatibility checker one of these components. It's fully isolated, has unit tests, fairly straightforward to reason about, and integrates nicely with the render pass logic (without too many generics!). It's more profitable in the long run, I think, to build this kind of architecture versus integration-testing the thing (even at `wgpu` playtest level).
There is less magic overall now: no binding iterator, no fancy chaining, no complex matching. The logic is straightforward, hopefully. And the 40 LOC saved is a good indication of it.
**Testing**
Tested on wgpu-rs examples.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1187: validate for strip_index_format being used with non-strip topology r=kvark a=Wumpf
**Description**
Hit lack of this validation when porting a project to newest wgpu-rs: Accidentally set the strip_index_format for a TriangleList pipeline which left me with a Vulkan validation error (since wgpu decides to set `restart_index` in presence of a `strip_index_format`)
```
VALIDATION [VUID-VkPipelineInputAssemblyStateCreateInfo-topology-00428 (-1077750125)] : Validation Error: [ VUID-VkPipelineInputAssemblyStateCreateInfo-topology-00428 ] Object 0: handle = 0x1ebbfa512a8, type = VK_OBJECT_TYPE_DEVICE; | MessageID
= 0xbfc2d693 | vkCreateGraphicsPipelines() pCreateInfo[0]: topology is VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST and primitiveRestartEnable is VK_TRUE. It is invalid. The Vulkan spec states: If topology is VK_PRIMITIVE_TOPOLOGY_POINT_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST, VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST_WITH_ADJACENCY, VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST_WITH_ADJACENCY or VK_PRIMITIVE_TOPOLOGY_PATCH_LIST, primitiveRestartEnable must be VK_FALSE (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkPipelineInputAssemblyStateCreateInfo-topology-00428)
object info: (type: DEVICE, hndl: 2112044208808)
```
(arguably wgpu could be more clever about this and just not set `restart_index`, but that leaves the user code in a non-sense state)
**Testing**
One-off test triggering the error through wgpu-rs.
Co-authored-by: Andreas Reich <r_andreas2@web.de>
1183: Improve docs language r=cwfitzgerald a=danielzgtg
**Description**
- s/fact culling/face culling/g
- s/are draw /are drawn /g
**Testing**
- There are no code change.
- The documentation should be less confusing
Co-authored-by: Daniel Tang <danielzgtg.opensource@gmail.com>
1182: Update all versions r=kvark a=kvark
**Connections**
Picks up https://github.com/gfx-rs/gfx/pull/3620 and a bunch of other fixes in gfx-rs and naga.
**Description**
Updates the dependencies ("gfx-9" naga train) as well as self version to 0.7, to match the v0.7 branch.
**Testing**
Should just work :)
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1159: Zero initialize buffers r=kvark a=Wumpf
**Connections**
First half of #563, focusing solely on buffers and ignoring same issue for textures
**Description**
Tracks for each buffer which parts are initialized (i.e. set to zero). Identified three interaction points for this:
* buffer mapping: Zeroing out ad-hoc and marking as initialized
* queue write to buffer: Marks target buffer regions as initialized (i.e. optimizes away buffer init down the line)
* use in binding or copy operation in a command buffer:
* fine grained tracking of regions that may require init (or will be initialized implicitly) on each command buffer
* set in motion on queue submit, init is exclusively with `fill_buffer`
Todo list for Ready-to-Review
- [x] memory barriers for `fill_buffer` calls
- [x] better data structure for `memory_init_tracker`
- [x] coarse filtering on command-buffer buffer init requirements (the list should almost always be empty whereas now it pushes any buffer use)
- [x] improve naming of things
- [x] at least pretend this is adequately tested
Todo list beyond this PR
* make data structures usable for textures
* and.. well.. implement all this for textures!
* explore reusing barrier tracker for memory init tracking?
**Testing**
* Some basic testing by doing some changes to wgpu-rs samples and watching them in in the debugger.
* Added a ron test file for the player (love those!) to poke the feature a little bit
* MemoryInitTracker comes with simple unit tests
Overall this is a bit shallow but as so often in this area accurate testing is hard because the outcomes are quite indirect
Co-authored-by: Andreas Reich <r_andreas2@web.de>
