Some Wayland compositors, notably Exo, do not always release buffers
fast enough, and not in sync with their frame callbacks, to guarantee
that a free buffer is available the next time a client calls
`eglSwapBuffers()`.
This currently leads to a crash in `dri2_wl_swrast_get_backbuffer_data()`
with the swrast backend. To avoid this, simply block until the
compositor releases a buffer eventually.
While arguably compositors should release buffers they don't need any
more for the next frame, this can be quite complex depending on
the architecture - notably multi-process/IPC in case of Exo.
cc: mesa-stable
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24091>
(cherry picked from commit 74451ed3f0)
Do not try to determine the shader stage from the compiled shader
variant, which may be NULL after compile failure. Instead, get it
from the NIR shader.
Fixes a segfault when trying to evaluate etna_shader_stage(NULL)
after compile failure.
Suggested-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Fixes: 3d49619071 ("etnaviv: add support for performance warnings")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24178>
(cherry picked from commit f626605cbf)
From OpenGL ES 3.0 spec, page 56:
"Binding more than one attribute name to the same location
is referred to as aliasing, and is not permitted in OpenGL
ES Shading Language 3.00 vertex shaders. LinkProgram will
fail when this condition exists. However, aliasing is
possible in OpenGL ES Shading Language 1.00 vertex shaders.
This will only work if only one of the aliased attributes
is active in the executable program, or if no path through
the shader consumes more than one attribute of a set of
attributes aliased to the same location. A link error can
occur if the linker determines that every path through the
shader consumes multiple aliased attributes, but implemen-
tations are not required to generate an error in this case."
So here we make sure to allow the optimisations before validation
for earlier ES shader versions.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes: 80c001013c ("glsl: do vs attribute validation in NIR linker")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9342
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24205>
(cherry picked from commit c64ad299e4)
It turns out the hardware doesn't save the whole state on a context
switch, as the kernel expects when it creates the golden context.
For some HW units, only the state that was explicitly programmed will be
part of it, so we need to make sure mesh shading is disabled on context
creation, or we risk being context switched with an application that
uses mesh, and when ours gets to run again, the mesh state won't be
reset, and submitting a legacy 3D pipeline while the HW thinks mesh is
enabled causes us to hang.
Cc: 23.2 <mesa-stable>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24150>
(cherry picked from commit 7b0ded0b23)
It turns out the hardware doesn't save the whole state on a context
switch, as the kernel expects when it creates the golden context.
For some HW units, only the state that was explicitly programmed will be
part of it, so we need to make sure mesh shading is disabled on context
creation, or we risk being context switched with an application that
uses mesh, and when ours gets to run again, the mesh state won't be
reset, and submitting a legacy 3D pipeline while the HW thinks mesh is
enabled causes us to hang.
Cc: 23.2 <mesa-stable>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24150>
(cherry picked from commit 50d68f74b5)
It happened because glCallList was restoring varying_vp_inputs, which
caused every glCallList to process the state change again.
This loosely reverts commit 3a294ff01f
"mesa: move the _mesa_set_varying_vp_inputs call to where the state changes".
Fixes: 3a294ff01f - "mesa: move the _mesa_set_varying_vp_inputs call to where the state changes"
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24165>
(cherry picked from commit c97961a855)
nir_opt_mov and nir_op_vecN are only the same if the mov is only a
single component. Otherwise the vec loop will try to access src[c]
where c > 0 which breaks for nir_op_mov. It's uncommon but scalar
back-ends can see vector movs so we need to handle this correctly.
Fixes: 6513c675ad ("nv50/ir/nir: implement nir_alu_instr handling")
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24167>
(cherry picked from commit 259ba104f7)
This was missed in 0bf6dcb785
There is a loop which iterates over a temp array. NIR optimization
moves the real work out of the loop and what remains are just ALU ops
with undefs. So after converting undefs to zero, the ALU ops are
optimized out and DCE kills the loop. This is a good thing in
general and we don't fail the linking due to the loop presence.
However than we hit the shader constants and ALU limits later :-(
So from dEQP POW we go from NotSupported to Fail.
Fixes: 0bf6dcb785
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24134>
(cherry picked from commit 0a2a7bfd19)
The 1st sync scope of vkCmdCopyQueryPoolResults is not sufficient to
cover transfer writes against query feedback buffer. We must ensure
ordering against prior query reset cmd where the feedback buffer fill
gets injected.
Fixes: de4593faa1 ("venus: add query pool feedback cmds")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24130>
(cherry picked from commit ed79b30639)