bindgen 0.69.0 broke the `--version` switch, resulting in misleading errors about requiring at
least bindgen 0.62 or about unexpected arguments.
Ideally the build system would fetch the correct bindgen version automatically like cargo does.
Until then, provide a hopefully more helpful error message to the user.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26046>
* Add support for PIPE_BUFFER in resource_from_handle.
* Flush batches after reallocate_resource_inplace:
If we're dealing with a PIPE_BUFFER, iris_flush_resource doesn't
flush the batch and we export the resource with pending commands.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21305>
The `zink_internal_create_screen()` function can fail before
`screen->loader_lib` and/or `screen->instance` are initialized.
The `zink_destroy_screen()` doesn't check those cases and crashes.
The error was found by Fedora's CI. The back trace is available at [1].
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2023-c39f82c465
Fixes: 0c2045553f ("zink: use screen destructor for creation fails")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26029>
This reverts commit f7e7cf637e.
It is now possible to change the buffer size from VA frontend, so this
is no longer needed and instead it's up to applications to set
appropriate value.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25991>
When using `MESA_LOADER_DRIVER_OVERRIDE=v3d` in real hw, use kmsro to
create the drm screen, which is actually what happens when not exporting
such variable.
This avoids confusions when using the envvar in real hardware and starts
to fail.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26007>
If application requests to map surface that was most recently used
as decoder or postproc target and also doesn't explicitly set the
map flags (vaMapBuffer2) it's very likely the intent is to read from
this surface, so we need to map it as such.
This fixes regression on radeonsi where mapping NV12 surfaces for
reading would fail with applications using vaDeriveImage. The reason
for this is that the VA frontend doesn't allow vaDeriveImage for
interlaced surfaces so the applications would use vaGetImage fallback,
but radeonsi doesn't allocate NV12 surfaces as interlaced anymore.
This also fixes mapping other formats surfaces (P010, RGBx, ...)
for reading, which never worked before.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9935
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10048
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26008>
This is something that we could allocate and export. So we must import
them as well.
Fixes import failures in spec@ext_image_dma_buf_import@ext_image_dma_buf_import-modifiers
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25995>
Now that we have TILED2 and TILED3 modifiers, we should handle those
cases.
Fixes assert that modifier != INVALID in
spec@ext_image_dma_buf_import@ext_image_dma_buf_import-modifiers
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25995>
To get MacOS to build, some extra dependencies need to be added to a couple of build targets.
This mainly shows up when not installing the dependencies in the default prefix locations.
On MacOS, this happens when using a custom build of brew to install the dependencies to 'odd' locations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26022>
Instead, check if it's a vector or scalar and use 1 explicitly. In FS
output case where we were only using it assert we don't have any arrays,
assert that directly.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
