177: Update `lazy_static` version to match `shared_library`'s r=MaikKlein a=Chris--B
`shared_library` uses a flexible "`1`" for its `lazy_static` lib. By following suit, `ash` can avoid duplicate versions of `lazy_static` in transient dependencies builds.
I tested this by building `ash`: everything built fine.
Co-authored-by: Chris Butler <chrisbutler296@gmail.com>
169: Issue 142 r=MaikKlein a=coolmedium
Hey here is an attempt to address #142 .
I have used builders in cases where a builder method accepts a structure that sets more than one struct field (e.g. fields like `x_count` and `p_to_some_x`). Otherwise I have usually used `.. Default::default()` when doing so would save typing.
If there is a preferred way to approach this I'm happy to make any changes.
Also, for creating shader modules I have added `examples::bytes_to_u32_vec` to convert the current shader code into a format suitable for passing to the `vk::ShaderModuleCreateInfo::code`. It uses `std::mem::transmute` and is based on the code for `u32::from_ne_bytes` in nightly. I have only tested this on Linux.
Co-authored-by: colin <colin@coolmedium.games>
170: SPIR-V reading helper r=MaikKlein a=Ralith
SPIR-V is defined in terms of 4-byte words and does not have a defined endianness, and compiler and target endianness may differ. Furthermore, Vulkan seems to require SPIR-V supplied to the implementation to be 4-byte-aligned. As a result, reading SPIR-V in a safe and portable fashion is error-prone.
So far we have largely shied away from including nontrivial helper code in ash, but arguably most portable code using ash will want this function. Do we want to break precedent? Or should we introduce a separate, optional, utility crate for code that doesn't directly wrap some part of Vulkan?
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
