Support for no-std - Githubissues

ash-rs / ash

Vulkan bindings for Rust

Apache License 2.0

1.84k stars 187 forks source link

Support for no-std #314

Open nyovaya opened 4 years ago

nyovaya commented 4 years ago

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 commented 4 years ago

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

Ralith commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Ralith commented 4 years ago

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

MaikKlein commented 4 years ago

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

nyovaya commented 4 years ago

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 commented 3 years ago

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

i509VCB commented 2 years ago

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 commented 2 years ago

probably with alloc given we need dynamic function loading

Loading functions does not require alloc.

i509VCB commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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