261: streamline Makefile r=kvark a=Napokue
Changes:
- Streamlining the Make commands to make it look better
- Introduced two new variables: `WILDCARD_WGPU_NATIVE` & `WILDCARD_WGPU_NATIVE_AND_REMOTE` to reduce duplicate code. Will continue to reduce duplicate after my compute example is merged, to avoid unnecessary merge conflicts
Maybe I am not too familiar with the concept FFI, but wouldn't it be easier to understand that we just generate headers and not foreign function interfaces. Basically the same, but the latter one sounds a lot more complex. We want to reach as much as possible people, so maybe renaming this would be beneficial?
So I was thinking to have the commands: `header-wgpu` and `header-wgpu-remote`, instead of `ffi-wgpu` and `ffi-wgpu-remote`.
Co-authored-by: Timo de Kort <dekort.timo@gmail.com>
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>
