* initial support for the `VK_KHR_multiview` extension
The `VK_KHR_multiview` extension can be used to efficiently draw to multiple layers of a framebuffer at once with.
This is particularly useful for virtual reality applications or other types of stereoscopic rendering where both eyes need to be rendered and they share almost all visible vertices.
* allow creation of multi-layer attachment images
Using the `AttachmentImage::multisampled_with_usage_with_layers` constructor.
More constructors with different combinations could be added for the `AttachmentImage` but `multisampled_with_usage_with_layers` already exposes all possible options.
I think all these different constructors should be replaced with a constructor that takes a struct that implements `Default` or an enum with the different possibilities.
* compliance with VUID-VkFramebufferCreateInfo-renderPass-02531
* removed changelog entries according to new policy
* migrate `VK_KHR_multiview` support to ash
* add more comments
* add remaining `VK_KHR_multiview` validation
* validate instanced drawing using `multiview` limits
* add some missing validation relating to `VIEW_LOCAL` dependencies
* use the vulkano device feature instead of depending on the `multiview` extension directly
* Allow choosing the Vulkan max API version when creating Instance
* Rewrite feature handling, include all Vulkan 1.1 and 1.2 features
* Fixes
* Move features.rs to device module
* More small fixes
* Changelog
* Convert trait `ShaderInterfaceDef` into struct `ShaderInterface`
* Convert some instances of PipelineLayoutDesc to RuntimePipelineDesc
* Use regular Vec for now
* Convert PipelineLayoutDescUnion to RuntimePipelineDesc
* Convert PipelineLayoutDescTweaks to use RuntimePipelineDesc
* Remove PipelineLayoutDesc trait, replace with what used to be RuntimePipelineDesc
* Remove PipelineLayoutAbstract trait
* Fix bug
* Provide value for push constants to entry point instead of type
* Remove GraphicsEntryPointAbstract, allow pipelines without fragment shader
* Move descriptor::pipeline_layout to pipeline::layout
* Small changelog addition
* Fix bug
* Move physical device functions into their own module
* Add method to FunctionPointers to query Vulkan api version
* Store the versions of instances and devices, allow user to query
* Check Vulkan version in vulkano-shaders, changelog
* Small mistake in changelog
* Write descriptor set layout structs for each entrypoint rather than for the entire module
Signed-off-by: Arc-blroth <45273859+Arc-blroth@users.noreply.github.com>
* Fix descriptor set calculation for all storage classes across all SPIRV versions by inspecting each entrypoint's instruction tree. Also adds 27 instructions to parse.rs.
Signed-off-by: Arc-blroth <45273859+Arc-blroth@users.noreply.github.com>
* Add unit tests for descriptor set calculations
Signed-off-by: Arc-blroth <45273859+Arc-blroth@users.noreply.github.com>
* Fix BufferBlock not counting as a Block decoration on structs (this fixes the unit tests from 4875bcc2)
Signed-off-by: Arc-blroth <45273859+Arc-blroth@users.noreply.github.com>
* cargo fmt
Signed-off-by: Arc-blroth <45273859+Arc-blroth@users.noreply.github.com>
* Update changelog
Signed-off-by: Arc-blroth <45273859+Arc-blroth@users.noreply.github.com>
* 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.
* Add new template parameters for GraphicsPipelineBuilder
* Add support for the specialization constants in build()
* Fix SpecializationConstants fields being private
* Fix lifetime problem in SpecializationConstants::descriptors()
* Run rustfmt on builder.rs
