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>
glCompileShader can use two different sources, so we need 2 different SHA1s
there. Successful compilation sets compiled_source_sha1.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13869>
The big comment was not really true.
The other debug options are unused right now, but will be used again
in the future.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13878>
We don't set them and we don't read them if they are disabled, so don't
print them either. This silences valgrind warnings.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13878>
src/amd/compiler/aco_optimizer.cpp:1316:17: runtime error: shift
exponent 32 is too large for 32-bit type 'unsigned int'
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/13951>
src/amd/vulkan/radv_cmd_buffer.c:3232:75: runtime error: index 252 out
of bounds for type 'uint8_t [128]'
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/13951>
src/amd/common/ac_nir_lower_ngg.c:1135:62: runtime error: left shift
of 1 by 31 places cannot be represented in type 'int
src/amd/common/ac_nir_lower_ngg.c:622:20: runtime error: left shift
of 1 by 31 places cannot be represented in type 'int'
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/13951>
to also get rid of the additional function that I introduced before.
Fixes: 82b261417e ("util/cpu_detect: Add flag for IBM Z (s390x)")
Signed-off-by: Marius Hillenbrand <mhillen@linux.ibm.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13958>
These macros expand to a mov in an if statement which breaks address
assumption that instruction which produces address and consumes it
are in the same block.
Fixes test:
dEQP-VK.subgroups.ballot_broadcast.framebuffer.subgroupbroadcast_intvertex
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13931>
I was trying to be clever here, skipping ahead to the newly-created
block and processing the remaining instructions after the split in the
same loop. But if the last instruction in a block was lowered, the saved
next instruction would be the head of the block before the split, not
the new block, and we would compare it to the new block so we wouldn't
stop like we were supposed to. Stop being so clever, and just restart
processing with the new block after lowering an instruction.
Because we're wrapping the actual transform in yet another loop, and the
restarting logic is a bit tricky, refactor the actual lowering into a
separate lower_instr function. Otherwise we'd be mixing the two and
indenting the actual logic even more.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13928>
This was plain broken. The solution is to not require any framebuffer
changes. Silently skipping results in broken behavior. e.g:
(secondary cmdbuffer with no framebuffer)
ClearAttachment 2
translated into
bind attachment 2 as attachment 0 (skipped)
clear attachment 0
restore original bindings (skipped)
which results in clearing attachment 0, not what we wanted. It is
a small wonder CTS doesn't find it until VK_KHR_dynamic_rendering.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13699>
They might not be available in secondary cmdbuffers with inheritance.
To avoid binding anything we need to create pipelines per attachment
index. I've excluded these from the "compile on device creation" set
because I think almost nobody will need them.
Alternative solution would be to reuse the same shader but muck with
a bunch of registers to shift them for the attachment index. That is
however a lot of complexity and has to execute on every pipeline
change, which is probably more expensive in overhead and definitely
in complexity.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13699>
If we have an inherited subpass in a cmdbuffer we can't really
emit any framebuffer data if it isn't provided.
Note we still do it for resolve clears, but we can't have that
in a secondary cmdbuffer with inherited renderpass.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13699>
When cloning a chunk of tracepoints, we cannot just copy the elements
of the traces[] array. We also need the payloads associated with
those.
This change introduces a new u_trace_payloaf_buf object that is
refcounted so that we can easily import traces[] elements and their
payloads from one utrace to another.
v2: use u_vector (Danylo)
v3: Delete outdate comment (Danylo)
Fix assert (Danylo)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0565c993f9 ("u_trace: helpers for tracing tiling GPUs and re-usable VK cmdbuffers")
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13899>
