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>
Add function loader_get_render_node() to help us to get a render node
from dev_t. If the device does not expose a render node, this new
function returns NULL.
As this function uses drmGetDeviceFromDevId(), we bump libdrm minimal
version to 2.4.109.
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 will allow us to remove EGL_DRI2_NUM_FORMATS (as explained in
"egl/wayland: remove unused constant EGL_DRI2_NUM_FORMATS") and it will
also help to add the dma-buf feedback support. Both changes happen in
the next commits.
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>
Most Wayland compositors have already implemented the dma-buf protocol
extension. So we can stop relying on the wl_drm events and start to
depend only on the dma-buf interface to receive format/modifier pairs
and create wl_buffer's. So we can deprecate drm_handle_format() and
drm_handle_capabilities().
Note that we still use the wl_drm interface to find out the DRM device
that the compositor is using, so we can't deprecate it fully for now. In
the future (when the dma-buf feedback interface is added to the dma-buf
protocol extension [1] and most compositors incorporate it) we may be
able to fully deprecate wl_drm.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
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>
Currently we have a weird design. We have a hardcoded array (named
dri2_wl_visuals) with all the formats that we support, which are 9.
And we also have EGL_DRI2_MAX_FORMATS, which is a constant set to 10. In
patches in which people added new formats to dri2_wl_visuals, this
constant had its value increased. This is confusing, as its name gives
the idea that we can't support more formats.
This constant is only used to define the bitset size of
dri2_egl_display::formats. And it should work just fine if we created
this bitset with the number of formats supported.
To make things clearer, replace EGL_DRI2_MAX_FORMATS by
EGL_DRI2_NUM_FORMATS, which must be equal to ARRAY_SIZE(dri2_wl_visuals)
(i.e. the number of supported formats).
In the next commits we get rid of this constant completely, as it is
prone to errors.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
If we want to add a variable with a type name that is too long, we have
to realign all the variables within these structs. The other option is
to ignore and don't realign, and then we end up with a very ugly code.
So get rid of these unnecessary spaces, as they don't bring anything
useful. Instead, they are annoying.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
Rather than relying on distro packages, build libwayland and
wayland-protocols from known versions everywhere we need it.
The only place we do not do so but rely on distro packages is the LAVA
rootfs, for which it does not matter right now since the version is
sufficiently new, but this could/should be cleaned up later.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>