* Update PR template
* Rename queue to queue_family
* Add examples readme
* Use the same image output filename
* Move existing examples with multiple files into their own folder
* Improve error message when running runtime-shader in the wrong directory
Expand MissingUsage into MissingBufferUsage and MissingImageUsage
each with an enum so that the usage that is missing is obvious
in the error, e.g.:
thread 'main' panicked at 'add curimage: MissingImageUsage(Storage)'
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
* 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.
Either these calls to `replace` are unnecessary, or I'm going to learn something
I really need to know.
The only way difference I can see between `replace` and a simple assignment is
that `replace` returns ownership of the value to the caller, so the old value is
dropped after the new value has been put in place. But if Rust lets us assign to
or move from a variable, that means that no other alias can observe that
happening --- which I think means that the drop can't possibly care whether it
occurs before or after the move.
The previous expression gives unreasonable answers for some combinations of
`swapchain::Capabilities`' `min_image_count` and `max_image_count` values. For
example, for `3` and `None`, the expression evaluates to 2, which isn't a
permitted image count.
I looked for a terser expression (using `Option` methods, say), but the `match`
expression ended up being the most legible I came up with.
It was recently discovered in rust-lang/rust#50781 that `Self: Trait` bounds in trait methods are really not object-safe. This will be made into a warning by rust-lang/rust#50966, and vulkano will be affected by the warning .
Thankfully the fix looks simple, by just moving `fn len` from `BufferAccess` to being directly in `TypedBufferAccess`.
This updates the asserts in `RenderPass` creation to allow
`VK_SUBPASS_EXTERNAL` as a special value in addition to any value less
than the total number of subpasses. This enables custom unsafe
implementations of `RenderPassDesc` to define their external dependencies.
* Allow Surface to reference an external window object
This makes the Surface struct generic across a Window
type, so that a surface can own (or reference, if W is
an Arc) an external window object.
This also updates vulkano-win to take advantage of this.
There is no longer a dedicated Window struct in vulkano-win.
Instead, the Surface is simply passed ownership of the
winit::Window.
This fixes#844
* Update examples for new surface API
* Update Changelog
* Remove unnecessary send/sync bounds
* Update swapchain docs for new Surface behavior
