#vulkan #vulkan-graphics #graphics #graphics-pipeline #ash #3d

vk-sync-fork

Simplification of core Vulkan synchronization mechanisms such as pipeline barriers and events. Forked off of the original vk-sync crate which is currently unmaintained.

5 unstable releases

0.4.0 Apr 6, 2022
0.3.0 Dec 28, 2021
0.2.2 Dec 10, 2021
0.2.1 Oct 23, 2021
0.2.0 Oct 23, 2021

#425 in Graphics APIs

Download history 9/week @ 2024-06-17 13/week @ 2024-06-24 2/week @ 2024-07-08 23/week @ 2024-07-15 17/week @ 2024-07-22 13/week @ 2024-07-29 10/week @ 2024-08-05 13/week @ 2024-08-12 8/week @ 2024-08-19 5/week @ 2024-08-26 8/week @ 2024-09-02 7/week @ 2024-09-09 33/week @ 2024-09-23 38/week @ 2024-09-30

79 downloads per month
Used in screen-13

MIT/Apache

48KB
695 lines

vk-sync(-fork)

Latest version Documentation

Simplified Vulkan synchronization logic, written in rust.

Forked off of the original vk-sync crate which is currently unmaintained.

Overview

In an effort to make Vulkan synchronization more accessible, this library provides an efficient simplification of core synchronization mechanisms such as pipeline barriers and events.

Rather than the complex maze of enums and bit flags in Vulkan - many combinations of which are invalid or nonsensical - this library collapses this to a much shorter list of ~40 distinct usage types, and a couple of options for handling image layouts.

Additionally, these usage types provide an easier mapping to other graphics APIs like DirectX 12.

Use of other synchronization mechanisms such as semaphores, fences and render passes are not addressed in this library at present.

Bindings

There are a number of Vulkan ffi bindings available, and I do plan to support the most common bindings, but for now this library only implements support for ash. Please add other bindings you need via a pull-request; I would happily accept it.

Expressiveness

Despite the fact that this library is fairly simple, it expresses 99% of what you'd actually ever want to do in practice. Adding the missing expressiveness would result in increased complexity which does not seem worth the trade-off. If you have any pattern you need express, please file an issue!

Here's a list of known things you cannot express:

  • Execution only dependencies cannot be expressed. These are occasionally useful in conjunction with semaphores, or when trying to be clever with scheduling - but their usage is both limited and fairly tricky to get right anyway.

  • Depth/Stencil Input Attachments can be read in a shader using either ImageLayout::ShaderReadOnlyOptimal or ImageLayout::DepthStencilReadOnlyOptimal - this library always uses ImageLayout::DepthStencilReadOnlyOptimal. It is possible (though highly unlikely) when aliasing images that this results in unnecessary transitions.

Usage

Add this to your Cargo.toml:

[dependencies]
vk-sync = { package = "vk-sync-fork", version = "0.2.1" }

License

Licensed under either of

at your option.

Credits

This library is heavily based on work by Tobias Hector (https://github.com/Tobski/simple_vulkan_synchronization)

As mentioned above, this library was orignally developed by Graham Wihlidal (https://github.com/gwihlidal/vk-sync-rs)

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Code of Conduct

Contribution to the vk-sync-fork crate is organized under the terms of the Contributor Covenant, the maintainer of vk-sync, @gwihlidal, promises to intervene to uphold that code of conduct.

Dependencies

~5MB
~124K SLoC