* Implement support for VK_KHR_16bit_storage and VK_KHR_storage_buffer_storage_class.
This change also allows SPIR-V instructions to require device extensions.
* Remove SPIR-V capabilities with duplicate values (StorageBuffer16BitAccess and UniformAndStorageBuffer16BitAccess).
* move changelog entry to current version
This is kind of a delayed emergency release to address an issue where
some Linux distributions (Arch, Void and perhaps others) are unable to
build any projects depending on vulkano-shaders due to
google/shaderc-rs#58. This is resolved in shaderc 0.6 and in turn will
be resolved in vulkano 0.14 thanks to #1226.
See the CHANGELOG-VULKANO.md for more details on the release.
* Update shaderc to 0.6 in order to significantly reduce compile-times on (Arch/Void)Linux again by linking towards shared libraries
* Add "shaderc-build-from-source" feature in order to allow shaderc to build from source if linking to system libraries fails
* Remove trailing whitespace to please Travis (CI)
* replaced `.expect()` that provided no useful information with `.unwrap()`
* used `use` consistently (all types are `use`d all functions have the parent module `use`d)
* other formatting consistencies
* vulkano_shaders_derive exposes a proc_macro instead of a proc_macro_derive
* move vulkano_shader out of vulkano_shaders_derive and deprecate vulkano_shaders_derive
* Update documentation
* Move vulkano_shader! to root of mod, so it works with rust 1.30
SPIR-V allows the array stride and size of a type to differ, but rust defines them to be the same. Thus
certain types when represented in rust will have the wrong layout. E.g. an array of vec3 can have an array
stride of 16 in SPIR-V, but an array of [f32;3] in rust would have a stride of 12. Thus using one for the
other would cause corruption.
This suggests a workaround by using a wrapping struct or upgrading the size of the type to one where the size
is the array stride.
I considered generating the wrapping struct for the user, but that seems very confusing for the user. We could
generate wrapping structs for all vec and mat types in arrays, but that would be a large API change.
See #298.
* Use 'greater than' instead of 'superior to'.
Using 'X is superior to Y' to mean 'X > Y' is not standard mathematical usage. I
think I've seen 'superior to' used in lattice theory, but that's not relevant to
these cases.
* trait RenderPassDesc: Correctly describe when `None` is returned.
This seems to be an off-by-one error in the documentation. Looking at the
implementations generated in `src/framebuffer/macros.rs`, for example,
the various elements of each sequence are numbered from 0 to n-1.
* Typo: 'anistropic' -> 'anisotropic'.
* sampler::MipmapMode::Linear: Clarify description.
The docs seem to suggest that if the dimensions match a given level D, then
`Linear` would use levels D-1 and D+1, which is senseless. The new wording is
meant to be closer to the calculation described in Vulkan 1.1.82 §15.6.7.
* Typo: 'transitionned' -> 'transitioned', and similar.
* Doc fix: 'more optimal' -> 'more efficient'
Rationale for the curious:
'Optimal' is an absolute; once something is optimal, it cannot be made more so.
Absolutes can be weakened, as in 'almost optimal', but not strengthened, as in
'more optimal' or 'very optimal'. 'Efficient' is not an absolute: one thing
might be 'more efficient' than another.
* Minor doc fixes.
* Doc fix: 'performances' -> 'performance' throughout.
