It's a private type, but is exposed as part of the map method. Somehow rustc isn't catching this...

Likely related to #19?

I have noticed for awhile that occasionally my app hangs in debug mode at exit (and never closes). I did some digging. This also occurs in the hello.rs example for me as well, i.e. after "Goodbye!" the application never closes.

I was unable to check with the address sanitizer since it only dumps output after program completion. However, I did trace the method calls. The hang occurs in the Drop implementation for the Swapchain KHR, which then calls device.destroy_swapchain_khr(), which hangs on vkDestroySwapchainKHR() (I have confirmed it is this method). At that point, we're in vks, and I hit a dead end.

I confirmed that the swapchain and device handles were legitimate--they match the values at create time. On my end, there is a single refresh of the swapchain, so two swapchains are created. The first is dropped successfully, and the second one hangs. Because of this, the device, instance, etc. are never dropped.

For reference, I'm on linux with an intel UHD graphics 620.

Per conversation in PR #5.

After a create logical device, the memory is not free.

Reproduction

1. Set PRINT to true
2. cargo run --example hello

Enabling instance extension: 'VK_KHR_device_group_creation' (version: 1)
Enabling instance extension: 'VK_KHR_external_fence_capabilities' (version: 1)
Enabling instance extension: 'VK_KHR_external_memory_capabilities' (version: 1)
Enabling instance extension: 'VK_KHR_external_semaphore_capabilities' (version: 1)
Enabling instance extension: 'VK_KHR_get_physical_device_properties2' (version: 1)
Enabling instance extension: 'VK_KHR_get_surface_capabilities2' (version: 1)
Enabling instance extension: 'VK_KHR_surface' (version: 25)
Enabling instance extension: 'VK_KHR_wayland_surface' (version: 6)
Enabling instance extension: 'VK_KHR_xcb_surface' (version: 6)
Enabling instance extension: 'VK_KHR_xlib_surface' (version: 6)
Enabling instance extension: 'VK_EXT_debug_report' (version: 9)
Enabling instance extension: 'VK_EXT_debug_utils' (version: 1)
DEBUG_REPORT: Debug report printing enabled.
Available device extension: 'VK_KHR_bind_memory2' (version: 0.0.1)
Available device extension: 'VK_KHR_dedicated_allocation' (version: 0.0.1)
Available device extension: 'VK_KHR_descriptor_update_template' (version: 0.0.1)
Available device extension: 'VK_KHR_device_group' (version: 0.0.1)
Available device extension: 'VK_KHR_external_fence' (version: 0.0.1)
Available device extension: 'VK_KHR_external_fence_fd' (version: 0.0.1)
Available device extension: 'VK_KHR_external_memory' (version: 0.0.1)
Available device extension: 'VK_KHR_external_memory_fd' (version: 0.0.1)
Available device extension: 'VK_KHR_external_semaphore' (version: 0.0.1)
Available device extension: 'VK_KHR_external_semaphore_fd' (version: 0.0.1)
Available device extension: 'VK_KHR_get_memory_requirements2' (version: 0.0.1)
Available device extension: 'VK_KHR_image_format_list' (version: 0.0.1)
Available device extension: 'VK_KHR_incremental_present' (version: 0.0.1)
Available device extension: 'VK_KHR_maintenance1' (version: 0.0.1)
Available device extension: 'VK_KHR_maintenance2' (version: 0.0.1)
Available device extension: 'VK_KHR_maintenance3' (version: 0.0.1)
Available device extension: 'VK_KHR_push_descriptor' (version: 0.0.1)
Available device extension: 'VK_KHR_relaxed_block_layout' (version: 0.0.1)
Available device extension: 'VK_KHR_sampler_mirror_clamp_to_edge' (version: 0.0.1)
Available device extension: 'VK_KHR_shader_draw_parameters' (version: 0.0.1)
Available device extension: 'VK_KHR_storage_buffer_storage_class' (version: 0.0.1)
Available device extension: 'VK_KHR_swapchain' (version: 0.0.68)
Available device extension: 'VK_KHR_variable_pointers' (version: 0.0.1)
Available device extension: 'VK_KHR_multiview' (version: 0.0.1)
Available device extension: 'VK_EXT_depth_range_unrestricted' (version: 0.0.1)
Available device extension: 'VK_EXT_descriptor_indexing' (version: 0.0.2)
Available device extension: 'VK_EXT_discard_rectangles' (version: 0.0.1)
Available device extension: 'VK_EXT_external_memory_dma_buf' (version: 0.0.1)
Available device extension: 'VK_EXT_external_memory_host' (version: 0.0.1)
Available device extension: 'VK_EXT_global_priority' (version: 0.0.1)
Available device extension: 'VK_EXT_sampler_filter_minmax' (version: 0.0.1)
Available device extension: 'VK_EXT_shader_viewport_index_layer' (version: 0.0.1)
Available device extension: 'VK_EXT_vertex_attribute_divisor' (version: 0.0.1)
Available device extension: 'VK_AMD_draw_indirect_count' (version: 0.0.1)
Available device extension: 'VK_AMD_gcn_shader' (version: 0.0.1)
Available device extension: 'VK_AMD_shader_core_properties' (version: 0.0.1)
Available device extension: 'VK_AMD_shader_info' (version: 0.0.1)
Available device extension: 'VK_AMD_shader_trinary_minmax' (version: 0.0.1)
Required device extension available: 'VK_KHR_swapchain'
Physical device format count: 2
Physical device present mode count: 3
Physical device queue family count: 2
Physical device queue family count: 2
Physical device queue family count: 2
Physical device format count: 2
Physical device present mode count: 3
Read 1600 bytes from /home/adrien/Devel/voodoo/examples/shaders/vert.spv
Read 1120 bytes from /home/adrien/Devel/voodoo/examples/shaders/frag.spv
Physical device queue family count: 2
Physical device queue family count: 2
Physical device format count: 2
Physical device present mode count: 3
Goodbye.

