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)
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)
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)
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)
When we start to support GPUs with more then 16 varyings the code base
tells us that there is some work to do.
Cc: mesa-stable
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26662>
(cherry picked from commit 2f205caea4)
Update to rnndb commit 071f5a60dcb8.
This updates VIVS_PA_SHADER_ATTRIBUTES__LEN define from 10 to 16 and
fixes memory corruption if more then 10 varyings are used. The current
upper limit for varyings is 16.
Cc: mesa-stable
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26662>
(cherry picked from commit 11ffb20b70)
Since dbbf566588 ("aco,ac/llvm,radeonsi: lower f2f16 to f2f16_rtz in nir")
radeonsi behavior changed and some of the core fp16 ops broke as a result.
We should explicitly specify the rounding mode until we add an gallium API
for drivers to advertize what they prefer.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26655>
(cherry picked from commit d136583c82)
Treat R8_G8B8_420_UNORM and NV12 the same, because dri2 frontend doesn't
understand or care about the difference from the sampler PoV.
Fixes: 1e820ac128 ("freedreno: Rework supported-modifiers handling")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26601>
(cherry picked from commit 2132f95de0)
We never steal the NIR program or free it explicitly, and the state
tracker expects drivers to take ownership of the program object. Since
panfrost doesn't need to keep the original NIR shader around for
compute, let's just free it before returning.
Fixes: 40372bd720 ("panfrost: Implement a disk cache")
Cc: stable
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26424>
(cherry picked from commit 692a4b1804)
The `zink_internal_create_screen()` function initializes
`screen->drm_fd` to 0, a valid file descriptor value, via `rzalloc`.
If an error is found during initialization, the `zink_destroy_screen()`
function is invoked in the `fail` label and the `screen->drm_fd` is
closed because its value is 0 and `screen->drm_fd != -1` is checked.
Initialize `screen->drm_fd` to -1 to avoid this issue.
Resolves: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10191
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26332>
(cherry picked from commit fff3fc45a0)
Enables 10 bpc / color depth 30 bit support under XOrg
with X11/GLX/OpenGL.
Successfully tested with RaspberryPi OS 11,
running X-Server 1.20, and also with Weston,
on a RaspberryPi 400 on top of current Mesa 24.0-devel.
Alejandro Piñeiro also performed a GLES CTS run
with successful result, citing him:
"Full GLES 31 CTS finished with 0 failres. So all ok"
Note that this commit was originally developed and
successfully tested by myself against Mesa 23.1-devel
from February 2023, and therefore should apply and work
cleanly against recent Mesa stable branches. One could
see this commit as a trivial compatibility fix against
X-Server 1.20 / modesetting-ddx 1.20, which is why I'm
also nominating this commit for the current 23.3 stable
branch, and also the 23.2 stable branch, so it may make
it into RaspberryPi OS 12. Thanks for the consideration.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Backport-to: 23.2
Backport-to: 23.3
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26472>
(cherry picked from commit 1700c6af6f)
Otherwise ctx->VertexProgram._VaryingInputs might not be up to date.
We can't do this in update_program because this breaks vbo_save_playback_vertex_list_gallium:
const GLbitfield enabled = node->enabled_attribs[mode];
_mesa_set_varying_vp_inputs(ctx, enabled); <-- update _VaryingInputs
if (ctx->NewState)
_mesa_update_state(ctx); <-- calls update_program, reverting the
change made above
Fixes: c97961a855 ("mesa: fix 38% decrease in display list performance of Viewperf2020/NX8_StudioAA")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9441
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25956>
(cherry picked from commit 64352ae8e4)
This is required in order to return the correct value for
`gbm_dri_bo_get_offset()` for e.g. the second plane of a NV12 image.
Use the newly introduced `util_resource` helper and, while on it, also
add support for `gbm_bo_get_plane_count()`.
Cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26283>
(cherry picked from commit 2404483706)
This is required in order to return the correct value for
`gbm_dri_bo_get_offset()` for e.g. the second plane of a NV12 image.
Use the newly introduced `util_resource` helper and, while on it, also
add support for `gbm_bo_get_plane_count()`.
Cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26283>
(cherry picked from commit cb8cdab928)
In environments where 3D acceleration is not available, like in a VM,
the behavior before commit 8cd44b8843 ("egl: add automatic zink
fallback loading between hw and sw drivers") was to fallback to swrast.
This was the output of `eglinfo` in that situation:
$ eglinfo
[...]
Wayland platform:
EGL driver name: swrast
OpenGL core profile renderer: llvmpipe (LLVM 17.0.4, 256 bits)
However, after commit 8cd44b8843 ("egl: add automatic zink fallback
loading between hw and sw drivers") Zink support is tested before
falling back to swrast.
Since the system doesn't support 3D acceleration, Zink + software
rendering is used instead of swrast causing issues like the ones
described in #10146.
In this case, `eglinfo` prints:
$ eglinfo
[...]
Wayland platform:
EGL driver name: zink
OpenGL core profile renderer: zink Vulkan 1.3(llvmpipe (LLVM 17.0.4,
256 bits) (MESA_LLVMPIPE))
This patch ensures that Zink + software rendering is used only when the
user opts-in by setting `LIBGL_ALWAYS_SOFTWARE` or `D3D_ALWAYS_SOFTWARE`
and swrast is used otherwise.
After the patch, the output of `eglinfo` is identical to the one before
the regression:
$ eglinfo
[...]
Wayland platform:
EGL driver name: swrast
OpenGL core profile renderer: llvmpipe (LLVM 17.0.4, 256 bits)
Resolves: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10146
Fixes: 8cd44b8843 ("egl: add automatic zink fallback loading between
hw and sw drivers")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26220>
(cherry picked from commit 2a71f06f29)
In order to return correct offsets, strides and possibly other
parameters. This is relevant for formats like NV12 and P010 where
the second plane, when produced by the V4L2 decoder, uses the
same FD like the first one, but with an offset.
Analogous to 7a7e577d.
Also use the new helper to get the number of planes.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10094
Cc: mesa-stable
Reviewed-by: Italo Nicola <italonicola@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26109>
(cherry picked from commit 5f4253e096)
