There are paths were a v3d screen can be created instead of vc4 screen,
in a real rpi4 hardware. For instance, in the CI itself.
So assuming that it was only possible with the simulator was wrong.
This reverts commit c31be1f4ba.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27047>
Prior to 06b526de, the mesa format was used for these completeness checks.
That was to address the case where a *different* internal format selected
the *same* mesa format, and the texture shouldn't be considered compatible.
But this didn't address the case where the *same* internal format selected
a *different* mesa format, e.g. because the type passed to the TexImage
API was different.
An old WGL demo app called TexFilter.exe tries to redefine a mipped RGBA16
texture as RGBA8. This incorrect logic caused Mesa to try to copy the RGBA16
data from the smaller mips into the newly created RGBA8 data, because it
thought that the texture was still mip-complete, despite the format changing.
Cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27023>
These use different tables but map to the same bits, so it is just
a matter of picking the right tables for the instruction.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26860>
ring_seqno_valid indicates a successful ring cmd submission, and can be
used to avoid invalid reply decoding due to failed submit alloc.
Otherwise, the garbled VkResult will mislead into initialization failure
instead of oom.
Below cts failure is fixed:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
Fixes: ec131c6e55 ("venus: use instance allocator for ring allocs")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27026>
While it technically was already only using an ir_instruction field, better make
sure that it is effectively an ir_variable using the dedicated method instead of
relying on an undefined behavior.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26144>
The parameter_lists_match_exact function was wrongly assuming that all the
elements were ir_variable when there can also be ir_dereference_variable elements.
Add case taking this into account.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26144>
The vdrm_execbuf() missed to set the seqno field for requests sent to host.
This causes vdrm_host_sync() to lock up due to the unset seqno in a case
where two or more threads are using vdrm_execbuf() and vdrm_send_req()
concurrently, like in this scenario:
thread1: vdrm_send_req() shmem->seqno=1 req->seqno=2
thread2: vdrm_execbuf() shmem->seqno=1 req->seqno=0
thread1: vdrm_host_sync() shmem->seqno=0 req->seqno=2
Fix the lockup by setting the seqno in vdrm_execbuf().
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27021>
If we have to wait for a buffer to be released in swrast_update_buffers(),
we can leak it.
Take care to reuse the existing buffer if one is still available.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26761>
Refactor emit_dynamic_buffer_binding_table_entry to emit a null surface
state when the descriptor has no assocaited buffers allowing us to drop
the same check elsewhere.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27005>
While it passes locally, the runners are slow enough to not make it in
60 seconds so just move it to skips.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26973>
The max waves for RT prolog need to be recalculated after merging the
resource usage of all shaders invoked from it.
Note that there is no need to panic, as the info was only used to
calculate maximum scratch size and with the RT prolog being low
footprint, this likely only caused overestimation rather than
underestimation.
Fixes: 533ec9843e ("radv: Precompute shader max_waves.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26998>
