libLLVM for Android is built without RTTI, but after commit ad86267
mesa inherits meson default RTTI enabled state.
cpp_rtti=false is added to meson options in android/mesa3d_cross.mk
(v2) Add Fixes tag and use spaces instead of tabs for aligning the trailing \
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Fixes: ad862674 ("meson: Don't override built-in cpp_rtti option, error if it's invalid")
Cc: "21.3" "21.2" mesa-stable
Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13901>
These flags control special CRC handling for empty tiles using the CRC
clear colour field added on Bifrost. Their use depends on CRC being
used. We missed these flags earlier; let's add them since they are used
by the Valhall DDK but are not new to Valhall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13982>
If there is holes, eg. the application firsts set vertex attributes
0 and 1, then vertex attributes 0 and 7, the format of vertex attribute
1 is still the previous one, while it should be FORMAT_INVALID to avoid
a GPU hang.
This fixes a GPU hang with Yuzu.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5627
Cc: 21.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13856>
ISL recently started allowing linear ASTC surfaces to be created. With
that in place, iris can perform GPU-based uploads to ASTC textures in
the same way it does so with other compressed surfaces.
We're not aware of any reason to continue special-casing ASTC texture
uploads, so we get rid of the code which does so.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13881>
The sampler can only decode ASTC surfaces that are Y-tiled. ISL has
been asserting this restriction at surface creation time.
However, some drivers want to create a surface that is only used for
copying compressed data. And during the copy, the surface won't have a
compressed format.
To enable this behavior, we choose to move the tiling assertion to the
moment a surface state is created for the sampler.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13881>
We don't support typed image writes for multisampling, so we can't
handle multisampled destinations. We also usually handle MSAA by
running the fragment shader per-sample, which we aren't accounting
for in our compute shaders, so we can't handle MSAA sources either.
We could do both of these things if we really wanted to, but we don't.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13524>
When we're doing a stencil blit via a fragment shader, we can avoid
W-tiling shenanigans by using the stencil write hardware on Skylake
and later.
Of course, the compute engine doesn't have stencil fragment writes,
so it can't do that. Just fall back to the detiling shenanigans.
Caught by Piglit's arb_copy_image-formats when forcing iris to use
BLOCS for resource_copy_region on Icelake.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13524>
When dispatching compute shaders to do a blit, our destination rectangle
may not line up perfectly with the workgroup size. For example, we may
round the left x0 coordinate down to a multiple of the workgroup width,
and the right x1 coordinate up to the next multiple of the workgroup
width. Similarly for y0/y1 and workgroup height. This means that we
may dispatch additional invocations which should not actually do any
blitting. We need to set key->uses_kill to bounds check and drop those.
Caught by Piglit's arb_copy_image-simple when forcing iris to perform
resource_copy_region via BLOCS and running with INTEL_DEBUG=norbc on
Icelake.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13524>
This code was originally made for crocus by Dave Airlie.
Iris is also affected, so this commit ports the fix.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12993>
egl-copy-buffers test has been fixed for dri3. So remove
it from broadcom and freedreno ci fail list to prevent the
gitlab ci test fail:
spec@egl 1.4@egl-copy-buffers,UnexpectedPass
Also remove it from radeonsi ci fail list since I verified
on radeonsi.
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13868>
In the test no front buffer has been allocated on the client
side, so we get a segfault when access it directly.
eglCopyBuffers() just need to do server side copy, so we don't
really need to create a client side front buffer to perform
the copy.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13868>
In some non-trivial cases (the amber script file in the merge
request description) phi instruction has more than 32 elements
in predecessors tree and that isn't recursion, just large tree.
In that case, phis not fully converted into a register or mov,
but successfully removed.
The fix removes the counter and adds container of visited blocks.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3690
Cc: mesa-stable
Signed-off-by: Mykhailo Skorokhodov <mykhailo.skorokhodov@globallogic.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13710>
If there is a halt or return instruction right before a loop with a single
continue, we would have taken the fast path intended for loops without
continues.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Tested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 71a985d80b ("nir/dce: perform DCE for unlooped instructions in a single pass")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10284>
It turns out that BLEND_MIN and BLEND_MAX in Utgard take blend factors
into account. My guess is that actual equation looks like:
OP(As * S + Ad * D, Ad) for alpha, and
OP(Cs * S + Cd * D, Cd) for color.
So we have to set S factor to 1 and D factor to 0 to be compliant with
GL spec.
Fixes following piglit tests:
spec@!opengl 1.4@blendminmax
spec@arb_blend_func_extended@arb_blend_func_extended-fbo-extended-blend
(with patch my for ES2_compatibility and EXT_blend_func_extended)
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13873>
It was a bit trickier to RE, since blob doesn't expose this
functionality at all, however we had a clue from the very beginning:
lima_blend_factor is 3 bits, i.e. 8 values, but only 5 of them were
used, it just waited till someone tried what 3 unused values do.
Interestingly enough, it turns out "5" works just as "0" (which is
PIPE_BLENDFACTOR_*SRC_*), but only if output register for gl_FragColor
is $0, So it looks suspiciously similar with PIPE_BLENDFACTOR_*SRC1_*
behavior, and looks like secondary output is taken from $0.
Since output regs for all other outputs are configured via RSW, there
must be a field in RSW for output register for secondary color, it's
likely 4 bits and it's currently set to 0 for reg $0.
Then it was just a matter of brute-forcing various consecutive 4 bits
in RSW - and indeed, setting top 4 bits of rsw->aux0 to the index of
gl_FragColor output register fixes blending tests when we use "5"
blend factor instead of "0".
So it must be a register number for gl_SecondaryFragColor. Unlike
gl_FragColor, the field is only repeated once in RSW.
Wire it up in compiler, and piglit arb_blend_func_extended now passes.
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13873>
It's needed by _mesa_half_to_float(), without this change it hits
assertion failure in util_get_cpu_caps().
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13968>
This has no effects, except for XFB but that shouldn't really matter.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13542>
The shader locations are now directly stored in radv_shader_args which
makes sense because they are tied to the arguments. The locations are
then copied to radv_shader_info but they will be moved into a new
radv_shader_binary_info with upcoming changes.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13542>
The game calls vkGetSemaphoreCounterValue() with an invalid semaphore
handle and it crashes. This is an invalid Vulkan usage and it should
be fixed in the game. I reported the issue to the developers.
Workaround this temporarily (hopefully) by ignoring
vkGetSemaphoreCounterValue() if the semaphore is NULL from an internal
RADV layer.
Cc: 21.3 mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5119
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13956>
Detected by UBSAN.
../src/amd/vulkan/radv_private.h:2939:1: runtime error: member access
within null pointer of type 'struct radv_device_memory'
../src/amd/vulkan/radv_private.h:2926:1: runtime error: member access
within null pointer of type 'struct radv_buffer'
../src/amd/vulkan/radv_private.h:2945:1: runtime error: member access
within null pointer of type 'struct radv_image'
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13965>
The variant may include a lowered gl_Clip/CullDistance array. So we have
to use the variant's info (which is not available). However we save off
the clip/cull masks already, so just reuse those.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13891>
We expose the compact array cap, which means that we get compact
clipdist arrays. Indicate this to the lowering pass so that it works for
gl_ClipDistance from fs, among others.
Fixes, among others, on a420,
tests/spec/glsl-1.30/execution/clipping/fs-clip-distance-interpolated.shader_test
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13891>
gl_ClipDistance most definitely can be read in fragment shaders since
GLSL 1.30. This is also accessible in ES with EXT_clip_cull_distance.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13917>
As explained in "egl/wayland: add initial dma-buf feedback support", we
still don't use the per-surface dma-buf feedback. In this patch we start
to use it.
If per-surface dma-buf feedback is advertised, use it to allocate
surface buffers. Also, the dma-buf protocol states that the feedback is
resent only when the client is using a suboptimal format/modifier pair.
So listen for new per-surface feedback events and reallocate the surface
buffers based on them. We can't change the format of a buffer, but we
can pick a new modifier.
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
In get_back_bo() we have two calls to loader_dri_create_image() and some
overhead. As in the next commit we add another call to this same
function and more overhead to get_back_bo(), it starts to lose
legibility.
So move loader_dri_create_image() calls to separate functions, allowing
us to have an easier to read get_back_bo(). It also adds some minor
style changes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
This bumps the supported dma-buf version up to 4 and adds the initial
dma-buf feedback implementation. It follows the changes in the dma-buf
protocol extension [1] to include the dma-buf feedback interface, which
should be incorporated by most Wayland compositors in the future.
From version 4 onwards, the dma-buf modifier events are not sent by the
compositor anymore, so we use the default feedback to pick the set of
formats/modifiers supported by the compositor. Also, we try to avoid the
wl_drm device event and instead use the dma-buf feedback main device. We
only fallback to wl_drm when the compositor advertises a device that
does not have a render node associated.
In this initial dma-buf feedback implementation we still don't do
anything with the per-surface dma-buf feedback, but in the next commits
we add proper support.
It's important to mention that this also bumps the minimal supported
version of wayland-protocols to 1.24, in order to include [1].
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
