As per
fb9b2a8731,
the compositor may advertise DRM_FORMAT_MOD_INVALID as a supported
modifier. This patch makes mesa recognize this fact and allow
linux_dmabuf usage with the INVALID modifier in this case.
In case the driver doesn't support modifiers, we can still use
linux-dmabuf protocol instead of the legacy wl_drm interface to create
wl_buffers. This will help compositors to handle these buffers better.
In this commit, the INVALID modifier is allowed to be added to the list
of supported modifiers, and create_wl_buffer will be able to use
linux_dmabuf with an INVALID modifier if the compositor advertised it as
supported.
Signed-off-by: Ivan Molodetskikh <yalterz@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2147>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2147>
Now that we have 7 (soon 8) boards available, there's capacity to be
testing GLES 3.0. However, due to (it looks like) buffer overflows in the
driver, we end up with flaky test results: 1/60 jobs spuriously failed,
and another 6/60 jobs reported flakes. At 6 jobs per pipeline, that's way
too high of a failure rate to enable for non-freedreno developers. Leave
the job present but disabled so that we can do manual test runs for
regressions.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3661>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3661>
This should get us better stability of the db410c boards by having a
smaller per-board software stack, with no disks involved (just initramfs).
Additionally, the new cluster is 7 (soon 8) db410cs, while currently the
docker cluster only has 1/4 of its db410cs still running.
Unfortunately, we have to prepare the fastboot boot image during the ARM
drivers build stage, because LAVA relies on publicly available URLs for
the images to load into the bootloaders of the boards, and the only thing
we have for that is gitlab's artifacts.
Note that this testing relies on the boards being freshly flashed with the
linaro v136 firmware to pick up the initramfs size fixes and to stop the
boot at fastboot.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3661>
In all these cases the type was tested before based, so don't use
dynamic_casts.
Closes#2566
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Tested-by: Mauro Rossi <issor.oruam@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3974>
It's not always 4, for example on RAVEN there is only one.
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/4018>
Here we reset the counter to 0 for each shader stage not each program.
We also make add a flag to stop iterating over indices that have
already been processed.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3992>
This fixes the image index calculation in the nir linker. We need
to reset the counter to 0 for each shader stage not each program.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3992>
Use UniformDataSlots for the context of UniformDataDefaults rather
than UniformStorage as in some cause UniformStorage may be NULL.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3992>
Our current GPGPU_WALKER code only supports up to 64 threads.
On HSW we could use up to 70 and TGL up to 112, but only if the walker
is adjusted so the width does not exceed 64. Work to support this is
in progress.
Previous to this change, we might try to downgrade to SIMD8 if the
SIMD16 shader spilled. Since HSW and TGL have the max number of
threads above 64, we would then try to emit an invalid GPGPU walker
command.
Fixes: 932045061b ("i965/cs: Emit compute shader code and upload programs")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Need to list_delinit() before we clone the instruction to split it into
individual samgpN instructions, otherwise we get list corruption.
Tested-by: Eduardo Lima Mitev <elima@igalia.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3989>
1) emperically, 10 seems like a more accurate # than 4
2) push "soft" delay handling into ir3_delayslots(), as
we should also be using it to calculate the costs
that the schedulers use
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3989>
In schedule live value tracking, differentiate between half vs full
precision. Half-precision live values are less costly than full
precision.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3989>
Current scheduler thresholds try to ensure there are warps available to
switch to when hiding texture fetch latency. But if there is none to
hide, we should allow scheduler to use more registers to reduce nops.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3989>
To avoid spurious sync flags, we want to, for a6xx+, operate in terms of
half-regs, with a full precision register testing the corresponding two
half-regs that it conflicts with.
And while we are at it, stop open-coding BITSET
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3989>
