vk-mem-rs: Crate does not compile with newly released ash 0.33

First, thanks for making these bindings!

I’m hitting this compile error since ash 0.33 released. (I haven’t looked into the correct fix yet, but wanted to mention it)

error[E0432]: unresolved import `ash::version`
   --> .cargo/registry/src/github.com-1ecc6299db9ec823/vk-mem-0.2.2/src/lib.rs:753:18
    |
753 |         use ash::version::{DeviceV1_0, DeviceV1_1, InstanceV1_0};
    |                  ^^^^^^^ could not find `version` in `ash`

Also wanted to mention, since vk-mem does not use semver to reference ash (cargo.toml has ash >= 0.27.1), the new ash release broke CI in my project immediately. It would have been less disruptive if this library relied on a specific version of ash. (If needed, feature flags could be used to simultaneously support multiple versions of ash, i.e “ash-32”, “ash-33”, “ash-latest”, etc.)

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 6
Comments: 18 (12 by maintainers)

Commits related to this issue

Specifiy a maximum supported ash version v0.33 of ash moved some things around, so this crate as-is no longer works. See: https://github.com/gwihlidal/vk-mem-rs/issues/54 See: #54 — committed to Chris--B/vk-mem-rs by Chris--B 3 years ago
Update to vk-mem fork This fork builds correctly in a world with ash v0.33. See: https://github.com/gwihlidal/vk-mem-rs/issues/54 — committed to Chris--B/spark by Chris--B 3 years ago
Update to working vk-mem repo https://github.com/gwihlidal/vk-mem-rs/issues/54#issuecomment-894593402 — committed to NickRoz1/gfaestus by NickRoz1 2 years ago

Most upvoted comments

@aclysma the second option definitely sounds like the most robust option. And yeah it can be somewhat messy if one does support lots of versions, though most of them would have identical ash code interaction still.

Unfortunately I think this crate is effectively unmaintained, we’ve moved to the pure Rust gpu-allocator instead

repi on Aug 13, 2021

I have been given full permissions to merge PRs and publish new cargo crates, so closing this issue now. Please feel free to open a new issue if problems pop up.

Neo-Zhixing on Jan 31, 2024

I don’t know why ppl suggest gpu-allocator as some kind of replacement… Sure if you don’t think Panasonic and Sony are different, then I guess. The accolades of using AMD’s memory allocator VS something maintained by a third party are clear? I realized as I wrote that, that I don’t know anything about gpu-allocators owners. Owned by AMD is not something the readme points too, so I could be forgiven.

cheako on Jul 7, 2022

It sounds like this library is no longer maintained (https://github.com/gwihlidal/vk-mem-rs/issues/54#issuecomment-898736244) so I wouldn’t plan on anything to be merged at this point.

aclysma on Aug 27, 2021

I wasn’t blaming ash. I only meant that having a dependency in the public API that is still evolving is problematic. And yes, the range specifier is the biggest issue here. There isn’t a way to pin the version of ash without Cargo.lock which makes libraries that depend on vk-mem a little frustrating.

aloucks on Aug 18, 2021

Crates depending on vkmem can’t publish currently?

cheako on Aug 23, 2021