Support for no-std

[nyovaya]

Can this crate be changed in a way that it supports no-std(as Vulkan explicitly supports embedded devices) or does it depend on std exclusive stuff?

[nyovaya]

Instead of Vec<T> we could use the crate 'smallvec' for no_std.

[Ralith]

Vec is available via the alloc crate in no_std. You could cfg out the high level wrappers if you want no-alloc support as well.

[MaikKlein]

I haven't looked at no_std at all yet. ash also fetches all the function pointers at runtime, is that a problem for embedded devices?

[nyovaya]

Ok it seems like dynamic function loading is not trivial on no_std.

[Ralith]

Dynamic function loading is intrinsic to Vulkan, minimal entry points aside.

[MaikKlein]

Which "embedded devices" do you want to run vulkan on?

[nyovaya]

Dont have anything explicit in mind but I think it would be some device with an RTOS or with a statically linked vulkan driver.

[anyputer]

Also, CStr is only in libstd. Hopefully Rust gets better null-terminated strings eventually...

[i509VCB]

I do have some interest in this, there are few things I can think of to make moving towards being no_std capable (probably with alloc given we need dynamic function loading):

• Make the generator generate types using core and alloc instead of std for imports where possible. This is a change that can be made without any api changes.
• Regarding CStr(ing) we either need to hope those are moved to liballoc/libc/libcore or make ash depend on https://crates.io/crates/cstr_core when no_std is used.

I imagine there is more than those two things involved with no_std support.

[Ralith]

probably with alloc given we need dynamic function loading

Loading functions does not require alloc.

[i509VCB]

probably with alloc given we need dynamic function loading

Loading functions does not require alloc.

Well I guess I am mistaken there.

I could make some pull requests to do some of the type import stuff for core and alloc if desired

[i509VCB]

To help with this, I am implementing the following clippy lint: https://github.com/rust-lang/rust-clippy/pull/9103

The lint should help us ensure we don't forget any types that could be specified in core or alloc instead.

[i509VCB]

Assuming all goes well for 1.64, CStr and CString will be accessible inside of core and alloc respectively: https://github.com/rust-lang/rust/pull/99277

The new clippy lints are also stabilized in 1.64