For non 64bit devices the key stored in hash_table_u64 is wrapped in
hash_key_u64 structure, which is never free.
This commit fixes this issue by just removing the user-defined
`delete_function` parameter in hash_table_u64_{destroy,clear} (which
nobody is using) and using instead a delete function to free this
structure.
Fixes: 608257cf82 ("i965: Fix INTEL_DEBUG=bat")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10480>
Otherwise, if src_bit_size > 0 and dst_bit_size == 0, we end up doing a
bad shift in `1 << (dst_bit_size - 1)`, as `dst_bit_size - 1` is a
negative value (in this case would be MAX_UINT32).
Fixes CID#1468134 "Bad bit shift operation (BAD_SHIFT)":
"large_shift: In expression 1 << dst_bit_size - 1U, left shifting by
more than 31 bits has undefined behavior. The shift amount,
dst_bit_size - 1U, is 4294967295."
v2:
- Use an assertion instead (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10251>
As we are not using anymore references to the old VC5, let's rename
definitions from VC5 to V3D in the Vulkan driver.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10402>
We are referring the driver as V3D instead old VC5; so let's update the
references.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10402>
As the driver was renamed in the past from VC5 to V3D, let's rename also
the definitions and enumerations to keep it consistent across the code.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10402>
Long time ago VC5 was renamed to V3D, but the include guards `VC5_FOO_H`
were not.
In order to keep consistency, let's rename these guards from `VC5_FOO_H`
to `V3D_FOO_H`.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10402>
When we originally added patch variable handling to spirv_to_nir, we
were splitting I/O block variables in spirv_to_nir, so we weren't
guaranteed to have a nir_variable early enough in processing.
Since b0c643d8f5 ("spirv: Use NIR per-member splitting"), we've been
using NIR per-member splitting where we have a nir_variable which has
a separate nir_variable_data per member. With this, we can drop
vtn_variable::patch and use the patch boolean on the nir_variable
instead.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10469>
Fix defects reported by Coverity Scan.
member_not_init_in_gen_ctor: The compiler-generated constructor for this class does not initialize buf.
member_not_init_in_gen_ctor: The compiler-generated constructor for this class does not initialize st.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10399>
it's not really expected that most apps are going to be switching variants
all the time, so having the "default" one be more dynamic allows skipping
shader lookups more frequently
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10513>
no need for hashing or lookups if this is the default variant
also have an alt variant for vertex stages to account for streamout and
halfz lowering
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10513>
The idea is to allow the renderer to use a completely different external
memory handle type (e.g., OPAQUE_WIN32!?) than the driver (always
OPAQUE_FD and DMA_BUF). It hides the mismatch by doing translations in
vkGetPhysicalDevice*.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10437>
When two vn_renderer_bo's share the same gem_handle, destroying one of
them would invalidate the other.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10437>
It should be faster. More importantly, we want to use it to keep track
of all BOs for correct dmabuf import.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10437>
There is no good reason to seprate them. I also plan to adopt
util_sparse_array, which requires the kernel BO to be created first (to
use its gem_handle/res_id as the key).
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10437>
CPU BOs and GPU BOs are used different enough that it makes sense to
treat them as different objects. This commit adds vn_renderer_shmem to
represent CPU BOs.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10437>
Rename it to VN_CS_ENCODER_INITIALIZER_LOCAL to make it clear that it is
only for local variables.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10437>
This will allow us to change vn_instance_submit_command without
regenerating the headers.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10437>
The combination of removing bottlenecks in userspace (userspace fences,
etc) and slow GPU results in hitting full ringbuffer on a306. Haven't
figured out a reasonable way to work around that in userspace until a
kernel fix is in place, so disable this one for now.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10444>
Move the submit ioctl to it's own thread to unblock the driver thread
and let it move on to the next frame.
Note that I did experiment with doing the append_bo() parts
synchronously on the theory that we should be more likely to hit the
fast path if we did that part of submit merging before the bo was
potentially re-used in the next batch/submit. It helped some things
by a couple percent, but hurt more things.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10444>
A more direct solution would be for bo's to have a reference to the
device. But bo's are ref/unrefd more frequently.
This avoids async submits unrefing a bo after the device handle-
table is freed.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10444>
