It is emptied by `reset_queries` at the end of every render pass, so
it's just keeping an allocation alive, not holding any state. It seems
unlikely that there is sufficient performance gain from reusing the
memory allocation to justify the complexity of additional state at
higher layers.
Previously, the check was skipped if the copy was a single row, which is
not correct. The check should be made whenever bytes_per_row is
specified. It is permissible not to specify bytes_per_row if the copy is
a single row, but if it is specified, it must be aligned.
Also removes a redundant check of the `offset` alignment.
Since the offset and bytesPerRow alignment checks are not part of
"validating linear texture data", I chose to remove that instance of
them. These checks are now in `validate_texture_buffer_copy`, which
does not correspond 1:1 with the spec, but has a comment explaining how
it does correspond.
This also allow to remove the MESA_VERSION and VULKAN_SDK_VERSION
duplication between the ci workflow and the install action.
To pass down the version in each steps, I added action inputs
because there is no way as of today to define environments
variables that are shared between steps in composite actions
(no top level `env:` like for workflows).
TransferError now has separate variants for texture copy formats that
are only forbidden in combination with specific aspects
(CopyFrom/ToForbiddenTextureFormatAspect), and texture copy formats that
are always forbidden, irrespective of the aspect
(CopyFrom/ToForbiddenTextureFormat).
This produces a less confusing error message by not mentioning the
aspect it is not relevant.
Although the operation of these functions is defined in terms of f16
semantics, the input/output types are not f16, and they are generally
available even when native `f16` support is not. But in at least one
case, they are only available with `f16` support, so add a new downlevel
flag that is cleared when these functions are not available.
Add some infrastructure to simplify testing of missing
capabilities/extensions, and add tests for a few more kinds of f16
usage.
Co-authored-by: Erich Gubler <erichdongubler@gmail.com>
This contains the Metal HAL changes required to support external
textures. When creating a bind group we create resource bindings for
each of the 3 textures and parameters buffer that the external texture
has been lowered to. When creating the pipeline layout we fill the
`BindTarget` accordingly, so that the Naga MSL backend can bind each
of the global variables to which the the external texture has been
lowered to each of these resources.
We must also ensure the size of the buffer bound to the parameters
global matches the size of the MSL type, else metal validation
complains. We do this by adding a padding field to the rust-side
ExternalTextureParams struct, the size of which is used as the size of
the buffer to allocate.
Lastly we enable `Features::EXTERNAL_TEXTURE` on the Metal backend.
This adds MSL backend support for `ImageClass::External`. (ie WGSL's
`external_texture` texture type). This is implemented very similarily
to the HLSL implementation in #7826.
Each external texture global variable is lowered to 3 `texture2d`s and
a buffer of type NagaExternalTextureParams. As usual in Naga's MSL
backend, these are passed as arguments to the entry point. The
bindings for each of these arguments are provided via the usual
binding map, using a new `BindExternalTextureTarget` variant of
`BindTarget`.
Unlike HLSL, MSL allows textures to be used as fields in structs. We
therefore immediately wrap these variables in a
`NagaExternalTextureWrapper` struct. This wrapper can then
conveniently be passed to either user-defined functions or builtin
implementations that accept an external texture.
The WGSL builtins `textureDimensions()`, `textureLoad()`, and
`textureSampleBaseClampToEdge()` are implemented using wrapper
functions using the regular `write_wrapped_functions()` machinery.
