Safe and rich Rust wrapper around the Vulkan API

Overview

Vulkano

Crates.io Docs Build Status Gitter chat

See also vulkano.rs.

Vulkano is a Rust wrapper around the Vulkan graphics API. It follows the Rust philosophy, which is that as long as you don't use unsafe code you shouldn't be able to trigger any undefined behavior. In the case of Vulkan, this means that non-unsafe code should always conform to valid API usage.

What does vulkano do?

  • Provides a low-levelish API around Vulkan. It doesn't hide what it does, but provides some comfort types.
  • Plans to prevent all invalid API usages, even the most obscure ones. The purpose of vulkano is not to simply let you draw a teapot, but to cover all possible usages of Vulkan and detect all the possible problems in order to write robust programs. Invalid API usage is prevented thanks to both compile-time checks and runtime checks.
  • Can handle synchronization on the GPU side for you (unless you choose do that yourself), as this aspect of Vulkan is both annoying to handle and error-prone. Dependencies between submissions are automatically detected, and semaphores are managed automatically. The behavior of the library can be customized thanks to unsafe trait implementations.
  • Tries to be convenient to use. Nobody is going to use a library that requires you to browse the documentation for hours for every single operation.

Note that in general vulkano does not require you to install the official Vulkan SDK. This is not something specific to vulkano (you don't need the SDK to write programs that use Vulkan, even without vulkano), but many people are unaware of that and install the SDK thinking that it is required. However, macOS and iOS platforms do require a little more Vulkan setup since it is not natively supported. See below for more details.

Development status

Vulkano is still in heavy development and doesn't yet meet its goals of being very robust. However the general structure of the library is most likely definitive, and all future breaking changes will likely be straight-forward to fix in user code.

Documentation

To get started you are encouraged to use the following resources:

  • The guide on vulkano.rs - Starts with trivial compute examples (~50 lines of code) then works up to rendering triangles and mandelbrots.
  • The vulkano-examples repository - Includes examples in the repo and also a list of projects that use vulkano.
  • docs.rs - Full Vulkano API documentation

Setup

Vulkano uses shaderc-rs for shader compilation. Refer to shaderc-rs documentation to provide a pre-built libshaderc for faster build times.

Unless you provide libshaderc, in order to build libshaderc with the shaderc-sys crate, the following tools must be installed and available on PATH:

  • CMake
  • Ninja Is optional except when building with MSVC. It may speed up build time for libshaderc.
  • Python (works with both Python 2.x and 3.x, on windows the executable must be named python.exe)

These requirements can be either installed with your favourite package manager or with installers from the projects' websites. Below are some example ways to get setup.

windows-msvc Specific Setup

  1. rustup default stable-x86_64-pc-windows-msvc
  2. Install Build Tools for Visual Studio 2017. If you have already been using this toolchain then its probably already installed.
  3. Install msys2, following ALL of the instructions.
  4. Then in the msys2 terminal run: pacman --noconfirm -Syu mingw-w64-x86_64-cmake mingw-w64-x86_64-python2 mingw-w64-x86_64-ninja
  5. Add the msys2 mingw64 binary path to the PATH environment variable.

Windows-gnu Specific Setup

windows-gnu toolchain is not supported but you can instead cross-compile to windows-gnu from windows-msvc

Steps 1 and 2 are to workaround https://github.com/rust-lang/rust/issues/49078 by using the same mingw that rust uses.

  1. Download and extract https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/x86_64-6.3.0-release-posix-seh-rt_v5-rev2.7z
  2. Add the absolute path to mingw64\bin to your PATH environment variable. (This path needs to be before the msys2 path)
  3. Run the command: rustup default stable-x86_64-pc-windows-msvc
  4. Run the command: rustup target install x86_64-pc-windows-gnu
  5. Install Build Tools for Visual Studio 2017. If you have already been using this toolchain then its probably already installed.
  6. Install msys2, following ALL of the instructions.
  7. Then in the msys2 terminal run: pacman --noconfirm -Syu mingw64/mingw-w64-x86_64-pkg-config mingw-w64-x86_64-gcc mingw-w64-x86_64-cmake mingw-w64-x86_64-make mingw-w64-x86_64-python2 mingw-w64-x86_64-ninja
  8. Add the msys2 mingw64 binary path to the PATH environment variable.
  9. Any cargo command that builds the project needs to include --target x86_64-pc-windows-gnu e.g. to run: cargo run --target x86_64-pc-windows-gnu

Linux Specific Setup

Use your package manager to install the required dev-tools and vulkan drivers

For example on ubuntu:

sudo apt-get install build-essential git python cmake libvulkan-dev vulkan-utils

On arch based system

sudo pacman -Sy base-devel git python cmake vulkan-devel --noconfirm

macOS and iOS Specific Setup

Vulkan is not natively supported by macOS and iOS. However, there exists MoltenVK an open-source Vulkan implementation on top of Apple's Metal API. This allows vulkano to build and run on macOS and iOS platforms.

The easiest way to get vulkano up and running with MoltenVK is to install the Vulkan SDK for macOS. There are installation instructions on the LunarG website.

On iOS, vulkano links directly to the MoltenVK framework. There is nothing else to do besides installing it. Note that the Vulkan SDK for macOS also comes with the iOS framework.

Donate

Austin Johnson (Active maintainer) Become a patron

Rukai (Current maintainer) Become a patron

Tomaka (Original developer) Become a patron

Contributing

Contributions are welcome! Feel free to submit pull requests.

Pull requests that fix bugs or improve documentation are likely to be quickly reviewed, while pull requests that add features or change the API may be more controversial and take more time.

If your change adds, removes or modifies a trait or a function, please add an entry to the CHANGELOG.md file as part of your pull request.

Structure

This repository contains four libraries:

  • vulkano is the main one.
  • vulkano-shaders Provides the shader! macro for compiling glsl shaders.
  • vulkano-win provides a safe link between vulkano and the winit library which can create a window to render to.
  • vk-sys contains raw bindings for Vulkan. You can use it even if you don't care about vulkano.

In order to run tests, run cargo test --all at the root of the repository. Make sure your Vulkan driver is up to date before doing so.

License

Licensed under either of

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual licensed as above, without any additional terms or conditions.

Comments
  • Support for MoltenVK

    Support for MoltenVK

    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.

    opened by tomaka 66
  • Support for Runtime Descriptor Arrays

    Support for Runtime Descriptor Arrays

    ~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[];

    opened by AustinJ235 49
  • Image Loading Fails on Intel Xe Graphics

    Image Loading Fails on Intel Xe Graphics

    • 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.

    2021-04-10T13:32:38,317578437-04:00 2021-04-10T13:30:22,210279536-04:00 vulkan_samples.txt capture.txt

    type: bug 
    opened by Cognoscan 40
  • About OomError

    About OomError

    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.

    opened by tomaka 37
  • Lots of conflicts with reused uniform buffers in 0.22

    Lots of conflicts with reused uniform buffers in 0.22

    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.

    type: bug 
    opened by faulesocke 36
  • improved image layout transitions

    improved image layout transitions

    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
    PR: Long Standing PR: In review. Comments to address. 
    opened by Timbals 29
  • The triangle example crashes with UnsupportedDimensions on MacOS 10.12 + MoltenVK

    The triangle example crashes with UnsupportedDimensions on MacOS 10.12 + MoltenVK

    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?

    type: bug 
    opened by golddranks 29
  • 'windows-msvc Specific Setup' leads to compilation error of compute example.

    'windows-msvc Specific Setup' leads to compilation error of compute example.

    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:

    image

    Clicking 'OK' leads to:

    image

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

    image

    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:

    image

    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:

    image

    So, what have I done wrong?

    type: question 
    opened by JonathanWoollett-Light 27
  • Cannot work on nvidia wayland ,at least for your examples

    Cannot work on nvidia wayland ,at least for your examples

    • 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 "

    type: bug 
    opened by Decodetalkers 23
  • 0.12 fails to build

    0.12 fails to build

    • 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
    
    opened by AustinJ235 23
  • How to run the examples

    How to run the examples

    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.

    opened by adrianbrink 23
  • Better custom vertex buffer layouts support

    Better custom vertex buffer layouts support

    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`.
    
    opened by trevex 5
  • GpuFuture - Redesign RFC

    GpuFuture - Redesign RFC

    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);
    
    opened by LeonMatthes 4
  • Added support for using vulkano-win with winit without compiling Waland support

    Added support for using vulkano-win with winit without compiling Waland support

    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
    
    opened by john01dav 1
  • check_image_access allows accessing a swapchain image before it's acquired.

    check_image_access allows accessing a swapchain image before it's acquired.

    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.

    opened by phire 0
  • Expose queue family index in `QueueFamilyProperties`

    Expose queue family index in `QueueFamilyProperties`

    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.

    opened by melvyn2 5
  • [Feature Request] Pass ImageCreateFlags into ImmutableImage::from_buffer and from_iter

    [Feature Request] Pass ImageCreateFlags into ImmutableImage::from_buffer and from_iter

    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.

    opened by gregjohnson2017 2
Releases(v0.32.0)
  • v0.32.0(Oct 31, 2022)

    What's Changed

    • Fix handling of runtime sized arrays in shaders by @Rua in https://github.com/vulkano-rs/vulkano/pull/1992
    • Hide queue operations behind a lock by @Rua in https://github.com/vulkano-rs/vulkano/pull/1993
    • Fix clippy warnings with new Rust version by @Rua in https://github.com/vulkano-rs/vulkano/pull/1996
    • Queue operations refactoring by @Rua in https://github.com/vulkano-rs/vulkano/pull/1995
    • New changelog layout by @Rua in https://github.com/vulkano-rs/vulkano/pull/1998
    • Exclude markdown from actions by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/2000
    • Updated pull request template by @Rua in https://github.com/vulkano-rs/vulkano/pull/1999
    • Make queues own the resources of executing operations by @Rua in https://github.com/vulkano-rs/vulkano/pull/2001
    • Fix feature name casing by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2003
    • Remove command_buffer::submit module, make new Queue methods public by @Rua in https://github.com/vulkano-rs/vulkano/pull/2002
    • Add new memory property flags and improve documentation by @Rua in https://github.com/vulkano-rs/vulkano/pull/2005
    • Rust 2018 idioms by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2007
    • Cache results of some PhysicalDevice methods for faster future retrieval by @Rua in https://github.com/vulkano-rs/vulkano/pull/2006
    • #2007 fixes by @Rua in https://github.com/vulkano-rs/vulkano/pull/2008
    • Add state tracking and validation to Fence by @Rua in https://github.com/vulkano-rs/vulkano/pull/2010
    • Swapchain acquisition checks by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/2009
    • #1935 add from_handle to DeviceMemory by @hsteinmueller in https://github.com/vulkano-rs/vulkano/pull/2011
    • Add support for layer extensions to VulkanLibrary by @Rua in https://github.com/vulkano-rs/vulkano/pull/2012
    • Add remaining ColorSpace variants by @Rua in https://github.com/vulkano-rs/vulkano/pull/2013
    • Add support for khr_surface_protected_capabilities extension by @Rua in https://github.com/vulkano-rs/vulkano/pull/2014
    • Improvements to caches and switch to ahash by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2019
    • Replace generics with impl Trait in function arguments by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2017
    • #[inline]ing adjustments and minor syntax/formatting changes by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2016
    • Add support for ext_validation_features by @Rua in https://github.com/vulkano-rs/vulkano/pull/2015
    • Fix clippy warnings resulting from #2016 by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2020
    • More complete shield links by @Rua in https://github.com/vulkano-rs/vulkano/pull/2021
    • Move to manual management of descriptor set and command buffer allocators by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1957
    • Fix physical device surface querying regression #2026 by removing surface caching by @lilly-lizard in https://github.com/vulkano-rs/vulkano/pull/2027
    • Fix checks from #2009 by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/2023
    • Better error message when source is too small for ImmutableImage by @Rua in https://github.com/vulkano-rs/vulkano/pull/2022
    • Add support for Unix and Windows external fences by @Rua in https://github.com/vulkano-rs/vulkano/pull/2024
    • Minor documentation fixes by @Rua in https://github.com/vulkano-rs/vulkano/pull/2025
    • Remove unneccessary muts in examples left after #1957 by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2029
    • Check for empty aspects when creating ImageView by @Rua in https://github.com/vulkano-rs/vulkano/pull/2028
    • Buffer and image uploads take a command buffer instead of making one by @Rua in https://github.com/vulkano-rs/vulkano/pull/2030
    • Fix missing validation when binding memory to buffers with the shader_device_address usage by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2031
    • Switch to an atomic counter for DeviceMemory allocations by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2033
    • Fixed queue family index count not being set in buffers and images by @daigennki in https://github.com/vulkano-rs/vulkano/pull/2034
    • #2030 doc fixes by @Rua in https://github.com/vulkano-rs/vulkano/pull/2032
    • Add safety checks to semaphores, add importing and exporting by @Rua in https://github.com/vulkano-rs/vulkano/pull/2035
    • Minor tweaks to DeviceMemory by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2038
    • Remove type parameter from Surface by @Rua in https://github.com/vulkano-rs/vulkano/pull/2036
    • Rename internal_object to handle by @Rua in https://github.com/vulkano-rs/vulkano/pull/2037
    • Move resource locking to submit function by @Rua in https://github.com/vulkano-rs/vulkano/pull/2041
    • Near-full support for VK_KHR_synchronization2 by @Rua in https://github.com/vulkano-rs/vulkano/pull/2043
    • Add checks for khr_portability_subset by @Rua in https://github.com/vulkano-rs/vulkano/pull/2044
    • Memory allocation revamp by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1997
    • Make command buffer/descriptor set allocators Sync again by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2046
    • #1997 fixes by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2049
    • Fix depth and stencil attachment check when building pipeline by @insertt in https://github.com/vulkano-rs/vulkano/pull/2052
    • Fix #2047 by @Rua in https://github.com/vulkano-rs/vulkano/pull/2048
    • Add new safe Buffer and Image types containing bound memory by @Rua in https://github.com/vulkano-rs/vulkano/pull/2050
    • Add homegrown IDs for Vulkan objects by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2054
    • Further improvements to command buffer allocation by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2053
    • Add async future for Fence Signal by @Joeoc2001 in https://github.com/vulkano-rs/vulkano/pull/2051
    • Add missing validation to DeviceMemory by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2057
    • Add validation for binding dedicated allocations by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2056
    • Update render pass checks for new VUID by @Rua in https://github.com/vulkano-rs/vulkano/pull/2055
    • Fix bug with surface_capabilities extension structs attached to the wrong parent struct by @Rua in https://github.com/vulkano-rs/vulkano/pull/2058
    • Fix unused import warnings on Windows by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/2059
    • Fix synchronization issue between command buffers by @Rua in https://github.com/vulkano-rs/vulkano/pull/2060
    • Fix some docs in the memory::allocator module by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2063
    • Add support for the requires_dedicated_allocation flag to GenericMemoryAllocator by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2062
    • Update SwapchainCreateInfo image_extent doc by @ftvkyo in https://github.com/vulkano-rs/vulkano/pull/2065
    • Fix alignment for CpuAccessibleBuffer by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2064
    • Remove unneeded panic in GenericMemoryAllocator by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2066
    • Merge single layout descriptor set pools into StandardDescriptorSetAllocator by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2067
    • Add more usage info for allocators by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2069
    • Implement allocator traits for allocators wrapped in Arcs by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2068
    • Add support for zero-sized command buffer pools by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2070
    • Use SmallVec for command buffer allocations by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2071
    • Fix StandardCommandBufferAllocator example docs by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/2072
    • Release Vulkano 0.32.0 by @Rua in https://github.com/vulkano-rs/vulkano/pull/2061

    New Contributors

    • @hsteinmueller made their first contribution in https://github.com/vulkano-rs/vulkano/pull/2011
    • @lilly-lizard made their first contribution in https://github.com/vulkano-rs/vulkano/pull/2027
    • @daigennki made their first contribution in https://github.com/vulkano-rs/vulkano/pull/2034
    • @insertt made their first contribution in https://github.com/vulkano-rs/vulkano/pull/2052
    • @Joeoc2001 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/2051
    • @ftvkyo made their first contribution in https://github.com/vulkano-rs/vulkano/pull/2065

    Full Changelog: https://github.com/vulkano-rs/vulkano/compare/v0.31.0...v0.32.0

    Source code(tar.gz)
    Source code(zip)
  • v0.31.0(Sep 18, 2022)

    What's Changed

    • Update examples link by @Nevin1901 in https://github.com/vulkano-rs/vulkano/pull/1931
    • Add VulkanLibrary as first initialization step before Instance by @Rua in https://github.com/vulkano-rs/vulkano/pull/1932
    • Update winit to 0.27 by @Rua in https://github.com/vulkano-rs/vulkano/pull/1933
    • Merged ImmutableBuffer into DeviceLocalBuffer #1934 by @pac85 in https://github.com/vulkano-rs/vulkano/pull/1936
    • Add from_handle constructors for various Vulkan object types. #1935 by @p3t3rix in https://github.com/vulkano-rs/vulkano/pull/1938
    • Remove unnecessary question mark operator and unsafe block by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1940
    • Make StandardCommandPool lockless by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1939
    • Better defaults for vulkano config by @hakolao in https://github.com/vulkano-rs/vulkano/pull/1942
    • StdDescriptorPool rewamp by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1943
    • Vulkano-shaders struct generation refactor by @Rua in https://github.com/vulkano-rs/vulkano/pull/1945
    • Changes regarding naming and API consistency by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1946
    • Use libloading instead of shared_library by @Rua in https://github.com/vulkano-rs/vulkano/pull/1947
    • Remove an unneccessary Mutex layer when accessing StandardMemoryPool by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1949
    • Ios fix by @hakolao in https://github.com/vulkano-rs/vulkano/pull/1950
    • Switch to parking_lot's Mutexes by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1951
    • Fixup some outdated code by @Rua in https://github.com/vulkano-rs/vulkano/pull/1948
    • Refactor internal error handling by @Rua in https://github.com/vulkano-rs/vulkano/pull/1952
    • Fix or allow all Clippy errors, re-enable dead code and unused variable warnings by @Rua in https://github.com/vulkano-rs/vulkano/pull/1953
    • Opaque Windows handle external memory import support by @idanraiter in https://github.com/vulkano-rs/vulkano/pull/1959
    • Autogen enhancements for InstanceExtensions, DeviceExtensions, device::Features by @Firestar99 in https://github.com/vulkano-rs/vulkano/pull/1960
    • vulkano: export LoadingError by @gurchetansingh in https://github.com/vulkano-rs/vulkano/pull/1961
    • Refactor bind/push commands by @Rua in https://github.com/vulkano-rs/vulkano/pull/1962
    • Refactor draw/dispatch commands, render pass state, improve validation checks by @Rua in https://github.com/vulkano-rs/vulkano/pull/1963
    • Macrofy all Vulkan bitflag and enum types, check for device support by @Rua in https://github.com/vulkano-rs/vulkano/pull/1964
    • Better validation and errors by @Rua in https://github.com/vulkano-rs/vulkano/pull/1966
    • Make PhysicalDevice an independent object by @Rua in https://github.com/vulkano-rs/vulkano/pull/1967
    • Add sparse image querying functions by @Rua in https://github.com/vulkano-rs/vulkano/pull/1968
    • Add DeviceMemory::commitment by @Rua in https://github.com/vulkano-rs/vulkano/pull/1969
    • Fix validation for physical device surface methods by @Rua in https://github.com/vulkano-rs/vulkano/pull/1970
    • Add khr_external_fence and remaining parts of khr_external_semaphore by @Rua in https://github.com/vulkano-rs/vulkano/pull/1972
    • Add support for all remaining surface types, add missing functions for the existing ones by @Rua in https://github.com/vulkano-rs/vulkano/pull/1973
    • Include device extension functions under instance functions if they use a physical device by @Rua in https://github.com/vulkano-rs/vulkano/pull/1974
    • Fix LayerNotPresent error in debug.rs example by @CodesOtakuYT in https://github.com/vulkano-rs/vulkano/pull/1977
    • Impl Present Wait Feature by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1965
    • Add validation to Format by @Rua in https://github.com/vulkano-rs/vulkano/pull/1975
    • Rename next and chunk methods of CpuBufferPool for consistency by @Rua in https://github.com/vulkano-rs/vulkano/pull/1978
    • Improvements to from_handle documentation and parameter order by @Rua in https://github.com/vulkano-rs/vulkano/pull/1982
    • Add support for ext_tooling_info by @Rua in https://github.com/vulkano-rs/vulkano/pull/1983
    • Add external memory support for buffers by @Rua in https://github.com/vulkano-rs/vulkano/pull/1984
    • Update Khronos URLs by @Rua in https://github.com/vulkano-rs/vulkano/pull/1986
    • Add support for ext_separate_stencil_usage, image view usages and two new layouts by @Rua in https://github.com/vulkano-rs/vulkano/pull/1985
    • Example Tweaks by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1987
    • Treat atomic writes in shaders as write accesses by @Rua in https://github.com/vulkano-rs/vulkano/pull/1989
    • Fix memory leak by @marc0246 in https://github.com/vulkano-rs/vulkano/pull/1991
    • Release 0.31 by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1990

    New Contributors

    • @Nevin1901 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1931
    • @pac85 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1936
    • @p3t3rix made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1938
    • @idanraiter made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1959
    • @Firestar99 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1960
    • @CodesOtakuYT made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1977

    Full Changelog: https://github.com/vulkano-rs/vulkano/compare/v0.30.0...v0.31.0

    Source code(tar.gz)
    Source code(zip)
  • v0.30.0(Jul 20, 2022)

    What's Changed

    • Export enum MemoryMapError by @tutan-chromium in https://github.com/vulkano-rs/vulkano/pull/1861
    • Implement new locking for UnsafeBuffer and UnsafeImage by @Rua in https://github.com/vulkano-rs/vulkano/pull/1860
    • Fix #1858 by @Rua in https://github.com/vulkano-rs/vulkano/pull/1859
    • Use range-based state tracking for SyncCommandBuffer by @Rua in https://github.com/vulkano-rs/vulkano/pull/1862
    • Reorganize code of command buffer commands based on command type by @Rua in https://github.com/vulkano-rs/vulkano/pull/1863
    • Re-export UnsafeCommandPoolCreateInfo and UnsafeCommandPoolCreationError by @Rua in https://github.com/vulkano-rs/vulkano/pull/1866
    • Redundant unsafe block removed by @Eliah-Lakhin in https://github.com/vulkano-rs/vulkano/pull/1867
    • Fix game of life example on macos by @hakolao in https://github.com/vulkano-rs/vulkano/pull/1829
    • fix for android surface acquiring by @Dimkar3000 in https://github.com/vulkano-rs/vulkano/pull/1868
    • Allow SyncCommandBufferBuilder commands to specify the access range by @Rua in https://github.com/vulkano-rs/vulkano/pull/1869
    • Add document detailing how much of Vulkan is currently covered by Vulkano by @Rua in https://github.com/vulkano-rs/vulkano/pull/1875
    • Rename debug commands, add some new ones by @Rua in https://github.com/vulkano-rs/vulkano/pull/1878
    • Rewrite copy commands by @Rua in https://github.com/vulkano-rs/vulkano/pull/1873
    • Fix debug utils message severity error by @hakolao in https://github.com/vulkano-rs/vulkano/pull/1883
    • Use only the selected range of buffer and image views in synchronization by @Rua in https://github.com/vulkano-rs/vulkano/pull/1880
    • Improve render pass commands, more validation by @Rua in https://github.com/vulkano-rs/vulkano/pull/1884
    • Disallow dispatch calls with dimensions of zero-length by @ryco117 in https://github.com/vulkano-rs/vulkano/pull/1886
    • Cleanup physical.rs after last patch by @maratik123 in https://github.com/vulkano-rs/vulkano/pull/1887
    • Raytracing shaders with vulkano-shaders by @Atilogit in https://github.com/vulkano-rs/vulkano/pull/1888
    • PresentFuture: Avoid flushing twice on flush error by @LeonMatthes in https://github.com/vulkano-rs/vulkano/pull/1889
    • Device local example by @ryco117 in https://github.com/vulkano-rs/vulkano/pull/1890
    • Fixing Module comments that were accidentally changed by @ryco117 in https://github.com/vulkano-rs/vulkano/pull/1891
    • Image extent zero length by @ryco117 in https://github.com/vulkano-rs/vulkano/pull/1893
    • Add support for dynamic rendering by @Rua in https://github.com/vulkano-rs/vulkano/pull/1902
    • Remove Default from NonExhaustive by @Rua in https://github.com/vulkano-rs/vulkano/pull/1903
    • Update dependencies by @Rua in https://github.com/vulkano-rs/vulkano/pull/1904
    • Fix #1881 by @Rua in https://github.com/vulkano-rs/vulkano/pull/1905
    • fix errors I noticed in readme by @coolbot123 in https://github.com/vulkano-rs/vulkano/pull/1906
    • Fix #1894 by @Rua in https://github.com/vulkano-rs/vulkano/pull/1908
    • Refactor query commands by @Rua in https://github.com/vulkano-rs/vulkano/pull/1909
    • Add is_signaled to FenceSignalFuture by @Rua in https://github.com/vulkano-rs/vulkano/pull/1910
    • Refactor dynamic state commands by @Rua in https://github.com/vulkano-rs/vulkano/pull/1911
    • Vulkano util proposal by @hakolao in https://github.com/vulkano-rs/vulkano/pull/1918
    • Allow setting present mode in vulkano util's window renderer by @hakolao in https://github.com/vulkano-rs/vulkano/pull/1922
    • Documentation todos by @JMicheli in https://github.com/vulkano-rs/vulkano/pull/1920
    • constness of ImageUsage constructors and more utility methods for SampleCounts by @marcot1cs in https://github.com/vulkano-rs/vulkano/pull/1924
    • Support for VK_KHR_portability_subset Devices by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1927
    • Move RangeMap into Vulkano by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1928
    • Release 0.30 by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1929

    New Contributors

    • @tutan-chromium made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1861
    • @Dimkar3000 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1868
    • @ryco117 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1886
    • @maratik123 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1887
    • @Atilogit made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1888
    • @LeonMatthes made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1889
    • @coolbot123 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1906
    • @JMicheli made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1920
    • @marcot1cs made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1924

    Full Changelog: https://github.com/vulkano-rs/vulkano/compare/v0.29.0...v0.30.0

    Source code(tar.gz)
    Source code(zip)
  • v0.29.0(Mar 11, 2022)

    What's Changed

    • A multi-window game of life application example by @hakolao in https://github.com/vulkano-rs/vulkano/pull/1812
    • Fix sync bug in same image blit/copy commands by @Amjad50 in https://github.com/vulkano-rs/vulkano/pull/1817
    • Move Unbuildable to crate root and rename to NonExhaustive by @Rua in https://github.com/vulkano-rs/vulkano/pull/1818
    • fix typo in begin_render_pass by @Overpeek in https://github.com/vulkano-rs/vulkano/pull/1821
    • fix queue 'supports_' methods with empty flags by @Overpeek in https://github.com/vulkano-rs/vulkano/pull/1822
    • Added overlapping_push_constant_ranges to PipelineLayout by @Amjad50 in https://github.com/vulkano-rs/vulkano/pull/1820
    • fix shader! macro for geometry stages failing to compile by @Overpeek in https://github.com/vulkano-rs/vulkano/pull/1823
    • Refactor VertexBuffersCollection to allow Arc by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1824
    • Add InstanceCreateInfo and DeviceCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1814
    • Add test for Version parsing by @Rua in https://github.com/vulkano-rs/vulkano/pull/1825
    • Add UnsafeBufferCreateInfo and BufferViewCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1815
    • Only include SamplerReductionModeCreateInfo if needed by @Rua in https://github.com/vulkano-rs/vulkano/pull/1827
    • Add RenderPassCreateInfo and FramebufferCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1828
    • Include raw function pointer structs in documentation by @Rua in https://github.com/vulkano-rs/vulkano/pull/1831
    • Add SwapchainCreateInfo, various related changes by @Rua in https://github.com/vulkano-rs/vulkano/pull/1832
    • Add DescriptorSetLayoutCreateInfo and PipelineLayoutCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1834
    • Vulkan 1.3 support, updated dependencies by @Rua in https://github.com/vulkano-rs/vulkano/pull/1836
    • Add MemoryAllocateInfo, improve handling of external memory by @Rua in https://github.com/vulkano-rs/vulkano/pull/1838
    • Add UnsafeCommandPoolCreateInfo, CommandBufferAllocateInfo and other changes by @Rua in https://github.com/vulkano-rs/vulkano/pull/1839
    • Add QueryPoolCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1840
    • Add CreateInfo for Event, Fence and Semaphore. by @Rua in https://github.com/vulkano-rs/vulkano/pull/1841
    • Add SamplerCreateInfo and SamplerYcbcrConversionCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1842
    • Add UnsafeDescriptorSetCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1843
    • Add UnsafeImageCreateInfo and ImageViewCreateInfo by @Rua in https://github.com/vulkano-rs/vulkano/pull/1844
    • convert fnv types into std by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1847
    • Fix validation of SPIR-V contains OpUndef by @White-Green in https://github.com/vulkano-rs/vulkano/pull/1851
    • arrays now implement VertexBufferCollection by @AustinJ235 in https://github.com/vulkano-rs/vulkano/pull/1852
    • Rework mapped memory, add BufferContents trait with bytemuck by @Rua in https://github.com/vulkano-rs/vulkano/pull/1853
    • Fixed potential overflow in multiview vertex buffer validation by @m3x3 in https://github.com/vulkano-rs/vulkano/pull/1855
    • Implement is_layout_initialized for ImmutableImage by @thanatos in https://github.com/vulkano-rs/vulkano/pull/1833
    • Release 0.29 by @Rua in https://github.com/vulkano-rs/vulkano/pull/1856

    New Contributors

    • @Overpeek made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1821
    • @White-Green made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1851
    • @m3x3 made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1855
    • @thanatos made their first contribution in https://github.com/vulkano-rs/vulkano/pull/1833

    Full Changelog: https://github.com/vulkano-rs/vulkano/compare/v0.28.0...v0.29.0

    Source code(tar.gz)
    Source code(zip)
  • v0.24.0(Jun 20, 2021)

  • v0.21.0(Mar 14, 2021)

Owner
null
Safe OpenGL wrapper for the Rust language.

glium Note to current and future Glium users: Glium is no longer actively developed by its original author. That said, PRs are still welcome and maint

null 3.1k Jan 1, 2023
GLFW3 bindings and idiomatic wrapper for Rust.

glfw-rs GLFW bindings and wrapper for The Rust Programming Language. Example extern crate glfw; use glfw::{Action, Context, Key}; fn main() { le

PistonDevelopers 546 Jan 3, 2023
A vector graphics renderer using OpenGL with a Rust & C API.

bufro A vector graphics renderer using OpenGL with a Rust & C API. A Rust example can be found in examples/quickstart.rs (using glutin). A C example c

Aspect 9 Dec 15, 2022
Rust bindings to bgfx, a cross-platform, graphics API agnostic

Rust bindings to bgfx, a cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.

Daniel Collin 65 Dec 24, 2022
Graph API client writen in Rust

graph-rs Now available on stable Rust at crates.io graph-rs-sdk = "0.1.0" 0.1.0 and above use stable Rust. Anything before 0.1.0 uses nightly Rust. M

Sean Reeise 56 Jan 3, 2023
A cool, fast maze generator and solver written in Rust

MazeCruncher Welcome to maze cruncher! Download Standalone Here Usage To get started, just run the standalone .exe in target/release or compile and ru

null 69 Sep 20, 2022
A high-performance SVG renderer, powered by Rust based resvg and napi-rs.

resvg-js resvg-js is a high-performance SVG renderer, powered by Rust based resvg and napi-rs. Fast, safe and zero dependencies! No need for node-gyp

一丝 744 Jan 7, 2023
A 2D vector graphics library optimized for GUIs, written in Rust and wgpu

RootVG A 2D vector graphics library optimized for GUIs, written in Rust and wgpu How it Works Unlike other 2D vector graphics libraries which have a s

Meadowlark 14 Jul 10, 2024
CLI for image processing with histograms, binary treshold and other functions

Image-Processing-CLI-in-Rust CLI for processing images in Rust. Some implementation is custom and for some functionality it uses 3rd party libraries.

Miki Graf 25 Jul 24, 2022
Sub-pixel precision light spot rendering library for astronomy and video tracking applications.

Planetarium Sub-pixel precision light spot rendering library for astronomy and video tracking applications. Example usage use planetarium::{Canvas, Sp

Sergey Kvachonok 5 Mar 27, 2022
A simple and elegant, pipewire graph editor

pw-viz A simple and elegant, pipewire graph editor This is still a WIP, node layouting is kinda jank at the moment. Installation A compiled binary is

null 180 Dec 27, 2022
A cargo subcommand for creating GraphViz DOT files and dependency graphs

cargo-graph Linux: A cargo subcommand for building GraphViz DOT files of dependency graphs. This subcommand was originally based off and inspired by t

Kevin K. 213 Nov 24, 2022
Szalinski: A Tool for Synthesizing Structured CAD Models with Equality Saturation and Inverse Transformations

Szalinski: A Tool for Synthesizing Structured CAD Models with Equality Saturation and Inverse Transformations

UW PLSE 24 Aug 15, 2022
Real-time 3D orientation visualization of a BNO055 IMU using Bissel and Bevy

orientation This is a demonstration of real-time visualization of the attitude of a BNO055 IMU across a wireless network to a Bevy app using the Bisse

chris m 4 Dec 10, 2022
Small, lightweight and fast library for rendering text with wgpu.

wgpu-text wgpu-text is a wrapper over glyph-brush for fast and easy text rendering in wgpu. This project was inspired by and is similar to wgpu_glyph,

Leon 20 Nov 30, 2022
Theorem relational dependencies automatic extraction and visualization as a graph for Lean4.

Lean Graph Interactive visualization of dependencies for any theorem/definitions in your Lean project. How to use In your browser: lean-graph.com Or r

Patrik Číhal 8 Jan 3, 2024
A fast, lightweight and extensible implementation of a graph data structure.

fast-graph A fast, lightweight and extensible implementation of a graph data structure. Note ⚠️ There will be some breaking changes in the coming 1-2

Henrik 34 Jul 6, 2024
A toy ray tracer in Rust

tray_rust - A Toy Ray Tracer in Rust tray_rust is a toy physically based ray tracer built off of the techniques discussed in Physically Based Renderin

Will Usher 492 Dec 19, 2022
A complete harfbuzz's shaping algorithm port to Rust

rustybuzz rustybuzz is a complete harfbuzz's shaping algorithm port to Rust. Matches harfbuzz v2.7.0 Why? Because you can add rustybuzz = "*" to your

Evgeniy Reizner 310 Dec 22, 2022