* Remove Send + Sync and BufferAccess traits where they are redundant
* Require Send + Sync for ImageViewAbstract
* Require Send + Sync for ImageAccess, AttachmentsList and MemoryPoolAlloc
* Require Send + Sync for DescriptorSet and DescriptorPoolAlloc
* Require Send + Sync for FramebufferAbstract
* Minor rearranging
* Require Send + Sync for PrimaryCommandBuffer, SecondaryCommandBuffer and CommandPoolAlloc
* Require Send + Sync for Command (private trait)
* Cargo fmt
* Move descriptor_set.rs to parent, make descriptor.rs its child
* Rename UnsafeDescriptorSetLayout to DescriptorSetLayout, as there isn't actually anything unsafe about it
* Make fixed_size_pool and persistent modules public, reduce number of re-exports from there
* Split off pool.rs from sys.rs
* Move std_pool module to pool::standard
* Make sys public, remove re-exports
* Move descriptor module and DescriptorSetDesc into layout module
* Move ShaderStages to pipeline::shader
* Make descriptor_set::collection module private
* Documentation
* Don't enable any features in examples unless the example requires it
* More elaborate device selection code in the triangle example
* Better device selection for all other examples
* Migrate to using Ash as a base
* Small change to test, to make it applicable to Vulkan 1.1
* Auto-generate extensions, check extension requirements
* Add documentation to extensions, use vk.xml from Ash 0.32.1
* Remove `RawDeviceExtensions` and `RawInstanceExtensions`
* Add extension conflict checking
* Small fix
* Add auto-generated features, more requirements checks
* Features documentation
* Macrofy required_if_supported_extensions
* Include vulkano-gen tool
* Move autogen imports to macros
* Change autogen into a build script
* Delete leftover file
* Autogenerate device properties
* Propagate bugfix in properties chain to features
* 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
* Create generic render pass description type, macro generates that instead of making its own type
* Replace EmptySinglePassRenderPassDesc with empty() constructor
* Remove RenderPass type parameter
* Remove RenderPassAbstract trait, type parameters that use it. Add GraphicsPipelineAbstract::subpass and Framebuffer::render_pass
* Remove RenderPassDescClearValues trait
* Remove RenderPassSubpassInterface and RenderPassCompatible traits
* Change RenderPassDesc into a struct
* Rename framebuffer module to render_pass, move/rename other things
* Rustfmt + changelog
* Documentation update
* Add pipeline barriers when executing secondary command buffers
* Add locking for secondary command buffers when executed on a primary
* Propagate flags of secondary to primary
* Forgot the vec variant
* Add poisoning as a stopgap measure to protect against inconsistent builder state
* vulkano: instance: derive Ord, PartialOrd for PhysicalDeviceType
Useful for want differeniating integrated and discrete GPUs in a
hash table.
* vulkano: don't pull in all of crossbeam
Just pull in crossbeam-queue, since that's what used.
Having a smaller set of packages is easier for system integrators
such as myself.
* vulkano: memory: add import support, separate device memory and mappings, and much more!
- Chaining structs copied shamelessly and poorly from Ash :-)
- Import support, as previously promised.
- DeviceMemoryMappings so we can maybe one day expose the binding model.
- Attempts to rigorously check Valid Usage IDs (VUIDs).
A note about error handling:
- Currently, Vulkano error handling is a bit unclear. For example, I
didn't define a "DeviceMemoryMappingError" and simply reused the
"DeviceMemoryAllocError" already present in the file. In reality,
both a theoretical "DeviceMemoryMappingError" and the already
present "DeviceMemoryAllocError" should mostly just check the valid
usage IDs present in the Vulkan spec (or return an error from the
implementation). This code pattern is common throughout Vulkano.
Perhaps we should go to a simpler VulkanoResult<T>??? Just an idea.
- Also, is Vulkano a validation layer??? LunarG tracks every single
VUIDs in their uber layer already:
https://www.lunarg.com/wp-content/uploads/2019/04/UberLayer_V3.pdf
Of course, given how Vulkan drivers are relatively straigtforward
compared to OpenGL, it's generally possible to match LunarG *using
Rust* if we just have a big enough community. Whether we want to or
not may be up for debate. For now, I just followed the original
vision of tomaka and added validation. If we do want to do it, then
we have to be more rigorous about it.
* Rename Dimensions > ImageViewDimensions, ViewType > ImageViewType
* Remove cubemap_compatible from ImageDimensions, add ImageCreateFlags to UnsafeImage creation
* Replace various UnsafeImage features/usage methods with new ones that return them directly
* Create image::view module, move view-related types into it
* Create safe ImageView type, remove some of the validity checks from UnsafeImageView
* Removed ImageViewAccess::samples and moved the descriptor_set_* functions to ImageAccess
* Remove ImageViewAccess::dimensions
* Impl ImageAccess for ImageView, remove impl on image types
* Rename ImageViewAccess to ImageViewAbstract, move some methods around
* Remove ImageViewDimensions (formerly Dimensions)
* impl Error for ImageViewCreationError
* Missing pub
* Typo
* Some small documentation changes
* Check for ImageCreateFlags that are currently not properly supported