It never drop the device (device.rs:97). It didn't print "Destroying device..."

Rename Builder to Definition and ::builder to ::define.

Also allow auto-conversion from builders/definitions to built structs.

The PhysicalDeviceMemoryProperties struct has functions which allow the developer to get a slice of size VK_MAX_MEMORY_TYPES. The entries up to memory_type_count are valid, the ones after are invalid.

The Voodoo API should have only one function, memory_types, and it should return a slice of the correct size: &memory_types[..memory_type_count].

hello.rs imports a few crates that are not used in the core library.
Definitely cgmath, and also tobj, image, and ordered_float I think?

See doc.crates.io/specifying-dependencies.html#development-dependencies

The current error check code returns Ok as long as the return code from vulkan is greater than or equal to 0. https://github.com/cogciprocate/voodoo/blob/master/src/error.rs#L206.

However, this is an improper assumption. For instance, if vkWaitForFences times out, VK_TIMEOUT(2) is returned. Similarly, vkGetFenceStatus will return a VK_NOT_READY(1) if the fence is still being used in a queue submission. This means that I am unable to actually use fence synchronization properly through the high level wrapper.

This check should be changed to be more robust and not report Ok when these cases are hit. I'm uncertain, however, if these responses should be considered errors or not. My guess is they probably should be for ease of use of the API, but technically they aren't really errors.

The driver_version function returns a voodoo::Version structure.

However, the spec does not say if this is in the same format as a Vulkan version. It's just a u32, its format is driver-specific.

I've opened this issue to track Voodoo's support for Vulkan 1.1

While the new minor version did not add any new functions, it simply made some extensions core (they needn't be enabled), and removed their KHR suffix.

Since Voodoo relies on vks for its C bindings, until that's updated, we'll probably not support Vk 1.1. Note that there was some work done towards Vk 1.1 in the next branch of the vks repository, but there haven't been any changes since 2 months ago.

https://github.com/withoutboats/failure

Voodoo uses SmallVec in lots of places. Besides making the API more complicated, I doubt it improves performance.

From this blog post by a smallvec developer:

Because malloc is fast, for many cases it’s actually slower to use SmallVec than just using Vec because the one-time cost of the initial allocation is dwarfed by the lifetime cost of SmallVec’s increased complexity. You can see that switching to Vec actually improves speed on many of SmallVec’s own benchmarks.

SmallVec is useful in cases where we perform lots of small allocations, which are unlikely to require allocating on the heap. But in Vulkan allocations are done at resource creation time, off the critical path.

Other Vulkan bindings like ash use Vec instead of smallvec (vulkano notwithstanding, it uses it internally, when doing lots of small allocations).

I suggest we switch Voodoo to use the standard Vec in most places, or even Box, considering the users of the API will likely not try to push new stuff into an array returned by Vulkan.

Instead of returning SmallVec<[QueueFamilyProperties; 16]>, we could return Box<[QueueFamilyProperties]>.