258: Run-time lock protection against double root r=grovesNL a=kvark
Fixes https://github.com/gfx-rs/wgpu-rs/issues/42
cc @paulkernfeld
We didn't handle a case where the root locking token would get dropped (while some children are borrowed), and a new one is created. This was the case in `wgpu_device_poll`, which ended up trying to unmap the buffers.
This PR brings a relatively simple run-time check for this. It could *probably* be done at the type level, but I'm going to leave it for any follow ups (help is welcome!), because:
1. we'll still have a run-time check for the simple case where 2 or more root tokens are created
2. I spent 20 minutes trying and wasn't able to get this going
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
254: Rebind with proper dynamic offsets r=grovesNL a=kvark
~~The change fixed a bug found by @kocsis1david : when we re-bind the higher bind groups we aren't currently considering their dynamic offsets.~
Fixes#255
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Disable vsync
Revert accidential hardcode of num_frames
Make the PresentMode configurable
Adapt examples
+ adjust style according to @kvrak
Adher to @kvarks wishes for style.
Examples build.
Fix unnecessary ampersand.
223: Derive Debug for All Remaining Public Types r=kvark a=arashikou
With gfx-hal 0.2.1 and the various backend releases on 2019-06-28, all of the gfx-hal types that wgpu depends on implement `Debug`. Thus, some types that could not derive `Debug` in #216 can now derive `Debug`.
This patch also adds `Debug` implementations for a few types that were recently added to wgpu.
Fixes#76.
Co-authored-by: John W. Bruce <arashikou@gmail.com>
With gfx-hal 0.2.1 and the various backend releases on 2019-06-28, all
of the gfx-hal types that wgpu depends on implement Debug. Thus, some
types that could not derive Debug in #216 can now derive Debug.
This patch also adds Debug implementations for a few types that were
recently added to wgpu.
Fixes#76.
242: Add logic to pick highest performance GPU on DirectX 12 r=kvark a=AndrewGaspar
I was having an issue on my Surface Book where my Intel's integrated GPU is always selected instead of my Nvidia discrete GPU when querying for `HighPerformance`. It turns out the Intel GPU is reported as a `DistcreteGPU` by `gfx` (in fact `gfx` has no logic for reporting `IntegratedGPU`s for DX12). However, it also turns out that `dx12::Instance::enumerate_adapters` returns adapters in descending order of performance, at least on Windows 10 > 1803. Therefore, we should use the _first_ GPU in each category, at least for `HighPerformance`. With this fix, `LowPower` selects my Intel GPU and `HighPerformance` and `Default` select my Nvidia GPU.
I'm not so sure `LowPower` = `IntegratedGPU` and `HighPerformance` = `DiscreteGPU` is the quite correct mapping, so I filed an issue on gfx to improve the ability for querying for power/performance preference: https://github.com/gfx-rs/gfx/issues/2879
Anyway, let me know if you have a different fix you'd prefer.
Co-authored-by: Andrew Gaspar <andrew.gaspar@outlook.com>
236: Re-export Pod from gfx-hal r=kvark a=paulkernfeld
This way, Pod can be used as a trait bound in wgpu-rs
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
235: Full MSAA handling r=kvark a=rukai
These changes fix the msaa-line wgpu example, along with a PR to wgpu-native https://github.com/gfx-rs/wgpu-rs/pull/28
Concerns:
* webgpu does not expose a way for users to query limits, how are they supposed to choose a suitable sample_count?
* I think `attachment_unused` should be moved into gfx-hal. Where abouts?
* Is a sample mask of `:u64 = !0` suitable?
Co-authored-by: Rukai <rubickent@gmail.com>
230: Implement sample_count field r=kvark a=rukai
I'm trying to get MSAA working for brawllib renderer.
This PR allows for more ways to hit validation errors.
Giving a valid but mismatching sample count results in these validation errors.
```
ERROR gfx_backend_vulkan
VALIDATION [VUID-vkCmdCopyImageToBuffer-srcImage-00188 (0)] : vkCmdCopyImageToBuffer(): srcImage for image 0xe030 was created with a sample count of VK_SAMPLE_COUNT_4_BIT but must be VK_SAMPLE_COUNT_1_BIT. The Vulkan spec states: srcImage must have a sample count equal to VK_SAMPLE_COUNT_1_BIT (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdCopyImageToBuffer-srcImage-00188)
object info: (type: IMAGE, hndl: 57392)
ERROR gfx_backend_vulkan
VALIDATION [UNASSIGNED-CoreValidation-DrawState-NumSamplesMismatch (0)] : Num samples mismatch! At draw-time in Pipeline (0x7) with 1 samples while current RenderPass (0xe) w/ 4 samples!
object info: (type: PIPELINE, hndl: 7)
ERROR gfx_backend_vulkan
VALIDATION [VUID-vkCmdDrawIndexed-renderPass-02684 (0)] : vkCmdDrawIndexed(): RenderPasses incompatible between active render pass w/ renderPass 0xe and pipeline state object w/ renderPass 0x6 Attachment 0 is not compatible with 0: They have different samples.. The Vulkan spec states: The current render pass must be compatible with the renderPass member of the VkGraphicsPipelineCreateInfo structure specified when creating the VkPipeline bound to VK_PIPELINE_BIND_POINT_GRAPHICS. (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdDrawIndexed-renderPass-02684)
object info: (type: RENDER_PASS, hndl: 14)
```
Co-authored-by: Rukai <rubickent@gmail.com>
224: Fix descriptor sets free validation error r=kvark a=rukai
Seeing as kvark believes this change to be correct I've opened this PR.
Still doesnt fix https://github.com/gfx-rs/wgpu/issues/221 though
Co-authored-by: Rukai <rubickent@gmail.com>
226: Tracking Rewrite r=grovesNL a=kvark
Fixes#44
The idea is to support independent tracking of sub-resources. Today, this is needed for textures, which can have individual layers and mipmap levels in different states at a time. Tomorrow, this will be needed for buffer sub-ranges.
The intent to hack it in grew into a complete rewrite of the tracker... The new approach is cleaner in a few places (e.g. `TrackPermit` is gone), but the implementation is obviously more complex. I tried to separate the levels from each other (see `ResourceState` and `RangedStates`) to fight complexity, but it requires a whole lot of testing infrastructure to be solid.
Also regresses #216 a bit, cc @arashikou : tracker is a relatively complex structure. I somehow doubt it's useful to look at it in debug spew. We may need to implement `Debug` manually for it before re-adding `Debug` derives on passes and command buffers.
TODO:
- [x] documentation of tracking types
- [x] unit tests for tracking logic
- [x] actual testing with existing apps, ensure no regressions
- [x] write a mipmap generation example
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
