Commit 84e93daa26 ("freedreno/registers: allow skipping the
validation") synced a change that made validation optional for
kernel builds, to avoid a lxml dependency for kernel builds.
But this inadvertantly also disabled schema validation on the
mesa side. CI (and meson "test" target) still validates the
xml against the schema, but it is easier if this is also done
as part of the normal build to avoid suprises from Marge.
Fixes: 84e93daa26 ("freedreno/registers: allow skipping the validation")
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37216>
Replace the basic debug message for unsupported blits with a comprehensive
dump of the blit parameters and make it a hard failure. This helps identify
exactly what blit operations are not supported and ensures they don't fail
silently in debug builds.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37034>
The attachment loadOp for stencil buffers is not stored at
attachment->desc.loadOp. It is stored at attachment->desc.stencilLoadOp
so v3dv was ignoring the clear values for stencil if the depth buffer
wasn't setup with the VK_ATTACHMENT_LOAD_OP_CLEAR.
Fixes: 4d0e497a3e ("v3dv: implement support for depth testing")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37228>
Transient attachments have been in Vulkan since 1.0, and are a way to
avoid allocating memory for attachments that can be stored entirely in
tile memory. The driver exposes a memory type with LAZILY_ALLOCATED_BIT,
and apps use this type to allocate images with TRANSIENT_ATTACHMENT
usage, which are restricted to color/depth/stencil/input attachment
usage. The driver is supposed to then delay allocating memory until it
knows that one of the images bound to the VkDeviceMemory must have
actual backing memory.
Implement this using the "lazy VMA" mechanism added earlier. We reserve
an iova range for lazy BOs, and only allocate them if we chose sysmem
rendering or there is a LOAD_OP_LOAD/STORE_OP_STORE. Because we never
split render passes and force sysmem instead, we don't have to deal with
the additional complexity of that here and just allocate everything.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37151>
Up until now tu_device_memory (turnip's VkDeviceMemory) was a thin
wrapper around tu_bo (the GEM BO), so when binding an image to a
VkDeviceMemory we could just store the BO. But now we have to skip
allocating the BO unless we need to for lazily-allocated memory, and the
tracking for that needs to happen at the API level instead of the
kernel/GEM level, so store the tu_device_memory instead.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37151>
Add an extremely limited form of sparse where zeroing memory is not
supported and only one BO can be fully bound to the sparse VMA
immediately when it's created. This can be implemented on drm/msm even
without VM_BIND, by just reserving the iova range. However kgsl doesn't
let us control iova offsets, so we have to use "real" sparse support to
implement it. In effect this lets us reserve an iova range and then
"lazily" allocate the BO. This will be used for transient allocations in
Vulkan when we have to fallback to sysmem.
As part of this we add skeleton sparse VMA support to virtio, which is
just enough for lazy VMAs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37151>
Reserve an iova range separately before allocating a BO. This reduces
the size of the critical section under the VMA lock and paves the way
for lazy BOs, where iova initialization is separated out.
While we're here, shrink the area where the VMA mutex is applied when
importing a dma-buf. AFAICT it's not useful to lock the entire function,
only the VMA lookup and zombie BO handling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37151>
When enabling
dEQP-VK.renderpass2.dedicated_allocation.attachment_allocation.grow.17,
we see a hang on a618 when a draw is immediately followed by a blit
without anything in between. The draw and clear are writing completely
different surfaces.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37151>
Wayland EGL applications often set SwapInterval 0 and then use surface
frame callbacks independently to pace their updates. These applications
don't actually want the display to tear, and we do not currently use
wayland tearing_control protocol on EGL to enable tearing behaviour.
Using a tearing presentation mode in Vulkan will lead to unexpected
behaviour for these applications.
Use MAILBOX on wayland instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34842>
On Valhall, we can end up with a lot of convertions for 8-bit and 16-bit
values.
However, since Valhall, we have access to a lot more swizzles on widen
sources.
The idea of this pass is to propagate replicate swizzle usages to
simplify things.
We do not attempt to propagate MKVEC.v2i16 as it is already handled by
bi_lower_swizzle.
This changes the following:
9 = V2S8_TO_V2S16 !7.b0
11 = IADD.v2s16 !9.h00, u4
88 = MKVEC.v2i8 11.b0, u256.b0, u256
13 = IMUL.v4i8 !88.b0, 8.b0
14 = V2S8_TO_V2S16 !13.b0
15 = IADD.v2s16 14.h00, !11.h00
89 = MKVEC.v2i8 !15.b0, u256.b0, u256
17 = IMUL.v4i8 !89.b0, !8.b0
Into this:
11 = IADD.v2s16 !7.b0, u4
13 = IMUL.v4i8 11.b0, 8.b0
15 = IADD.v2s16 13.b0, !11.h00
17 = IMUL.v4i8 !15.b0, !8.b0
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37167>
src/intel/perf/xe/intel_perf.c:420:27: warning: implicit conversion from enumeration type 'enum drm_xe_eu_stall_property_id' to different enumeration type 'enum drm_xe_oa_property_id' [-Wenum-conversion]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37172>
We don't (yet) have the ability to say that more than one value is
acceptable, and the yaml module we use complains about duplicate keys,
so let's just comment them out as it doesn't care about missing keys and
doesn't remove comments.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37215>
The definitive linux kernel counterpart update is now merged.
The linux kernel commit dc5c742f41c0a1c2b14e4357c752851e015f3bcd
(v6.17-rc1) set the new r600 drm version requirement. This change
updates the drm version accordingly to 2.51.0.
Fixes: 9e1180b335 ("r600: implement ARB_indirect_parameters")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37118>
The function resource_copy_region is expected to have a memcpy()
like behavior. Some formats, like r11g11b10_float, do not preserve
the original raw values. This was the problem. This change
updates r600_resource_copy_region() to use the generic copy path
for those formats.
This change takes into account how 8235d3aa19 "radeonsi: preserve
NaNs in draw-based resource_copy_region" proceeds.
This change fixes the remaining khr-gl and deqp-gles31 copy_image tests. This
change was tested on palm, barts and cayman. Here are the tests fixed:
khr-gl4[2-6]/texture_view/view_classes: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_2d_array_src_format_rgb9_e5_dst_target_texture_2d_array_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_2d_array_src_format_rgb9_e5_dst_target_texture_3d_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_2d_array_src_format_rgb9_e5_dst_target_texture_rectangle_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_3d_src_format_rgb9_e5_dst_target_texture_2d_array_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_3d_src_format_rgb9_e5_dst_target_texture_3d_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_3d_src_format_rgb9_e5_dst_target_texture_rectangle_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_rectangle_src_format_rgb9_e5_dst_target_texture_2d_array_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_rectangle_src_format_rgb9_e5_dst_target_texture_3d_dst_format_r11f_g11f_b10f: fail pass
khr-gl4[3-6]/copy_image/functional_src_target_texture_rectangle_src_format_rgb9_e5_dst_target_texture_rectangle_dst_format_r11f_g11f_b10f: fail pass
deqp-gles31/functional/copy_image/non_compressed/viewclass_16_bits/.*: fail pass
deqp-gles31/functional/copy_image/non_compressed/viewclass_32_bits/.*: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37117>
We need to store the driver location when we add it to the state
param list. Currently this code only works because
st_nir_assign_uniform_locations() later adds duplicate params but
this will be fixed in a following patch.
Unfortunatly we could not simply move nir_lower_clip to the state
tracker like we did in the reset of this MR as it is also called
directly from some drivers. Also to avoid making nir depend on the
gl_parameter defintions we simply loop over the results of the lowering
and fix up the locations.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37037>
Rob Clark