cc #300

Remains to do:

• [ ] Expose the ActivateMoltenVKLicenseMVK function somewhere in vulkano.
• [x] Tweak winit to allow exporting the NSView or UIView of the window. For MacOS this is done by adding an additional function here: https://github.com/tomaka/winit/blob/41e1a768e575667a0dfff6bc9c8f56c30d662122/src/os/macos.rs#L9
• [x] Update vulkano-win to create surfaces on MacOS and iOS.
• ~~Check that it's a correct thing to do to dlopen the MoltenVK library.~~

After steps 2 and 3, it should "just work" if you put the MoltenVK file next to the executable. Step 1 is optional for now because the free trial doesn't require activating a license.

I'm not sure that I'll finish this PR soon, so feel free to submit PRs to the moltenvk branch if you want to work on it. It should be fairly easy to do steps 2 and 3 (feel free to ask questions).

I'm also unsure about whether we'll want to merge this branch until MoltenVK is stable enough. I don't really want to have obsolete code in vk-sys because they decided to modify their extensions.

~Depends on https://github.com/vulkano-rs/vulkano/pull/1680~

* Entries for Vulkano changelog:
    - **BREAKING** `BufferAccess` now requires Send + Sync. This cascades into `TypedBufferAccess`, `BufferSlice`, `ImmutableBufferInitialization`, `ImmutableBuffer`, `DeviceLocalBuffer`, `CpuBufferPoolSubbuffer`, `CpuBufferPoolChunk`, `CpuAccessibleBuffer`, and `BufferView` now requiring their types to be `Send + Sync`.
    - **BREAKING** `DescriptorSetLayout::new()` now returns `Result<Self, DescriptorSetLayoutError>` instead of Result<Self, OomError>`
    - **BREAKING** `DescriptorCompatibilityError` additional variant `VariableCount`.
    - **BREAKING** `GraphicsPipelineCreationError` additional variant `PipelineLayoutCreationError`.
    - **BREAKING** `PipelineLayoutCreationError` additional variant `SetLayoutError`.
    - **BREAKING** `FixedSizeDescriptorSetsPool` has been replaced by `SingleLayoutDescSetPool`.
    - **BREAKING** Set builders now return `&mut Self` instead of `Self` & methods take values wrapped in an `Arc`.
    - Descriptor sets now support variable count descriptors.
        - e.g. `layout(set = 0, binding = 0) uniform sampler2D textures[];`

This pull request replaces the current descriptor set creation. PersistentDescriptorSet & FixedSizeDescriptorSetsPool. to allow for variable count arrays. e.g. layout(set = 0, binding = 0) uniform sampler2D textures[];

• Version of vulkano: v0.22.0
• OS: ArchLinux - Linux version 5.11.11-arch1-1 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1)
• GPU (the selected PhysicalDevice): Intel(R) Xe Graphics (TGL GT2) (type: IntegratedGpu)
• GPU Driver: vulkan-intel package, 21.0.1-1
• Upload of a reasonably minimal complete main.rs file that demonstrates the issue: See the image example in this repo

Issue

Trying to load images goes poorly when trying to do so on an Intel Xe Graphics card. The image becomes almost completely garbled, though it does still load some image portions. See the attached images - one shows the example Rust logo failing to load properly, the other shows a piece of code I put together that loads an image of my dog. It's easier to tell with the dog image, but it looks like portions of the image are being loaded, but something about the image structure is wrong. Only strong edges seem to be preserved, which to me hints at some kind of alternate sub-sample friendly memory layout.

I'm reasonably sure this isn't a graphics driver issue, as the Vulkan texture loading examples in C++ work fine.

If I switch to using a StorageImage and read the data back out to a buffer, the buffer contains data different from what I originally used to create the image. Instead, it appears to match up with the pixels as displayed.

I think this is also tangentially reported in #1468 - in that issue, the reporter mentions their integrated graphics card produces "confetti", but things work fine when using a dedicated card. That sounds like the same issue I'm having here.

My best guess so far is that the image memory barriers used to transition between layouts aren't set up right. Somehow we're copying data to the image when its layout is not correct for that operation, or it is getting treated as though its layout is different than what is actually in memory. I've done some probing into the Vulkan API calls, looking for differences between how Vulkano and the C++ example works, and that's about all I've come up with so far... well, that and the memory allocations & mapping seem to be handled slightly differently. The copy operations and buffer initialization seem to be basically the same.

The command buffer API calls from Vulkano are:

Thread 0, Frame 0, Time 17382 us:
vkBeginCommandBuffer(commandBuffer, pBeginInfo) returns VkResult VK_SUCCESS (0):
    commandBuffer:                  VkCommandBuffer = 0x563c2d05cd80
    pBeginInfo:                     const VkCommandBufferBeginInfo* = 0x7ffc251f8168:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO (42)
        pNext:                          const void* = NULL
        flags:                          VkCommandBufferUsageFlags = 0
        pInheritanceInfo:               const VkCommandBufferInheritanceInfo* = UNUSED

Thread 0, Frame 0, Time 17430 us:
vkCmdPipelineBarrier(commandBuffer, srcStageMask, dstStageMask, dependencyFlags, memoryBarrierCount, pMemoryBarriers, bufferMemoryBarrierCount, pBufferMemoryBarriers, imageMemoryBarrierCount, pImageMemoryBarriers) returns void:
    commandBuffer:                  VkCommandBuffer = 0x563c2d05cd80
    srcStageMask:                   VkPipelineStageFlags = 8192 (VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT)
    dstStageMask:                   VkPipelineStageFlags = 4096 (VK_PIPELINE_STAGE_TRANSFER_BIT)
    dependencyFlags:                VkDependencyFlags = 1 (VK_DEPENDENCY_BY_REGION_BIT)
    memoryBarrierCount:             uint32_t = 0
    pMemoryBarriers:                const VkMemoryBarrier* = 0x7ffc251fd4a8
    bufferMemoryBarrierCount:       uint32_t = 0
    pBufferMemoryBarriers:          const VkBufferMemoryBarrier* = 0x7ffc251fd4e8
    imageMemoryBarrierCount:        uint32_t = 1
    pImageMemoryBarriers:           const VkImageMemoryBarrier* = 0x7ffc251fd6b8
        pImageMemoryBarriers[0]:        const VkImageMemoryBarrier = 0x7ffc251fd6b8:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER (45)
            pNext:                          const void* = NULL
            srcAccessMask:                  VkAccessFlags = 0 (VK_ACCESS_NONE_KHR)
            dstAccessMask:                  VkAccessFlags = 4096 (VK_ACCESS_TRANSFER_WRITE_BIT)
            oldLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_UNDEFINED (0)
            newLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL (7)
            srcQueueFamilyIndex:            uint32_t = 4294967295
            dstQueueFamilyIndex:            uint32_t = 4294967295
            image:                          VkImage = 0x563c2d06fbb0
            subresourceRange:               VkImageSubresourceRange = 0x7ffc251fd6e8:
                aspectMask:                     VkImageAspectFlags = 1 (VK_IMAGE_ASPECT_COLOR_BIT)
                baseMipLevel:                   uint32_t = 0
                levelCount:                     uint32_t = 1
                baseArrayLayer:                 uint32_t = 0
                layerCount:                     uint32_t = 1

Thread 0, Frame 0, Time 17720 us:
vkCmdCopyBufferToImage(commandBuffer, srcBuffer, dstImage, dstImageLayout, regionCount, pRegions) returns void:
    commandBuffer:                  VkCommandBuffer = 0x563c2d05cd80
    srcBuffer:                      VkBuffer = 0x563c2d057030
    dstImage:                       VkImage = 0x563c2d06fbb0
    dstImageLayout:                 VkImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL (7)
    regionCount:                    uint32_t = 1
    pRegions:                       const VkBufferImageCopy* = 0x7ffc251fc178
        pRegions[0]:                    const VkBufferImageCopy = 0x7ffc251fc178:
            bufferOffset:                   VkDeviceSize = 0
            bufferRowLength:                uint32_t = 0
            bufferImageHeight:              uint32_t = 0
            imageSubresource:               VkImageSubresourceLayers = 0x7ffc251fc188:
                aspectMask:                     VkImageAspectFlags = 1 (VK_IMAGE_ASPECT_COLOR_BIT)
                mipLevel:                       uint32_t = 0
                baseArrayLayer:                 uint32_t = 0
                layerCount:                     uint32_t = 1
            imageOffset:                    VkOffset3D = 0x7ffc251fc198:
                x:                              int32_t = 0
                y:                              int32_t = 0
                z:                              int32_t = 0
            imageExtent:                    VkExtent3D = 0x7ffc251fc1a4:
                width:                          uint32_t = 93
                height:                         uint32_t = 93
                depth:                          uint32_t = 1

Thread 0, Frame 0, Time 18375 us:
vkCmdPipelineBarrier(commandBuffer, srcStageMask, dstStageMask, dependencyFlags, memoryBarrierCount, pMemoryBarriers, bufferMemoryBarrierCount, pBufferMemoryBarriers, imageMemoryBarrierCount, pImageMemoryBarriers) returns void:
    commandBuffer:                  VkCommandBuffer = 0x563c2d05cd80
    srcStageMask:                   VkPipelineStageFlags = 4096 (VK_PIPELINE_STAGE_TRANSFER_BIT)
    dstStageMask:                   VkPipelineStageFlags = 1 (VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT)
    dependencyFlags:                VkDependencyFlags = 1 (VK_DEPENDENCY_BY_REGION_BIT)
    memoryBarrierCount:             uint32_t = 0
    pMemoryBarriers:                const VkMemoryBarrier* = 0x7ffc251fc748
    bufferMemoryBarrierCount:       uint32_t = 0
    pBufferMemoryBarriers:          const VkBufferMemoryBarrier* = 0x7ffc251fc788
    imageMemoryBarrierCount:        uint32_t = 1
    pImageMemoryBarriers:           const VkImageMemoryBarrier* = 0x7ffc251fc958
        pImageMemoryBarriers[0]:        const VkImageMemoryBarrier = 0x7ffc251fc958:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER (45)
            pNext:                          const void* = NULL
            srcAccessMask:                  VkAccessFlags = 4096 (VK_ACCESS_TRANSFER_WRITE_BIT)
            dstAccessMask:                  VkAccessFlags = 0 (VK_ACCESS_NONE_KHR)
            oldLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL (7)
            newLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL (5)
            srcQueueFamilyIndex:            uint32_t = 4294967295
            dstQueueFamilyIndex:            uint32_t = 4294967295
            image:                          VkImage = 0x563c2d06fbb0
            subresourceRange:               VkImageSubresourceRange = 0x7ffc251fc988:
                aspectMask:                     VkImageAspectFlags = 1 (VK_IMAGE_ASPECT_COLOR_BIT)
                baseMipLevel:                   uint32_t = 0
                levelCount:                     uint32_t = 1
                baseArrayLayer:                 uint32_t = 0
                layerCount:                     uint32_t = 1

Thread 0, Frame 0, Time 18417 us:
vkEndCommandBuffer(commandBuffer) returns VkResult VK_SUCCESS (0):
    commandBuffer:                  VkCommandBuffer = 0x563c2d05cd80

Compare and contrast with the API calls from the C++ example:

Thread 0, Frame 0, Time 23076 us:
vkBeginCommandBuffer(commandBuffer, pBeginInfo) returns VkResult VK_SUCCESS (0):
    commandBuffer:                  VkCommandBuffer = 0x55a6ab3b7280
    pBeginInfo:                     const VkCommandBufferBeginInfo* = 0x7ffcd4cd7000:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO (42)
        pNext:                          const void* = NULL
        flags:                          VkCommandBufferUsageFlags = 1 (VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT)
        pInheritanceInfo:               const VkCommandBufferInheritanceInfo* = UNUSED

Thread 0, Frame 0, Time 23101 us:
vkCmdPipelineBarrier(commandBuffer, srcStageMask, dstStageMask, dependencyFlags, memoryBarrierCount, pMemoryBarriers, bufferMemoryBarrierCount, pBufferMemoryBarriers, imageMemoryBarrierCount, pImageMemoryBarriers) returns void:
    commandBuffer:                  VkCommandBuffer = 0x55a6ab3b7280
    srcStageMask:                   VkPipelineStageFlags = 16384 (VK_PIPELINE_STAGE_HOST_BIT)
    dstStageMask:                   VkPipelineStageFlags = 4096 (VK_PIPELINE_STAGE_TRANSFER_BIT)
    dependencyFlags:                VkDependencyFlags = 0
    memoryBarrierCount:             uint32_t = 0
    pMemoryBarriers:                const VkMemoryBarrier* = NULL
    bufferMemoryBarrierCount:       uint32_t = 0
    pBufferMemoryBarriers:          const VkBufferMemoryBarrier* = NULL
    imageMemoryBarrierCount:        uint32_t = 1
    pImageMemoryBarriers:           const VkImageMemoryBarrier* = 0x7ffcd4cd7020
        pImageMemoryBarriers[0]:        const VkImageMemoryBarrier = 0x7ffcd4cd7020:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER (45)
            pNext:                          const void* = NULL
            srcAccessMask:                  VkAccessFlags = 0 (VK_ACCESS_NONE_KHR)
            dstAccessMask:                  VkAccessFlags = 4096 (VK_ACCESS_TRANSFER_WRITE_BIT)
            oldLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_UNDEFINED (0)
            newLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL (7)
            srcQueueFamilyIndex:            uint32_t = 0
            dstQueueFamilyIndex:            uint32_t = 0
            image:                          VkImage = 0x55a6ab3297d0
            subresourceRange:               VkImageSubresourceRange = 0x7ffcd4cd7050:
                aspectMask:                     VkImageAspectFlags = 1 (VK_IMAGE_ASPECT_COLOR_BIT)
                baseMipLevel:                   uint32_t = 0
                levelCount:                     uint32_t = 1
                baseArrayLayer:                 uint32_t = 0
                layerCount:                     uint32_t = 1

Thread 0, Frame 0, Time 23515 us:
vkCmdCopyBufferToImage(commandBuffer, srcBuffer, dstImage, dstImageLayout, regionCount, pRegions) returns void:
    commandBuffer:                  VkCommandBuffer = 0x55a6ab3b7280
    srcBuffer:                      VkBuffer = 0x55a6ab325a50
    dstImage:                       VkImage = 0x55a6ab3297d0
    dstImageLayout:                 VkImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL (7)
    regionCount:                    uint32_t = 1
    pRegions:                       const VkBufferImageCopy* = 0x55a6ab4661c0
        pRegions[0]:                    const VkBufferImageCopy = 0x55a6ab4661c0:
            bufferOffset:                   VkDeviceSize = 0
            bufferRowLength:                uint32_t = 0
            bufferImageHeight:              uint32_t = 0
            imageSubresource:               VkImageSubresourceLayers = 0x55a6ab4661d0:
                aspectMask:                     VkImageAspectFlags = 1 (VK_IMAGE_ASPECT_COLOR_BIT)
                mipLevel:                       uint32_t = 0
                baseArrayLayer:                 uint32_t = 0
                layerCount:                     uint32_t = 1
            imageOffset:                    VkOffset3D = 0x55a6ab4661e0:
                x:                              int32_t = 0
                y:                              int32_t = 0
                z:                              int32_t = 0
            imageExtent:                    VkExtent3D = 0x55a6ab4661ec:
                width:                          uint32_t = 512
                height:                         uint32_t = 256
                depth:                          uint32_t = 1

Thread 0, Frame 0, Time 24231 us:
vkCmdPipelineBarrier(commandBuffer, srcStageMask, dstStageMask, dependencyFlags, memoryBarrierCount, pMemoryBarriers, bufferMemoryBarrierCount, pBufferMemoryBarriers, imageMemoryBarrierCount, pImageMemoryBarriers) returns void:
    commandBuffer:                  VkCommandBuffer = 0x55a6ab3b7280
    srcStageMask:                   VkPipelineStageFlags = 4096 (VK_PIPELINE_STAGE_TRANSFER_BIT)
    dstStageMask:                   VkPipelineStageFlags = 128 (VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT)
    dependencyFlags:                VkDependencyFlags = 0
    memoryBarrierCount:             uint32_t = 0
    pMemoryBarriers:                const VkMemoryBarrier* = NULL
    bufferMemoryBarrierCount:       uint32_t = 0
    pBufferMemoryBarriers:          const VkBufferMemoryBarrier* = NULL
    imageMemoryBarrierCount:        uint32_t = 1
    pImageMemoryBarriers:           const VkImageMemoryBarrier* = 0x7ffcd4cd7020
        pImageMemoryBarriers[0]:        const VkImageMemoryBarrier = 0x7ffcd4cd7020:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER (45)
            pNext:                          const void* = NULL
            srcAccessMask:                  VkAccessFlags = 0 (VK_ACCESS_NONE_KHR)
            dstAccessMask:                  VkAccessFlags = 32 (VK_ACCESS_SHADER_READ_BIT)
            oldLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL (7)
            newLayout:                      VkImageLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL (5)
            srcQueueFamilyIndex:            uint32_t = 0
            dstQueueFamilyIndex:            uint32_t = 0
            image:                          VkImage = 0x55a6ab3297d0
            subresourceRange:               VkImageSubresourceRange = 0x7ffcd4cd7050:
                aspectMask:                     VkImageAspectFlags = 1 (VK_IMAGE_ASPECT_COLOR_BIT)
                baseMipLevel:                   uint32_t = 0
                levelCount:                     uint32_t = 1
                baseArrayLayer:                 uint32_t = 0
                layerCount:                     uint32_t = 1

Thread 0, Frame 0, Time 24244 us:
vkEndCommandBuffer(commandBuffer) returns VkResult VK_SUCCESS (0):
    commandBuffer:                  VkCommandBuffer = 0x55a6ab3b7280

The full API call dumps are also attached.

I'll keep trying to tweak things, but I don't really know anything about pipeline barriers, so I'm mostly making wild guesses as to how this can be fixed.

vulkan_samples.txt capture.txt

Most functions in Vulkan can return VK_ERROR_OUT_OF_HOST_MEMORY and VK_ERROR_OUT_OF_DEVICE_MEMORY. In fact most functions can only return one of these two errors.

This is reflected in vulkano by the fact that a lot of functions can return OomError.

However in practice it is very unlikely that an out-of-memory error actually happens, with the exception of vkAllocateMemory.

The API would be much more convenient to use if an out of memory error returned by Vulkan resulted in a panic instead of returning an error, like it's the case for the core Rust. Again, with the exception of DeviceMemory which would still return OomError.

With 0.22 I get a lot of validation errors when recording draw commands. The offending code is always similar to this:

for mesh in &obj.meshes {
    let set = Arc::new(
        PersistentDescriptorSet::start(layout.clone())
            .add_buffer(light.uniform_buffer())
            .unwrap()
            .add_buffer(model_ub.clone())
            .unwrap()
            .build()
            .unwrap(),
    );

    builder
        .draw_indexed(
            shadow_pipeline.clone(),
            &dynamic_state,
            mesh.vb.clone(),
            mesh.ib.clone(),
            set,
            (),
            vec![],
        )
        .unwrap();
}

i.e. some loop that records draw commands and re-uses the same uniform buffer(s) over and over again. The error is always of the form

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: SyncCommandBufferBuilderError(Conflict { command1_name: "vkCmdBindDescriptorSets", command1_param: "Buffer bound to descriptor 0 of set 0", command1_offset: 4, command2_name: "vkCmdBindDescriptorSets", command2_param: "Buffer bound to descriptor 0 of set 0", command2_offset: 8 })', src/main.rs:533:42

The error is returned by the draw_indexed call. This code worked in 0.21 but stopped working when I upgraded to 0.22. I tried upgrading to 0.22 because I had similar issues (also conflicts but with images instead of buffers and only in a new piece of code that isn't involved here) and thought the overhauled image code in 0.22 could solve my problems. But now I have buffer problems :D

Is there already a fix for this? I'm also fine with patching up vulkano myself and just remove some validation code for now. Would be nice if someone can give me a hint where this could come from.

You can probably reproduce this issue when porting the examples to 0.22.

I ran into the same problems that issue #1578 described when using RenderDoc to replay Vulkan commands and traced it down to vulkano inserting image memory barriers at the beginning of the renderpass that transitionend my textures from UNDEFINED to VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. This caused RenderDoc to fill the texture with a pattern for recognising discarded resources.

They do this because according to the vulkan specification:

Layout transitions always apply to a particular image subresource range, and specify both an old layout and new layout. [...] If the old layout is VK_IMAGE_LAYOUT_UNDEFINED, the contents of that range may be discarded.

Although this doesn't actually cause issues on my machine (NVIDIA GPU) this should probably still be fixed for correctness and to remove unneccessary image memory barriers. I removed the default implementation of the layout_initialized and is_layout_initialized functions of the ImageAccess trait and implemented these for all remaining vulkano types that implement ImageAccess.

This is a breaking change for anyone that currently implements the ImageAccess trait.

fixes #1578 fixes #1595

Entries for Vulkano changelog:

• Breaking the first CommandBuffer that uses images will now initialize their layout which means the execution of the first command buffer that uses an image should be finished before recording more command buffers that use the image
• Breaking the ImageAccess trait now requires the implementation of the layout_initialized() and current_layout() functions, removed the layout_initialized(), initial_layout_requirement() and forced_undefined_initial_layout() functions and changed the unlock() function to always receive the image layout that a command buffer transitioned to
• Breaking the check_image_access() function should no longer ignore Undefined layouts
• fixed incorrect layout transitions that caused issues when using RenderDoc
• implemented is_layout_initialized(), try_gpu_lock() and unlock() correctly for all image access types

I'm using a 2017 MacBook Pro with Intel Iris Graphics 550 1536 MB and a 2560 x 1600 display.

The example builds successfully, and when I run it, it starts fine, printing some messages, including: [mvk-info] You require a license for the MoltenVK Vulkan Core feature set. Reverting to evaluation mode

After that, it panics when creating a new Swapchain. The error is UnsupportedDimensions. Debug-printing the dimensions passed to the new method, the dimensions turn out to be [2048, 1536]. The device capabilities are

Capabilities {
	min_image_count: 2,
	max_image_count: Some(2),
	current_extent: Some([1024, 768]),
	min_image_extent: [1024, 768],
	max_image_extent: [1024, 768],
	max_image_array_layers: 1, 
	supported_transforms: SupportedSurfaceTransforms {
		identity: true, 
		rotate90: false, 
		rotate180: false, 
		rotate270: false, 
		horizontal_mirror: false, 
		horizontal_mirror_rotate90: false, 
		horizontal_mirror_rotate180: false, 
		horizontal_mirror_rotate270: false, 
		inherit: false
	}, 
	current_transform: Identity, 
	supported_composite_alpha: SupportedCompositeAlpha {
		opaque: true, 
		pre_multiplied: true, 
		post_multiplied: true, 
		inherit: false
	}, 
	supported_usage_flags: ImageUsage {
		transfer_source: true, 
		transfer_destination: true, 
		sampled: true, 
		storage: true, 
		color_attachment: true, 
		depth_stencil_attachment: false, 
		transient_attachment: false, 
		input_attachment: false
	}, 
	supported_formats: [
		(B8G8R8A8Unorm, SrgbNonLinear),
		(B8G8R8A8Srgb, SrgbNonLinear),
		(R16G16B16A16Sfloat, SrgbNonLinear)
	], 
	present_modes: SupportedPresentModes {
		immediate: false, 
		mailbox: false, 
		fifo: true, 
		relaxed: false
	}
}

So it seems that it fails because of the max/min image extent checks.

I'm not knowledgeable enough to determine which of these values are wrong, but if I understand the meaning of max/min_image_extent capabilities right, it seems odd to me that the device supports only that. What should I do to fix this or to diagnose the problem further?

Details

• Version of vulkano: 0.18.0
• OS: Windows
• GPU (the selected PhysicalDevice): AMD Radeon 7
• GPU Driver: https://www.amd.com/en/support/kb/release-notes/rn-rad-win-20-4-2
• Minimal reproducible example: vulkano-test.zip

Issue

Upon compilation of the project (see minimal reproducible example) using cargo run the compilation errors occur:

Clicking 'OK' leads to:

And a continuous series of said errors until it exits (https://pastebin.com/cMYPNB9W):

Installation

To illustrate steps taken in installation:

1: Rust toolchain:

C:\Users\jonat>rustup show
Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\jonat\.rustup

installed toolchains
--------------------

stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)

active toolchain
----------------

stable-x86_64-pc-windows-msvc (default)
rustc 1.41.1 (f3e1a954d 2020-02-24)

2: Build tools for visual studio 2017 installed:

3+4: MSYS2 installed and given command ran:

jonat@DESKTOP-JFC6RHS MSYS ~
$ pacman --noconfirm -Syu mingw-w64-x86_64-cmake mingw-w64-x86_64-python2 mingw-w64-x86_64-ninja:: Synchronising package databases...
 mingw32 is up to date
 mingw64 is up to date
 msys is up to date
warning: mingw-w64-x86_64-cmake-3.17.3-1 is up to date -- reinstalling
warning: mingw-w64-x86_64-python2-2.7.18-1 is up to date -- reinstalling
warning: mingw-w64-x86_64-ninja-1.10.0-1 is up to date -- reinstalling
:: Starting core system upgrade...
 there is nothing to do
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (3) mingw-w64-x86_64-cmake-3.17.3-1  mingw-w64-x86_64-ninja-1.10.0-1
             mingw-w64-x86_64-python2-2.7.18-1

Total Installed Size:  133.02 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n]
(3/3) checking keys in keyring                                  [#################################] 100%
(3/3) checking package integrity                                [#################################] 100%
(3/3) loading package files                                     [#################################] 100%
(3/3) checking for file conflicts                               [#################################] 100%
(3/3) checking available disk space                             [#################################] 100%
:: Processing package changes...
(1/3) reinstalling mingw-w64-x86_64-cmake                       [#################################] 100%
(2/3) reinstalling mingw-w64-x86_64-python2                     [#################################] 100%
(3/3) reinstalling mingw-w64-x86_64-ninja                       [#################################] 100%

jonat@DESKTOP-JFC6RHS MSYS ~
$

5: MSYS2 MINGW64 binary path added to path variable:

So, what have I done wrong?

• Version of vulkano: 1.2.202
• OS: archlinux gnome
• GPU (the selected PhysicalDevice): nvidia
• GPU Driver: NVIDIA GeForce MX450
• Upload of a reasonably minimal complete main.rs file that demonstrates the issue: all your example files,

Any example file. I run the run_all.sh, and cannot get a winit window, the error is like "thread 'main' panicked at 'unexpected error: InitializationFailed', /home/cht/git/vulkano/vulkano/src/swapchain/swapchain.rs:1120:18 "

• Version of vulkano: 0.12
• OS: Void Linux
• GPU (the selected PhysicalDevice): Vega 56
• GPU Driver: radv (Linux 5.0.17 / Mesa 19.0.4)
• Example: https://gist.githubusercontent.com/AustinJ235/0ba19d35d61a90b4358384323a4d57b6/raw/80762476e40ab4c549b336f4bff69a86b23f6375/main.rs

Sadly, the new version of vulkano fails to build on computer.

error: /home/austin/Workspace/vulkano/target/debug/deps/libvulkano_shaders-ab78b8590e7207b0.so: undefined symbol: _ZN7glslang8TProgram10getInfoLogEv
   --> examples/src/bin/image/main.rs:289:5
    |
289 |     vulkano_shaders::shader!{
    |     ^^^^^^^^^^^^^^^

error: aborting due to previous error

I would like to test the examples but I am running into some problems.

On Linux with a NVIDA 1060 I get this error:

➜  vulkano-examples git:(master) cargo run --bin triangle
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/triangle`
thread 'main' panicked at 'failed to create Vulkan instance: LoadingError(LibraryLoadFailure("libvulkan.so.1: cannot open shared object file: No such file or directory"))', /checkout/src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Do I need to install something from Vulkan?

