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.
* 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`.
