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>
198: gfx-hal update with swapchain ranges r=msiglreith a=kvark
Also added a small batch file with commands I used to run the CTS. Having them in Makefile is unfortunately not very helpful on Windows.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
188: Fixed some limits that were giving invalid validation layer responses r=kvark a=Thomspoon
Added missing limits for some validation layers.
Dependent on: https://github.com/gfx-rs/gfx/pull/2814/
Also cleaned up a compiler error and random warning from the previous commit.
Co-authored-by: Shawn Thompson <saturisk@gmail.com>
187: Add transfer bit to all queue families r=kvark a=aloucks
Per the `gfx_hal::queue::QueueType` [docs](https://docs.rs/gfx-hal/0.2.0/gfx_hal/queue/enum.QueueType.html), all variants should include transfer operations. Notably, `General` now contains all three queue types.
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
185: Fixes for gfx HEAD, update Cargo.lock, and add gl backend option r=kvark a=aloucks
Updated Cargo.lock and some minor changes to get portability compiling again using the latest gfx master.
With these changes I was able to get `vulkaninfo` to run on a GPU-less VM using Mesa.
```
$ RUST_BACKTRACE=1 VK_ICD_FILENAMES=portability-linux-debug.json vulkaninfo > ~/vulkaninfo.txt
==========
VULKANINFO
==========
Vulkan Instance Version: 1.1.106
Instance Extensions:
====================
Instance Extensions count = 4
VK_EXT_debug_report : extension revision 9
VK_EXT_debug_utils : extension revision 1
VK_KHR_get_physical_device_properties2: extension revision 1
VK_KHR_surface : extension revision 25
Layers: count = 15
=======
...
Device Properties and Extensions :
==================================
GPU0
VkPhysicalDeviceProperties:
===========================
apiVersion = 0x400042 (1.0.66)
driverVersion = 1 (0x1)
vendorID = 0x0000
deviceID = 0x0000
deviceType = CPU
deviceName = Mesa OffScreen
...
```
Full output:
https://gist.github.com/aloucks/1a9acfb51adba4bb598ee6de0a213d82
It's probably a long way from being usable, but it would be nice to use portability for unit testing in CI jobs.
See also: https://github.com/gfx-rs/gfx/pull/2791 for updates to the gl backend.
Co-authored-by: Aaron Loucks <aloucks@cofront.net>
177: gfx-rs update and multiple submissions r=msiglreith a=kvark
~~I wanted to get the Diligent Engine running, eventually got blocked by https://github.com/gfx-rs/gfx/issues/2676~~
Gets us full Diligent Engine compatibility 🎉
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
175: Portability extensions fixes, README update r=grovesNL a=kvark
This version is confirmed to work with VkPI CTS 🎉
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
173: Dependencies update, all-around unsafe qualifiers r=grovesNL a=kvark
The big update to hal-0.1 and beyond.
I'm not sure that trying to minimize the `unsafe` spots was the right decision... perhaps it's easier to just mark all of gfxXxx methods unsafe, but I'm too tired now to rewrite it again.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
