`D3D12_HEAP_TYPE, D3D12_CPU_PAGE_PROPERTY, D3D12_MEMORY_POOL, D3D12_HEAP_FLAGS, D3D12_HEAP_PROPERTIES, and D3D12_HEAP_DESC
ID3D12Heap
Wrap ID3D12Device::CreateHeap
Made a tricky enum because DX12 doesn't follow Rust's rules
bump version to 0.2.0
Use bitflags for heap::Flags
Fix typo
Another typo fix
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>
40: Update running an example documentation r=kvark a=Napokue
- Removed link to gfx getting started
- Created our own getting started (with examples)
- Updated syntax
Motivation: I always forget how to run the examples, gfx getting started is not the same as the wgpu-rs one. So I found the correct usage of the syntax to run examples. I am noticing in the Gitter channel that many people are struggling with running the examples, maybe this will clear it up a little.
This is the beginning, I will continue to expand the documentation in the future.
Co-authored-by: Timo de Kort <dekort.timo@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.
32: Add conversion matrix from OpenGL to wgpu r=kvark a=dragly
The matrices in the examples are given in an OpenGL-like coordinate system,
while a Vulkan-like coordinate system is used by wgpu. This was previously
partially corrected in the shader and by flipping the up axis of the camera,
but left the x-axis mirrored in the final result.
This change adds a conversion matrix to framework.rs that can be used
to convert from OpenGL to wgpu. This also allows us to set the
winding-order to counter-clockwise, which matches the ordering in the data.
Co-authored-by: Svenn-Arne Dragly <dragly@cognite.com>
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
The matrices in the examples are given in an OpenGL-like coordinate system,
while a Vulkan-like coordinate system is used by wgpu. This was previously
partially corrected in the shader and by flipping the up axis of the camera,
but left the x-axis mirrored in the final result.
This change adds a conversion matrix to framework.rs that can be used
to convert from OpenGL to wgpu. This also allows us to set the
winding-order to counter-clockwise, which matches the ordering in the data.
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>
25: Add MSAA example r=kvark a=rukai
This example is the same as the triangle example except:
* The render pipeline is created with a sample_count of 4
* A new texture with a sample_count of 4 is created and set as the color_attachment instead of the swapchain
* The swapchain is now specified as a resolve_target
It doesn't work yet as wgpu-native doesn't handle MSAA yet.
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>