On MacOS I get this error:

  = note: ld: framework not found MoltenVK
          clang: error: linker command failed with exit code 1 (use -v to see invocation)


error: aborting due to previous error

error: Could not compile `vulkano-examples`.

Do I need to install anything on macOS to make it work?

Thank you very much for any help.

The goal of this PR is to make creating and using custom vertex buffer layouts easier and allow them to leverage a pre-existing VertexDefinition implementation. This will also allow vertex types derived from Vertex to interact with custom runtime created ones.

Here is some pseudo-code to illustrate the idea:

#[repr(C)]
#[derive(Clone, Copy, Debug, Default, Zeroable, Pod, Vertex)]
struct InstanceData {
    #[format(R32G32_SFLOAT)]
    position_offset: [f32; 2],
    #[format(R32_SFLOAT)]
    scale: f32,
}

// There is no runtime vertex buffer builder helper yet, but just image there is :)
const ATTRIBUTE_POSITION: VertexAttribute = VertexAttribute::new("position", Format::R32G32_SFLOAT);
const ATTRIBUTE_COLOR: VertexAttribute = VertexAttribute::new("color", Format::R32G32B32_SFLOAT);

let (buffer, info) = RuntimeVertexBufferBuilder::new()
        .add(
            ATTRIBUTE_POSITION,
            vec![
                Vec2::new(-0.5, -0.25),
                Vec2::new(0.0, 0.5),
                Vec2::new(0.25, -0.1),
            ],
        )
       .build();

