230: Update gfx with swapchain readback support r=kvark a=kvark
Based on https://github.com/gfx-rs/gfx/pull/3424
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
221: Support VK_KHR_portability_subset r=kvark a=kvark
Our extension IDs were messed up. Good thing to clean them up now, since otherwise nobody would be able to make this work 😅
Also, the test native example is now fully trying to initialize the portability extension and gather the relevant info. Output on my machine:
```
vkEnumerateInstanceExtensionProperties: res=0 count=5
vkEnumeratePhysicalDevices: res=0 count=1
vkEnumerateDeviceExtensionProperties: res=0 count=3
gfxGetPhysicalDeviceProperties2KHR
minVertexInputBindingStrideAlignment = 4
gfxGetPhysicalDeviceFeatures2KHR
events = 1
pointPolygons = 0
separateStencilMaskRef = 1
triangleFans = 0
```
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
205: Update to 2018 edition r=kvark a=krolli
This PR implements #179. Most of the work was done by `cargo fix --edition`.
Co-authored-by: Martin Krošlák <kroslakma@gmail.com>
204: Fix rustc warnings r=kvark a=krolli
This PR fixes warnings encountered with stable 1.40.0 rust toolchain. The most interesting issue is likely switch from `mem::zeroed()` and related functions to `MaybeUninit`.
While `mem::zeroed()` is not marked deprecated in the same way as `mem::uninitialized()` is, compiler still threw warning on it. However, in this case it may have been causing undefined behavior, as `EntryPoint` contains references which may not be null. Another option here would be using `Option` instead of `MaybeUninit`, which would be completely safe with some extra checks. Since original code didn't, and because valid Vulkan use requires exactly one vertex shader, I chose to use `MaybeUninit` instead.
Co-authored-by: Martin Krošlák <kroslakma@gmail.com>
203: Update gfx-hal r=kvark a=krolli
Update of portability to use the most recent version gfx-hal. Also cleaned up formatting with rustfmt to reduce noise in commit with actual update of gfx-hal.
Co-authored-by: Martin Krošlák <kroslakma@gmail.com>
202: Added vkGetPhysicalDeviceWin32PresentationSupportKHR r=kvark a=SaschaWillems
This PR adds vkGetPhysicalDeviceWin32PresentationSupportKHR, which will allow applications that query this work with gfx-portability. One such application is my Vulkan Hardware Capability Viewer.
Adding this function will also silences a Vulkan loader debug message that is shown for ICDs not implementing vkGetPhysicalDeviceWin32PresentationSupportKHR.
The implementation will always just return true.
Co-authored-by: Sascha Willems <webmaster@saschawillems.de>
201: fixes crash when enumerating on some systems r=kvark a=Hugobros3
Was crashing when calling `vulkaninfo`. I did some digging:
In gfxEnumeratePhysicalDevices, there is some logic for dealing with the cases where the slots allocated by the caller aren't enough to fit all the adapters the implementation has available. This logic has a flaw though, because it doesn't account for the cases where `num_output` is greater than the numbers of adapters gfx has to offer, and in that case the output is oversized wrt to the adapters we have to fit inside.
This matches both sides for calling copy_from_slice in that function. Not sure why this happens, I have a proper vulkan-ready device in this computer with a "proper" driver too, which may or may not explain it ? I'm not knowledgeable enough on how the loader and everything works to make a definitive statement.
This made things work on my pc so ¯\\_(ツ)_/¯
Co-authored-by: Gobrosse <hugo@xol.io>
