Safe and rich Rust wrapper around the Vulkan API

Last update: Jun 14, 2022

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.

GitHub

https://github.com/vulkano-rs/vulkano
Comments
  • 1. 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.

    Reviewed by tomaka at 2016-10-05 19:12
  • 2. 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[];

    Reviewed by AustinJ235 at 2021-08-17 10:04
  • 3. Image Loading Fails on Intel Xe Graphics

    • Version of vulkano: v0.22.0
    • OS: ArchLinux - Linux version 5.11.11-arch1-1 ([email protected]) (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

    Reviewed by Cognoscan at 2021-04-10 18:21
  • 4. 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.

    Reviewed by tomaka at 2016-04-03 12:02
  • 5. 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
    Reviewed by Timbals at 2021-05-20 20:14
  • 6. 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?

    Reviewed by golddranks at 2017-08-13 18:17
  • 7. 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
    
    Reviewed by AustinJ235 at 2019-05-26 05:23
  • 8. 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.

    Reviewed by adrianbrink at 2017-09-29 09:49
  • 9. Mac install

    • [x] Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
    • [x] Updated documentation to reflect any user-facing changes - in this repository

    This PR automatically downloads and installs the latest Vulkan SDK from lunarg. It will only do this if VULKAN_SDK is not set. The sdk will be installed at $HOME/.vulkan_sdk and the following environment variables will be set in the users .profile or .bash_profile

    export VULKAN_SDK=$HOME/.vulkan_sdk/macOS
    export PATH=$VULKAN_SDK/bin:$PATH
    export DYLD_LIBRARY_PATH=$VULKAN_SDK/lib:$DYLD_LIBRARY_PATH
    export VK_ICD_FILENAMES=$VULKAN_SDK/etc/vulkan/icd.d/MoltenVK_icd.json
    export VK_LAYER_PATH=$VULKAN_SDK/etc/vulkan/explicit_layer.d
    

    The only thing that isn't automated is the user will get a error about failing to link the vulkan libs. This is because the changes to their profile are not automatically refreshed. They will need to either source ~/.profile or source ~/.bash_profile or reopen their terminal after the first time they build vulkano.

    If anyone knows how to automate this that would be super useful. So far I have tried to pass the env var settings along from the build script to the lib using cargo:rustc_env but that only works if you are directly using Vulkano and not if it's a dependency.

    One thing we could do is assume that if the env vars are not set when Vulkano is run then they must just be set to the defaults and but the user has not sourced their profile. Then just std::env::set_var to set them temporarily.

    Reviewed by freesig at 2018-12-27 23:27
  • 10. Incorrect depth and weird artifacts

    Issue

    I created an example that renders a model (see following figure) but somehow the depth ordering is not correct although depth buffering is active.

    normal

    With deactivated depth test (leaving out .depth_stencil_simple_depth()), the model is rendered as follows.

    no-depth

    I don't understand why this is happening. Please note that I don't have any previous Vulkan knowledge but quite a bit of experience with OpenGL.

    Please checkout the example repository and feel free to create PR to fix the situation.

    Observations

    1. When I change the depth buffer format to D32Sfloat for example the artifacts are reduced but still present.
    2. The same artifacts appear in the teapot example when the scale matrix on this line is removed, the camera is moved back to 100 and the far plane is extended to 1000.

    Template

    • Version of vulkano: 0.17.0
    • OS: Windows 10 Pro
    • GPU (the selected PhysicalDevice): GeForce GTX 1070 (type: DiscreteGpu)
    • GPU Driver: 26.21.14.4274
    Reviewed by hpatjens at 2020-03-28 13:41
  • 11. Bug after resizing window containing swap chain

    I created a program using windows and the swapchain. The swapchain part is pretty similar to the triangle example. (I may upload it in git if you want to see. currently it's just in pijul) The problem occurs after rendering, when calling this on some result: .then_signal_fence_and_flush().unwrap(); Then the window doesn't update anymore, because it just stops there. When I wait some time, it generates an error message and a stack backtrace, I'll include:

    thread 'main' panicked at 'unexpected error: DeviceLost', /home/porky11/.cargo/registry/src/github.com-1ecc6299db9ec823/vulkano-0.7.1/src/lib.rs:161:17
    note: Run with `RUST_BACKTRACE=1` for a backtrace.
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DeviceLostError', /checkout/src/libcore/result.rs:906:4
    stack backtrace:
       0:     0x55e535584b73 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::hcae9eaf44818c983
                                   at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
       1:     0x55e53558127a - std::sys_common::backtrace::_print::h59558c687fc4cf51
                                   at /checkout/src/libstd/sys_common/backtrace.rs:71
       2:     0x55e5355863a3 - std::panicking::default_hook::{{closure}}::h48460b9cd8e002ae
                                   at /checkout/src/libstd/sys_common/backtrace.rs:60
                                   at /checkout/src/libstd/panicking.rs:381
       3:     0x55e535586112 - std::panicking::default_hook::h9a7143460d24c4d8
                                   at /checkout/src/libstd/panicking.rs:397
       4:     0x55e535586867 - std::panicking::rust_panic_with_hook::h76b4e13bdfc8824a
                                   at /checkout/src/libstd/panicking.rs:577
       5:     0x55e535586734 - std::panicking::begin_panic::hb353b753134545f4
                                   at /checkout/src/libstd/panicking.rs:538
       6:     0x55e535586639 - std::panicking::begin_panic_fmt::hd2175356d78b1606
                                   at /checkout/src/libstd/panicking.rs:522
       7:     0x55e5355865ca - rust_begin_unwind
                                   at /checkout/src/libstd/panicking.rs:498
       8:     0x55e5355b9ec0 - core::panicking::panic_fmt::he3a4d8a4eb6d8e51
                                   at /checkout/src/libcore/panicking.rs:71
       9:     0x55e5353e4125 - core::result::unwrap_failed::h1e20c5e1271e9480
                                   at /checkout/src/libcore/macros.rs:23
      10:     0x55e5353bbc0c - <core::result::Result<T, E>>::unwrap::hc51a84e6b2f7a038
                                   at /checkout/src/libcore/result.rs:772
      11:     0x55e53543bcb4 - <vulkano::swapchain::swapchain::SwapchainAcquireFuture as core::ops::drop::Drop>::drop::hfb7c8a15bc202cf5
                                   at /home/porky11/.cargo/registry/src/github.com-1ecc6299db9ec823/vulkano-0.7.1/src/swapchain/swapchain.rs:857
      12:     0x55e535283a44 - core::ptr::drop_in_place::h87026d0e346434d0
                                   at /checkout/src/libcore/ptr.rs:61
      13:     0x55e535281b0d - core::ptr::drop_in_place::h674271dfb769cd7a
                                   at /checkout/src/libcore/ptr.rs:61
      14:     0x55e535286481 - core::ptr::drop_in_place::hb66addcb9dd3c6f7
                                   at /checkout/src/libcore/ptr.rs:61
      15:     0x55e53527e30a - core::ptr::drop_in_place::h28064aaaa8e17741
                                   at /checkout/src/libcore/ptr.rs:61
      16:     0x55e535285e64 - core::ptr::drop_in_place::hb0ac5103cf5fc3b9
                                   at /checkout/src/libcore/ptr.rs:61
      17:     0x55e5351cf358 - <vulkano::sync::future::fence_signal::FenceSignalFuture<F> as core::ops::drop::Drop>::drop::h7dfd7029212159fd
                                   at /home/porky11/.cargo/registry/src/github.com-1ecc6299db9ec823/vulkano-0.7.1/src/sync/future/fence_signal.rs:454
      18:     0x55e53527dab4 - core::ptr::drop_in_place::h1c009b619754c078
                                   at /checkout/src/libcore/ptr.rs:61
      19:     0x55e53533c449 - vulkano::sync::future::GpuFuture::then_signal_fence_and_flush::hb6185d0718f650a2
                                   at /home/porky11/.cargo/registry/src/github.com-1ecc6299db9ec823/vulkano-0.7.1/src/sync/future/mod.rs:230
      20:     0x55e535370074 - planet_jump::main::h9003e67683d62038
                                   at src/main.rs:391
      21:     0x55e53558d66c - __rust_maybe_catch_panic
                                   at /checkout/src/libpanic_unwind/lib.rs:99
      22:     0x55e53558708b - std::rt::lang_start::hc743ffdb6d4ba404
                                   at /checkout/src/libstd/panicking.rs:459
                                   at /checkout/src/libstd/panic.rs:361
                                   at /checkout/src/libstd/rt.rs:59
      23:     0x55e5353884c2 - main
      24:     0x7efd5f42ff69 - __libc_start_main
      25:     0x55e5351cdf69 - _start
      26:                0x0 - <unknown>
    thread panicked while panicking. aborting.
    Ungültiger Maschinenbefehl (Speicherabzug geschrieben)
    

    (The last line means something like "invalid machine command (core dumped)")

    I don't think, this is a error, that should be able to occur without unsafe code, even if I did something wrong (what I don't think, because except of using different shaders and doing additional things, it's the same as the triangle example)

    Reviewed by porky11 at 2017-10-07 23:20
  • 12. Vulkano util proposal

    I've been thinking about a design for a set of utility structs to help with the boilerplate that comes with any Vulkano project. Mostly meaning: Instance creation, device selection, swapchain images, etc. So everything that happens only once, and don't change that much from project to project (unless there are some niche requirements), and the organizing of pre and after render.

    So here is my proposal: Vulkano Util crate.

    Typical use cases would be doable with just default values, most or all use cases specified with the configs. Feel free to give feedback and criticize! :). I can always make it my own crate too, but having it be maintained and improved by vulkano developers would be great.

    There would exist the following structs allowing you to focus mainly on your Vulkano pipelines.

    • VulkanoContext: Holds, Instance, Device, Queue(s) and an optional DebugUtilsMessenger. It's created with VulkanoConfig which has a set of Default values, but can be customized with create infos and device selection functions.
    • VulkanoWindows: Holds VulkanoWindowRenderer for each winit window and functions to access these windows and renderers.
    • VulkanoWindowRenderer: Used to organize rendering, swapchains, resizing and recreation of swapchain. Has an additional access to images that are resized with window (optional). Begin your render with start_frame and end with finish_frame.
      • VulkanoWindowRenderer::acquire: Recreates swapchain if needed (or requested), acquires next swapchain image and joins the future from that with previous frame end. Returns that future. Use it to synchronize your render between acquire and present.
      • VulkanoWindowRenderer::present(future: Box<dyn GpuFuture>, wait_future: bool): Used to present the swap chain image after all your executed command buffers. The idea is that you'd pass your last future before you wish to present the image on window. Optionally you can explicitly wait(None) on the future with the wait_future input. For example to ensure e.g. your compute queues aren't using a bound resource...

    Usage:

        // Create event loop
        let mut event_loop = EventLoop::new();
        // Create vulkano context with default values
        let context = VulkanoContext::new(VulkanoConfig::default());
        // Create vulkano windows struct (empty at this point)
        let mut windows = VulkanoWindows::default();
        // Create window with title "Fractal" without vsync (present mode)
        let _id = windows.create_window(
            &event_loop,
            &context,
            &WindowDescriptor {
                title: "Fractal".to_string(),
                present_mode: PresentMode::Immediate,
                ..Default::default()
            },
            // You can modify `SwapchainCreateInfo` through this
            |_| {},
        );
    

    With just all that you'd have a window ready to be drawn on.

    Drawing:

        // Start frame
        let before_pipeline_future = match renderer.acquire() {
            Err(e) => {
                println!("{}", e.to_string());
                return;
            }
            Ok(future) => future,
        };
        // Execute your command buffers here in between
        // and pass your last future to `finish_frame`.
        renderer.present(after_renderpass_future, true);
    

    I've also modified the fractal and game of life examples to use these. I don't think this replaces other tutorials necessarily, but could be helpful in future examples.

    So if you think this is something that would be useful, let me know what we can do to get this PR through. Renames, docs, refactors, improvements, test suggestions.

    These util structs should only wrap things in a way that can help the usage of Vulkano, but should not prevent you from doing anything.

    Reviewed by hakolao at 2022-06-21 17:49
  • 13. Proposal for new command buffer types

    At the moment, when you use AutoCommandBufferBuilder, it performs both validation of the command and automatic insertion of pipeline barriers. But it's quite possible that a user might want to do their own barriers manually. There may be situations where they can't be done automatically, or where the automatic method is inefficient.

    Currently, the user's only option is to use UnsafeCommandBufferBuilder. But this type is very unsafe; by using it, the user loses out on the command validation and also loses the ability to automatically keep resources alive inside the command buffer. It would be useful to have access to the safety of AutoCommandBufferBuilder without automatic barrier insertion.

    So my thought is to rearrange the current types into two new layers: a safety/validation layer and an automatic barrier insertion layer.

    • The builder types UnsafeCommandBufferBuilder and SyncCommandBufferBuilder would go.
    • There would only be two types for built command buffers, PrimaryCommandBuffer and SecondaryCommandBuffer. The corresponding traits would go.
    • A new type CommandBufferBuilder representing the safety/validation layer. It would validate all commands and keep resources alive, like AutoCommandBufferBuilder does now. It would not insert any barriers automatically, instead having a pipeline_barrier command to manually insert a barrier. But crucially, this command would be safe and every call would be validated just like other command buffer commands. CommandBufferBuilder would keep track of accesses and validate the barriers inserted by the user to ensure they got it right.
    • AutoCommandBufferBuilder would do what it does now, but it would be implemented on top of CommandBufferBuilder, by adding the automatic barrier insertion. Because the CommandBufferBuilder still validates the barriers, any bugs in AutoCommandBufferBuilder would hopefully be caught by the lower layer. In principle, AutoCommandBufferBuilder would just be one possible auto-barrier layer, the user could build their own if they wanted to.
    Reviewed by Rua at 2022-06-18 10:00
  • 14. Access Delta concept. New algorithm of resource synchronization inside one command buffer

    This is the first part of an effort to improve resource synchronization in vulkano. Original issue and design proposal: https://github.com/vulkano-rs/vulkano/issues/1914 In the design proposal I added a new section "Step 1. Introduction of Access Delta concept" that briefly describes this new concept .

    1. Added implementation of Access Delta for image and buffer resources
    2. Added append_command method and added it to all places where we are adding a command.
    3. Replaced old way of handling command buffer synchronization with a new access delta concept.

    This change should not change an overall behavior but also introduces a few improvements: now we don't need to check for a conflicts because we can now resolve all of them, now we can build more optimal barriers and in future this will help us to add a synchronization between command buffers.

    TODO: There are still a few todos in this PR that I will resolve in following commits.

    Right now this PR is split into 3 commits for easier code review.

    Reviewed by AndrewB330 at 2022-06-18 07:39
  • 15. Resource Synchronization Design Proposal

    Hello, recently I started using vulkano actively and noticed some limitation of the current implementation of resource synchronization. I wrote a small doc with my vision of the futures. I'm not fully familiar with the entire codebase yet, so I might miss some important thing in the design.

    I would like to discuss this design with all vulkano maintainers if this idea sounds interesting to you. This doc isn't full yet, but it gives an overall idea. Feel free to make any comments here or in the doc, any suggestions are appreciated :)

    https://docs.google.com/document/d/1yEDBNRt7EKsLsTL6vkdrqcGhEjsO7XbhSySclxnVNcY/edit?usp=sharing

    P.S. Let me know if its better to paste this doc in the markdown, here on github, instead if using google docs.

    @Rua @Eliah-Lakhin @AustinJ235

    Reviewed by AndrewB330 at 2022-06-10 15:37
  • 16. Validation error callback on portability drivers (VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR)

    • Version of vulkano: 0.29.0
    • OS: MacOS 12.3.1
    • GPU (the selected PhysicalDevice): Intel(R) Iris(TM) Plus Graphics 650
    • GPU Driver: Vulkan 1.3.211

    Issue

    When running the debug example on MacOS the following error is printed:

    vkCreateDevice: Attempting to create a VkDevice from a VkPhysicalDevice which is from a portability driver without the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit in the VkInstanceCreateInfo flags being set and the VK_KHR_portability_enumeration extension enabled. In future versions of the loader this VkPhysicalDevice will not be enumerated.

    As the message suggests it seems to be fixable by setting the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit on the InstanceCreateInfo flags field. However this is currently hardcoded to be empty with no way to override.

    More information on this bit can be found here (pdf)

    Full output of cargo run --bin debug:

    List of Vulkan debugging layers available to use:
    	VK_LAYER_LUNARG_api_dump
    	VK_LAYER_KHRONOS_profiles
    	VK_LAYER_KHRONOS_validation
    	VK_LAYER_KHRONOS_synchronization2
    Loader Message general verbose: Loading layer library /usr/local/share/vulkan/explicit_layer.d/../../../lib/libVkLayer_khronos_validation.dylib
    Loader Message general information: Inserted device layer VK_LAYER_KHRONOS_validation (/usr/local/share/vulkan/explicit_layer.d/../../../lib/libVkLayer_khronos_validation.dylib)
    Loader Message general error: vkCreateDevice: Attempting to create a VkDevice from a VkPhysicalDevice which is from a portability driver without the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit in the VkInstanceCreateInfo flags being set and the VK_KHR_portability_enumeration extension enabled. In future versions of the loader this VkPhysicalDevice will not be enumerated.
    unknown general information: Using MTLEvent for Vulkan semaphores.
    unknown general information: Created VkDevice to run on GPU Intel(R) Iris(TM) Plus Graphics 650 with the following 1 Vulkan extensions enabled:
    		VK_KHR_portability_subset v1
    Loader Message general verbose: Unloading layer library /usr/local/share/vulkan/explicit_layer.d/../../../lib/libVkLayer_khronos_validation.dylib
    
    Reviewed by PaulWagener at 2022-05-23 13:34
  • 17. Some examples leaking memory on resize

    Info

    • Version of vulkano: latest/0.29.0
    • OS: Windows 11 Home (10.0.22000)
    • GPU (the selected PhysicalDevice): NVIDIA GeForce RTX 3060
    • GPU Driver: 511.79 (DCH)

    Issue

    Some examples, including the one in the vulkano.rs guide slowly leak memory if resized. Memory usage is constant if the window is not resized but will steadily increase the more I resize the window. This occurs in the image examples, as well as some others like texture_array and runtime_array, but not in all examples. The ones like teapot and referred do not leak at all for me.

    Reviewed by Saetch at 2022-05-22 20:28
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

Jun 22, 2022
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

Jun 21, 2022
A vector graphics renderer using OpenGL with a Rust & C API.
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

Jun 19, 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.

Jun 8, 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

Jun 15, 2022
A cool, fast maze generator and solver written in Rust
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

May 24, 2022
A high-performance SVG renderer, powered by Rust based resvg and napi-rs.
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

Jun 17, 2022
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.

Nov 8, 2021
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

Mar 27, 2022
A simple and elegant, pipewire graph editor
 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

Jun 22, 2022
A cargo subcommand for creating GraphViz DOT files and dependency graphs
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

Apr 3, 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

Jun 12, 2022
Real-time 3D orientation visualization of a BNO055 IMU using Bissel and Bevy
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

Mar 30, 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,

Jun 3, 2022
A toy ray tracer in Rust
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

Jun 20, 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

Jun 9, 2022
An OpenGL function pointer loader for Rust

gl-rs Overview This repository contains the necessary building blocks for OpenGL wrapper libraries. For more information on each crate, see their resp

Jun 8, 2022
Graph data structure library for Rust.

petgraph Graph data structure library. Supports Rust 1.41 and later. Please read the API documentation here Crate feature flags: graphmap (default) en

Jun 20, 2022
A graph library for Rust.

Gamma A graph library for Rust. Gamma provides primitives and traversals for working with graphs. It is based on ideas presented in A Minimal Graph AP

Jun 3, 2022