// Both can be used together and leverage the matching logic previously implemented by `BuffersDefinition`
let pipeline = GraphicsPipeline::start()
        .vertex_input_state([info.per_vertex(), InstanceData::per_instance()])

1. [ ] Update documentation to reflect any user-facing changes - in this repository.

2. [ ] Make sure that the changes are covered by unit-tests.

3. [ ] Run cargo fmt on the changes.

4. [ ] Please put changelog entries in the description of this Pull Request if knowledge of this change could be valuable to users. No need to put the entries to the changelog directly, they will be transferred to the changelog file by maintainers right after the Pull Request merge.

   Please remove any items from the template below that are not applicable.

5. [ ] Describe in common words what is the purpose of this change, related Github Issues, and highlight important implementation aspects.

Changelog:

### Public dependency updates
- [some_crate](https://crates.io/crates/some_crate) 1.0
 
### Breaking changes
Changes to `Foo`:
- Renamed to `Bar`.

### Additions
- Support for the `khr_foobar` extension.

### Bugs fixed
- `bar` panics when calling `foo`.

Hi,

I'm currently using vulkano in a personal project as my main access to Vulkan. In many ways it's so much nicer than normal ash or other direct vulkan access, whilst retaining a tight level of control. Especially coming from OpenGL, whilst Vulkan means more boilerplate, I also finally understand how everything ties together.

One aspect of Vulkano that I've avoided in my project until now is the use of GpuFuture. Whilst the API is simple to use, I also feel it oversimplifies vulkan synchronization and results in some strange behavior like #1705 .

I've spent some time trying to narrow down this disconnect between Vulkan <-> GpuFuture recently, as I'd like to be comfortable using the simpler GpuFuture API (especially as the raw Submit API has been changed after vulkano 0.31).

From my research the main issue seems to be that GpuFuture actually takes care of multiple concerns, that may be better adressed individually:

1. Buffering multiple queue operations (anything before calling flush).
2. Handling synchronization between queue operations (then_execute, then_signal_semaphore, then_signal_fence).
3. Representing an event that will happen on the GPU in the future and cleaning up resources when the event has happened. (cleanup_finished, signal_finished, etc.).

Because GpuFuture takes care of all three of these, it ends up handling none of them perfectly. GpuFuture also ends up creating a tree, instead of a DAG, which is what synchronization with multiple queues actually is.

Of course I'm willing to contribute myself but don't want to waste time implementing something that other maintainers don't agree on. This is why I'm asking for comments and suggestions in this issue before I start implementing.

My current thoughts look something like this:

• Outsource concerns 1&2 into a submission builder, similar to the previous SubmitCommandBufferBuilder. This approach seems to be even outlined in DESIGN.md.
• Change GpuFuture to only represent an event that has been submitted and will happen in the future on a GPU.

We can create futures for the vulkan synchronization primitives to allow for manual synchronization. This would also allow us to use type restrictions for inter-future dependencies. e.g.:

• A SubmissionBuilder can only wait for SemaphoreFutures or TimelineSemaphoreFutures.
• Only the CPU can wait on a Fence, not another queue operation.

Proposed API - triangle example

let (fence, present) = previous_frame_end.take();
fence.wait();

// Result always needs to include either a SemaphoreFuture, FenceFuture or both so that there is some synchronization primitive to wait on.
let acquisition = swapchain.acquire_next_image(SwapchainAcquireInfo {
    signal_semaphore: true,
    ..Default::default()
});

let mut submission_builder = render_queue.submit();
let draw_semaphore = submission_builder
    .after(acquisition.semaphore.take())
    .commands(command_buffer)
    .signal_semaphore();
let draw_fence = submission_builder.submit_with_fence(); // returns a `FenceFuture`

let present_future = present_queue.present(SwapchainPresentInfo {
    wait_for: draw_semaphore,
    ..SwapchainPresentInfo::swapchain_image_index(swapchain, acquisition.image_index)
});
let previous_frame_end = (draw_fence, present_future);

Compare this to the old API:

let acquire_future = acquire_next_image(swapchain.clone(), None); // simplified

let future = previous_frame_end
    .take()
    .unwrap()
    .join(acquire_future)
    .then_execute(queue.clone(), command_buffer)
    .unwrap()
    .then_swapchain_present(
        queue.clone(),
        SwapchainPresentInfo::swapchain_image_index(swapchain.clone(), image_index),
    )
    .then_signal_fence_and_flush();

Whilst the old API is shorter, it also tries to hide some important details:

• the command_buffer queue might be a different one compared to the swapchain present queue, which would require a semaphore. This is currently missing.
• swapchain_present cannot signal a fence, so then_signal_fence_and_flush has to add an empty queue submission (possibly on the wrong queue).
• Signalling multiple semaphores after command buffer execution isn't possible. The documentation of GpuFuture even lists this as a ToDo.

What this tries to solve

• #1705
• Synchronization between multiple queues (multiple calls to signal_semaphore possible)
  • Futures will then represent a dependency-DAG, which is the correct representation.
• Potentially: #1882 (Add TimelineSemaphoreFuture and appropriate functions to SubmissionBuilder)

Open Questions

• What happens if a SemaphoreFuture is just dropped? Nothing ever waits for the Semaphore... Do we just panic? - I believe this is already an issue today.
• How exactly would futures share the "source event". E.g. a SemaphoreFuture and a FenceFuture would refer to the same submission. If any of them finish, the others would be finished as well.
• Exact GpuFuture trait API (draft see below)

New GpuFuture trait:

Should include the following:

unsafe fn signal_finished(&self);
fn cleanup_finished(&self);
fn finished(&self) -> bool;
// blocking wait until this future has finished (basically drop impl)
// Ideally should only be used with fences.
fn wait(&mut self);

1. [x] Update documentation to reflect any user-facing changes - in this repository. I didn't see any documentation of features, so there is no documentation to update.

2. [x] Make sure that the changes are covered by unit-tests. All existing tests still build. I can add a trivial duplication of some existing test (e.g. triangle-v1_3) that builds without Wayland if wanted.

3. [x] Run cargo fmt on the changes. Done

4. [x] Please put changelog entries in the description of this Pull Request Done

5. [x] Describe in common words what is the purpose of this change, related Wayland support in winit is still immature and pulls in some non-Rust libraries that need to be installed in the system package manager (yuck! Rust is supposed to get away from that), and on Nvidia Wayland is still pretty unstable. Given this, I prefer to not build with Wayland enabled in my applications. When using vulkano-win, however, the winit features for Wayland are enabled even if I disable them in winit in my own Cargo.toml since vulkano-win relies on winit having all default features enabled. This PR adds a default feature to vulkano-win and a simple code change to support operation in Xorg-only mode when vulkano-win is also configured to not have the wayland feature enabled. The merits of disabling Wayland are a different discussion — I think that it is quite reasonable to let developer of each program make this decision for their own program, which is what this PR allows.

Changelog:

### Breaking changes
None, since the feature is default

### Additions
- Added default (as to be non-breaking) wayland feature to vulkan-win that a user can disable in order to build vulkano-win without Wayland support

### Bugs fixed
None

To test, just modify triangle.rs or something to use the wrong framebuffer:

                            ..RenderPassBeginInfo::framebuffer(
--                            framebuffers[image_index as usize].clone(),
++                            framebuffers[(framebuffers()-1) - image_index as usize].clone(),
                            )

On my machine, the first few frames get rendered before it eventually hits a ResourceAccessError due to race conditions, but for safety, it really should error on the very first command buffer execution.

Looking though the code, swapchain's check_image_access just ignores it, because it's doesn't belong to it, and then it falls down the ImageState::check_gpu_write path which succeeds when it shouldn't.

Creating a queue using a QueueCreateInfo struct requires passing the queue family index. However, the queue_family_properties() method of a physical device returns an iterator of QueueFamilyProperties, which do not store their index. The examples use the enumerate() method of iterators to get the index of the families in the queue_family_properties iterator, however this is unintuitive and requires casting the usize index to the u32 that vulkano expects. Adding the index field to the QueueFamilyProperties struct would make this much simpler and more intuitive, as would passing that struct directly to the QueueCreateInfo struct.

I ran across an issue while trying to create an ImmutableImage to back a CubeArray. I'm getting an error saying ImageNotCubeCompatible, which is explained in the documentation:

ImageNotCubeCompatible A cube image view type was requested, but the image was not created with the cube_compatible flag.

I see that ImmutableImage::from_iter is calling ImmutableImage::from_buffer, which has the flags hard coded to be empty:

let flags = ImageCreateFlags::empty();

I believe that ImmutableImage is the appropriate type to use for CubeArray, because I just intend to write once and never again. It looks like as a workaround I could use ImmutableImage::uninitialized to specify the flags, but then I would have replicate the functionality of ImmutableImage::from_buffer to create a command buffer builder and perform the one-time write into the initializer, and also potentially generate mipmaps.

In summary, my request is that ImageCreateFlags should be added as a parameter to ImmutableImage::from_iter and ImmutableImage::from_buffer.