Commit 8f6fca89aa from !30952 by @zmike
renamed with_dri3 as with_dri in many places, but mistakenly deleted it
there, instead of renaming it. This causes the linking of gallium to fail
because of missing xcb_xfixes_destroy_region symbol from xcb-fixes.
This is basically replaying commit cf17d62516
from !7164 by @duncan.hopkins but with the new syntax.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31246>
Pass application provided damage region to the compositor instead
of damaging the entire display. This also gives us the possibility
in the future to have put image only copy the parts of the framebuffer
that were modified.
Fixes: fa465e34ca
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31210>
swapping buffers with damage is supposed to swap the entire buffer
and only pass the damage region as a hint to compositor as to what
updated. This change forces drisw to copy the entire buffer as there
is no method right now to check what was updated.
Fixes: cda627eb48
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31210>
For some reasons, this triggers only on VanGogh with some tests that
copy layered BCn images but they all pass in release build.
Suggested-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31226>
Otherwise we can end up generating invalid assembly not following
destination/source alignments requirements.
Fixes the following tests:
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_4.tan_frag
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_2.tan_frag
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_1.tan_frag
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_3.tan_frag
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Backport-to: 24.2
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31206>
The inner loop with p is dead, because n_passes_written is no longer
updated as of 56bd81ee21, so it is always
comparing a uint32_t < 0, which is never true. Since the inner loop is
dead code, the pass array is dead code, as it simply keeps writing to
element 0, and but never reads or uses it, along with all of the pass
count information.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31213>
These calls were missing error-handling, but all the pieces to do so are
already in place. Let's report the errors as appropriate.
Fixes: 5544d39f44 ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31216>
This is no longer r62, it's r90. But we don't need to be explicit about
it, so let's be a bit more vague in the comment here.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31216>
We need a clean because descriptor/CS memory can be returned to the
command pool where they get recycled. If we don't clean dirty cache
lines, those cache lines might get evicted asynchronously and their
content pushed back to main memory after the CPU has written new stuff
there.
Reported-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 5544d39f44 ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31225>
Turns out not even VK CTS was calling
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR()
to check if queue supports query.
So here adding a explicity check in our implementation of
vkCreateQueryPool().
https://github.com/KhronosGroup/VK-GL-CTS/pull/482
Cc: 24.2 <mesa-stable>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30652>
The query pool batch buffer or other bos could not be bound when
exec starts.
Cc: 24.2 <mesa-stable>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30652>
