Update the sampler views with the color channels, that fixes the issue
caused by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20815
It fixes the case:
`gst-launch-1.0 -v -v filesrc location=file.jpg ! jpegparse ! vaapijpegdec ! imagefreeze ! vaapisink`
Fixes: dc2119bf3f ("util/format: Fix wrong colors when importing YUYV and UYVY")
Cc: mesa-stable
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26911>
(cherry picked from commit 9eac06521a)
The unrolling uses glBegin, which is unsupported by GLES and the GL
dispatch fails.
Fixes: 50d791ca73 - glthread: add a vertex upload path that unrolls indices for glDrawElements
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26916>
(cherry picked from commit 56b4d199a0)
Gen5 adds some boolean conversion instructions after nir emits,
but that nir srcs don't line up with them, so reemit the boolean
conversion if we reemit the inot.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 31b5f5a51f ("nir/opt_if: Simplify if's with general conditions")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26782>
(cherry picked from commit 56a72e014f)
Fix piglit.spec@ext_image_dma_buf_import@ext_image_dma_buf_import-modifiers
randomly skipping some tests as external_only content was never initialized.
Cc: mesa-stable
Reviewed-by: default avatarMike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26305>
(cherry picked from commit b6d828576e)
zink_bo_create can run into a heap-use-after-free when the bo is still
referencing an batch_state from an older destroyed context. In order to
fix this, every context gives back their batch_states to the zink, where
they can be reused from for new contexts.
Cc: mesa-stable
Suggested-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26889>
(cherry picked from commit b06f6e00fb)
Implementations are supposed to do that per the Vulkan spec.
This fixes the following new VKCTS tests
dEQP-VK.pipeline.*.stencil.no_stencil_att.*
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26847>
(cherry picked from commit 8b7b5be98b)
With dynamic rendering, it's allowed to begin rendering with depth or
stencil only but still with a depth/stencil format. The test below
checks that unbound part of ds isn't modified, if depth is bound and
stencil not and vice versa.
This fixes a recent CTS
dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.partial_binding_depth_stencil.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25350>
(cherry picked from commit 1ef5feac5e)
This is ported from amd ac_llvm_helper.cpp, thanks to Marek for the pointer.
This is needed to avoid crashes due to atexit ordering between some piglit
tests and mesa internals.
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26883>
(cherry picked from commit b3cfec2fd8)
Python 3.12 started giving a SyntaxWarning for unrecognized escapes such
as "\w". This might become a SyntaxError in a future python version.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26850>
(cherry picked from commit cad2c0915d)
Fixes the build on OpenBSD, where major() is in sys/types and
sys/sysmacros.h does not exist. Also include sys/mkdev.h if
MAJOR_IN_MKDEV is defined.
Fixes: 6d60115be7 ("zink: Fix enumerate devices when running compositor")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26735>
(cherry picked from commit 33eecafe75)
We only need it for indirect draws.
Improves performance on an i7-12700 and A770:
- Piglit's drawoverhead base case +150.639% +/- 2.86933% (n=15).
- gfxbench5 gl_driver2_off +19.7219% +/- 1.13778% (n=15)
- SPECviewperf2020 catiav5test1 +1.6831% +/- 0.552052% (n=10).
Cc: mesa-stable
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26806>
(cherry picked from commit 55c262898a)
Whenever we use a BO in a batch, we need to find its corresponding exec
list entry, either to a) record that it's been used, b) update whether
it's being written, c) check for cross-batch implicit dependencies.
bo->index exists to accelerate these lookups. If a BO is used multiple
times by a batch, bo->index is its location in the list. Because the
field is global, and a BO can in theory be used concurrently by multiple
contexts, we need to double-check whether it's still there. If not, we
fall back to a linear search of all BOs in the list, looking to see if
our index was simply wrong (but presumably right for another context).
However, there's one glaringly obvious case that we missed here. If
bo->index is -1, then it's wrong for /all/ contexts, and in fact implies
that said BO has never been added to any exec list, ever. This is quite
common in fact: a new BO, never been used before, say from the BO cache,
or streaming uploaders, gets used for the first time.
In this case we can simply conclude that it's not in the list and skip
the linear walk through all buffers referenced by the batch.
Improves performance on an i7-12700 and A770:
- SPECviewperf2020 catiav5test1: 72.9214% +/- 0.312735% (n=45)
Cc: mesa-stable
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26806>
(cherry picked from commit d55b5d4af5)
A value of -1 means that the buffer has never been used in an execbuf
buffer list in any of our contexts. While setting this isn't critical,
doing so will allow us to short-circuit some looping in the next patch.
Cc: mesa-stable
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26806>
(cherry picked from commit d178334d5c)
Extension was enabled but required enums not.
Fixes: 979bcb9f42 ("glsl: add EXT_clip_cull_distance support based on ARB_cull_distance")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26688>
(cherry picked from commit 629b15f446)
Otherwise common/intel_gem.h may get included instead of
common/i915/intel_gem.h when building in a different directory.
Fixes: e050a00b9f ("intel/common: Move i915 files to i915 folder")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26784>
(cherry picked from commit fbb9ce0140)
The initial logic was to remember the place were SPI_SHADER_PGM_LO_*
are written, then assume that we can get the register offset because
the sequence would always be:
PKT3_SET_SH_REG
SPI_SHADER_PGM_LO_* register offset
VA low 32 bits value <- reg_va_low_idx
The problem is that this sequence isn't guaranteed, for instance we
can get this instead:
0 c0067600 |
1 00000046 |
2 003ffffd | SPI_SHADER_PGM_RSRC3_VS
3 00000020 | SPI_SHADER_LATE_ALLOC_VS
4 * 00002080 | SPI_SHADER_PGM_LO_VS
5 00000080 | SPI_SHADER_PGM_HI_VS
So the assert in si_state_draw.cpp would fail as well as the VA
update logic.
So instead remember which the SPI_SHADER_PGM_LO_* offset, and the low
32 bits of the VA in si_update_shaders.
Fixes: 8034a71430 ("radeonsi/sqtt: re-export shaders in a single bo")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26774>
(cherry picked from commit b55a2065e0)
Not expecting this to actually fix anything externally visible,
but reduces some invalid usage when the resulting vector is
not 16 elements long (e.g. the C/result matrix).
Fixes: 9df4703fbb ("radv: Add cooperative matrix lowering.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26768>
(cherry picked from commit 07ad6fd34a)
Testing negative iterations count makes no sense, and can cause issues
when the unsigned type is used.
Testing 0 iterations is already covered with
will_break_on_first_iteration, so it can be skipped too.
Fixes: 6772a17a ("nir: Add a loop analysis pass")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9913
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26173>
(cherry picked from commit a6459e0f7b)
When `MESA_LOADER_DRIVER_OVERRIDE` is set to `zink` and the display
initialization fails, fallback to software rendering.
The error was reported in #10123 and it can be reproduced with:
$ MESA_LOADER_DRIVER_OVERRIDE=zink eglinfo
`eglinfo` would crash in `dri2_display_release()` because of
`assert(dri2_dpy->ref_count > 0)`.
After bisecting the error to commit 8cd44b8843 ("egl/glx: add
autoloading for zink"), I found out that, before this change, the
display was set to initialized even when `_eglDriver.Initialize(disp)`
failed:
disp->Options.Zink = env && !strcmp(env, "zink");
// disp->Options.Zink is true
if (!_eglDriver.Initialize(disp)) {
[...]
// Zink initialization has failed at this point
// However, success is set to true:
bool success = disp->Options.Zink;
if (!disp->Options.Zink && !getenv("GALLIUM_DRIVER")) {
[...]
}
// Software initialization is ignored because success is true
if (!success) {
[...]
}
}
// The display is set as initialized even though it shouldn't
disp->Initialized = EGL_TRUE;
Resolves: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10123
Fixes: 8cd44b8843 ("egl/glx: add autoloading for zink")
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26184>
(cherry picked from commit d913927fe9)
This was missing from the FS stage primitive-id check. Also add usage
of macro to avoid running any extra code on platforms where this WA
would not apply.
Fixes: 0f14724039 ("iris: Implement Wa_14015297576")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26709>
(cherry picked from commit 82553774e2)
Chain stored modifiers point to the mapping of the current feedback
shmem of the surface. The surface tracked feedback mapping will be gone
and replaced with new mapping during surface_dmabuf_feedback_done. There
are two issues here:
1. One issue is that the existing mapping is closed before been used to
compare against new modifiers in sets_of_modifiers_are_the_same.
2. The other issue is that when the chain is still optimal, the chain
persists while the mapping is still replaced with the one from the
new format table shmem.
This change makes a deep copy of the modifiers to store in the chain to
ensure the modifiers used for the current chain are immutable through
the chain lifecycle.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26618>
(cherry picked from commit ddf2ca4faf)
