When checking for capabilities in SPIR-V,
`capabilities_available == None` indicates that all capabilities are
available. However, some capabilities are not even defined for all
language versions, so we still need to check if the requested
capabilities even exist in the language version we're using.
It used to be that `wgpu::Buffer` did not know its own size, and so slices had to potentially not know their endpoints. Now, buffers do, so slices can. This makes the code simpler, without modifying the API.
* [naga glsl-out] Differentiate between support for `std140` and `std430` layout, and emit `std140` in Uniforms when possible
* [naga glsl-out] Remove storage buffer std140 layout fallback, and error when we are unable to assign an explicit memory layout for uniform and storage globals
Co-authored-by: teoxoy <28601907+teoxoy@users.noreply.github.com>
---------
Co-authored-by: teoxoy <28601907+teoxoy@users.noreply.github.com>
The `metal` crate is currently unsound regarding unknown/future enum
variants, see https://github.com/gfx-rs/metal-rs/issues/209 and
https://github.com/rust-lang/rfcs/pull/3803.
`objc2-metal` fixes this by emitting C enums as a newtype + constants
for each variant, but that prevents us from importing the
variants/constants. So this commit converts to a pattern that works with
that in preparation for the migration.
A lot of Metal types are prefixed with MTL, which makes it quite clear
where they're coming from. This means that we don't loose any clarity if
we import them instead of having them prefixed with `metal::`.
This will make it easier to migrate to `objc2-metal` since that crate is
named differently from the `metal` crate.
The old is_compatible_with handled scalar/scalar, scalar/vector, vector/vector, but was missing vector/scalar.
Since is_compatible_with is only used by vertex shader inputs, and vertex shader inputs can't be matrices (only scalars and vectors), we can actually simplify this by removing the other match and just only checking the kind.
Fixes#7568
This makes texture view destruction cheap since users of wgpu-hal are required to keep resources referenced by encoders alive for at least as long as the encoder is alive.
This is also a prerequisite to implement rendering to slices of 3D textures (by creating temporary texture views).
On the other hand the cache won't be as effective but that is probably ok, we can reevaluate the implementation if it turns out to be a problem.
Imageless framebuffers are not needed, we know which views will be attached to the render pass already. Even if we wanted to more aggressively cache imageless framebuffers that wouldn't be possible since they still require specifiying view usage, texture usage and view formats.
Removing usage of imageless framebuffers simplifies the code substantially.
