panfrost_bo_import() calls drmPrimeFDToHandle() then pan_kmod_bo_import(),
which also calls drmPrimeFDToHandle() internally. This double import causes
GEM handle refcount leaks because each drmPrimeFDToHandle() increments the
kernel's GEM handle refcount, but only one drmCloseBufferHandle() is called
during cleanup by panfrost_kmod_bo_free(or panthor_kmod_bo_free).
Fix by removing the redundant drmPrimeFDToHandle() and using
pan_kmod_bo_import() directly. On re-import of existing buffers, properly
release the extra pan_kmod_bo reference with pan_kmod_bo_put().
This ensures GEM handle refcount, pan_kmod_bo refcount, and panfrost_bo
refcount are all properly balanced.
Fixes: 5089a758df ("panfrost: Back panfrost_bo with pan_kmod_bo object")
Signed-off-by: Xianzhong Li <xianzhong.li@nxp.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
(cherry picked from commit 248b0b47b7)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The only real requirement here is that the destination offset is zero
and that the destination is big enough to hold the source. The source
offset doesn't matter.
Fixes: bc17288697 ("pan/bi: Lower split/collect before RA")
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit 05c5e52054)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The non-trivial non-replicate swizzles on IADD.v4x8 and ISUB.v4x8 are
either documented wrong or broken in hardware. Instead of swizzling
b0101 and b2323, they swizzle b0011 and b2233 on G52. This is either a
hardware bug or an issue with documentation. In either case, it's
probably best not to trust it. Those swizzles aren't all that useful
anyway. We also weren't using any of them before (or they'd have
broken) so this isn't a performance regression.
Cc: mesa-stable
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit 538b5c411e)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Midpoint sorting is incompatible with how our traversal works.
Specifically, we change tMax when a hit is committed so we can skip over
BVH nodes that are guaranteed not to produce a closer hit. However,
changing tMax also changes the intersection interval of box nodes with
the ray, and thus, the midpoints of that interval. Stackless traversal
relies on getting nodes back in the exact same order as before, and if
that requirement is not met, traversal may incorrectly skip over nodes.
The likely benefit of midpoint sorting does not make up for the loss of
ability to skip over BVH nodes exceeding tMax, so simply disable
midpoint sorting.
This fixes geometry being visible behind other geometry when it
shouldn't be in various applications, including Half-Life 2 RTX.
Cc: mesa-stable
(cherry picked from commit c1a7680d93)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
ballot_bit_count_reduce expects the ballot to have 4 components causing
validation failures on targets where 1 < ballot_components < 4. Fix this
by padding the ballot to 4 components.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: ae66bd1c00 ("nir/opt_uniform_subgroup: use ballot_bit_count")
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
(cherry picked from commit cc6eec79c2)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
nir_builder_alu_instr_finish_and_insert initialized the def's bit_size
and num_components so we should set them afterwards.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Fixes: c66967b5cb ("nir: add nir_opt_varyings, new pass optimizing and compacting varyings")
(cherry picked from commit 273fd18b89)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
st_cb_bitmap appends a temporary bitmap sampler view to the sampler
view array passed to set_sampler_views().
1a5c660ef5 changed this path to only release the extra YUV views
returned by st_get_sampler_views(), but the temporary bitmap view is
created locally and is not part of extra_sampler_views. It therefore
stopped being released so release the temporary bitmap sampler view
explicitly after drawing the bitmap quad.
Fixes: 1a5c660ef5 ("st/bitmap: only release YUV samplerviews")
(cherry picked from commit 33864e569e)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
From the OpenCL specification:
`CL_MEM_KERNEL_READ_AND_WRITE`: This flag is only used by
clGetSupportedImageFormats to query image formats that may be both
read from and written to by the same kernel instance. To create a
memory object that may be read from and written to use
CL_MEM_READ_WRITE.
If an application follows the instructions above, i.e. query a list of
supported image formats, using `CL_MEM_KERNEL_READ_AND_WRITE` as
input, and then attempts to create an image using one of the supported
image formats, by calling `clCreateImage` and passing
`CL_MEM_READ_WRITE`, the call to the image creation entry point should
succeed. This instead fails on Mali devices with the error
`CL_IMAGE_FORMAT_NOT_SUPPORTED`.
Rusticl fails when validating the image format against its supported
flags. Formats that support `PIPE_BIND_SHADER_IMAGE` have their
supported flags set as `CL_MEM_WRITE_ONLY` and
`CL_MEM_KERNEL_READ_AND_WRITE`.
This changes the supported CL flags to be `CL_MEM_WRITE_ONLY` for
`PIPE_BIND_SHADER_IMAGE` and `CL_MEM_READ_WRTE |
CL_MEM_KERNEL_READ_AND_WRITE` for `PIPE_BIND_SAMPLER_VIEW |
PIPE_BIND_SHADER_IMAGE`.
Fixes: 3386e142 (rusticl: support read_write images)
Fixes OpenCL-CTS test: `test_image_streams` on Mali. Invocation:
```
test_image_streams write 1D CL_RGB CL_SIGNED_INT8
```
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
(cherry picked from commit e77c984cef)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
This would read OOB and crash because data type is optional per the
SPIRV spec.
Original patch by Faith Ekstrand <faith.ekstrand@collabora.com>.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 1f8be7bfad)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
When converting the index buffer from 4-bytes to 2-bytes, we use the
uploader for the job. Since commit b3133e250e we do an uploader alloc
ref, which releases the uploader buffer if there is no enough space,
creating a new one.
The problem happens when we also need this buffer because it is the one
containing the index buffer to convert. This happens, for instance, if
we need to convert the primitives because they are not supported (e.g.,
converting quads to triangles), as this is done
also using the uploader.
The solution is to ensure the uploader's buffer has an extra reference
so when released, it is not destroyed. This can easily achieved by
calling first pipe_buffer_map_range(), which is required to access the
buffer, and it increases the references.
This fixes `spec@!opengl 1.1@longprim`.
Fixes: b3133e250e ("gallium: add pipe_context::resource_release to eliminate buffer refcounting")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
(cherry picked from commit 48c086cb42)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
R300_PACKET3_3D_CLEAR_HIZ encodes COUNT in 14 bits (COUNT[13:0]), so a
single packet can clear at most 0x3fff dwords.
Large depth surfaces on R5xx can require more HiZ dwords than that.
When we emitted a single packet, COUNT truncated and part of HiZ RAM
remained uncleared, which could show up as HyperZ corruption.
Emit CLEAR_HIZ in chunks of R300_CLEAR_HIZ_COUNT_MAX and reserve enough
atom space for the worst-case packet count derived.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/360
Fixes: 12dcbd5954 ("r300g: enable Hyper-Z by default on r500")
(cherry picked from commit fddc101070)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Introduce r300_hyperz_pipe_count and use it in\nr300_setup_hyperz_properties.\n\nRV530 selects pipe topology from NUM_Z_PIPES, while other families use\nNUM_GB_PIPES. Keeping this in one helper avoids duplicated family checks\nand prepares follow-up HiZ clear sizing changes to reuse the same rule.
(cherry picked from commit e97ac38ff3)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Ian Romanick reported some "undefined behaviour" warnings during some
not specified tests, relating to introduction of RGB[A}16_UNORM formats
in merge request
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38588
This due to overflowing the 32-bits masks[], and then during assignment
the red/green/blue/alphaMask fields in struct gl_config when using a 16
bpc format. Iow. the red/green/blue/alphaMask would not be usable.
Suppress this warning by setting masks[] to zero for unorm16 formats,
just as was previously done for is_float16, ie. fp16 formats.
16 bpc formats are only exposed for display on non-X11 WSI target
platforms like GBM+DRM, Wayland, surfaceless, and these platforms do
not use the info in red/green/blue/alphaMask at all, so the "undefined
behaviour" is meaningless.
Fixes: f2aaa9ce00 ("dri,gallium: Add support for RGB[A]16_UNORM display formats.")
Reported-by: Ian Romanick @idr
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit ab94515b0a)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Fix a crash in image descriptor emission caused by stale image_mask bits.
Root cause:
- set_shader_images used a shift expression with count==64 when clearing
image_mask, which is undefined behavior in C.
- This could leave image_mask inconsistent with actual image bindings,
so panfrost_emit_images() might dereferences NULL image resources.
Fixes:
- Use 64-bit-safe bit helpers for mask updates to avoid invalid shifts.
Crash observed when running: OpenCL-CTS api/test_api
Backtrace:
#0 util_image_to_sampler_view (v->resource is NULL)
#1 panfrost_emit_images
#2 panfrost_update_shader_state
#3 panfrost_launch_grid_on_batch
#4 panfrost_launch_grid
Backport-to: *
Signed-off-by: Eric Guo <eric.guo@nxp.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
(cherry picked from commit c1770565f3)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Mesa's vk_common_SetDebugUtilsObjectNameEXT assumes every Vulkan object
handle is a pointer to a vk_object_base struct. In gfxstream, only a
subset of objects (instance, device, queue, command buffer, command pool,
buffer, fence, semaphore) carry a Mesa wrapper. All other non-dispatchable
handles (shader modules, pipelines, render passes, etc.) are opaque host
handles that are not valid pointers.
Passing such an unwrapped handle to the common path causes it to be cast
to a vk_object_base pointer and dereferenced, resulting in a SIGSEGV
(null-pointer dereference at offset 0x40).
Override the function in the gfxstream driver to store debug names on
vk_object_base for wrapped objects and return VK_SUCCESS for unwrapped
objects.
Fixes: 7b50e62179 ("gfxstream: mega-change to support guest Linux WSI with gfxstream")
Test: Verified with hellovk (with validation layers) on Android Emulator - no crashes.
(cherry picked from commit bf8862b49f)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
When DXGI is not supported, win32 falls back to sw wsi without acquire
timeout ignored.
This change:
1. adds the needed acquire mutex and cond
- the fail path is intentionally left untouched so that mutex and
cond are both valid when wsi_win32_swapchain_destroy is called
2. adds wsi_win32_acquire_idle_cpu_image helper to respect timeout
3. adds wsi_win32_set_image_idle helper to properly signal acquire_cond
for sw wsi case
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/15122
Cc: mesa-stable
(cherry picked from commit af42f0c80f)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Implement software workaround for AVP decoder corruption on Gen12
platforms. These platforms require a warmup workload before
the actual AV1 decode to prevent output corruption.
- Gen12: Tiger Lake, DG1, Rocket Lake, Alder Lake
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit 260908cecb)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
I have been running into crashes in this function when using blender.
Some of the entries in ice->state.framebuffer.base.cbufs[0] can
apparently have the texture field be null, which was causing a segfault
in this loop.
In my case, nr_cbufs was 3, and the first two cbufs entries had a null
texture and format set to PIPE_FORMAT_NONE. The last entry had format of
PIPE_FORMAT_R16G16_FLOAT and a non-null texture.
Adding this null check before attempting to dereference the texture
fixes the crash for me and allows blender to work normally.
Fixes: ca96f8517c ("iris: remove uses of pipe_surface as a pointer")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
(cherry picked from commit e16c8cc579)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
In the attribute model, the size is for the attribute binding and the
offset is an offset into that range. If we're going to use that to
offset the buffer itself, we need to increase the size accordingly.
Fixes: a21ee564e2 ("pan/bi: Make texel buffers use Attribute Buffers")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit ce56f49561)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
They swizzle just like anything else. Technically, we could maybe do a
little better than the generic case for these since they only read 8
bits per 16 bits in the destination but the generic case is correct,
even if it isn't optimal.
Fixes: f7d44a46cd ("pan/bi: Optimize replication")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit 8dc458225b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
struct nu_handle is hashed and deduplicated using struct nu_handle_key, which ignored
parent_deref. That means all instructions will use the first parent_deref when rewriting
the sources.
Avoid this by not including the parent deref in the struct, and instead querying it
when needed.
Fixes: 4d09cd7fa5 ("nir/lower_non_uniform_access: Group accesses using the same resource")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15173
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
(cherry picked from commit e7077e8f5c)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
It didn't save states properly. The only correct place to save them is
si_blitter_begin. Unfortunately, we can't skip saving and restoring
those states because we don't know in advance whether the rectangle path
will be used.
Cc: mesa-stable
Reviewed-by: Pierre-Eric
(cherry picked from commit 556ceb1b75)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
The dirty state of stencil ops is not checked when deciding whether to
rebuild the ISP state, although the values are part of the ISP state
(the 27:16 bits of ISPB word).
Add MESA_VK_DYNAMIC_DS_STENCIL_OP to the condition for rebuilding ISP
control registers.
Fixes GLCTS tests when running on top of Zink:
dEQP-GLES2.functional.fragment_ops.stencil.zero_stencil_fail
Fixes: 88f1fad3f7 ("pvr: Use common pipeline & dynamic state frameworks")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
(cherry picked from commit ee031d67b4)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
On LSC platforms the SLM writes are unfenced between workgroups. This
means a workgroup W1 finishing might have uncompleted SLM writes.
Another workgroup W2 dispatched after W1 which gets allocated an
overlapping SLM location might have writes that race with the previous
W1 operations.
The solution to this is fence all write operations (store & atomics)
of a workgroup before ending the threads. We do this by emitting a
single SLM fence either at the end of the shader or if there is only a
single unfenced right, at the end of that block.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13924
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
(cherry picked from commit fa523aedd0)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
The DDMADT instruction of PDS has out-of-bound test capability, which is
used for implementation of robust vertex input fetch.
According to the pseudocode in the comment block before the "LAST DDMAD"
mark in pvr_pipeline_pds.c, the check is between
`calculated_source_address + (burst_size << 2)` and `base_address +
buffer_size`, in which the `burst_size` seems to correspond to the BSIZE
field set in the low 32-bit of DDMAD(T) src3 and the `buffer_size`
corresponds to the MSIZE field set in the DDMADT-specific high 32-bit of
src3. As the calculated source address is just the base address adds the
multiplication result (the offset), the base address could be eliminated
from the check, results in the check between `offset + (BSIZE * 4)` and
`MSIZE` .
Naturally it's expected to just set the MSIZE field to the buffer size.
In addition, as the Vulkan spec says "Reads from a vertex input MAY
instead be bounds checked against a range rounded down to the nearest
multiple of the stride of its binding", the driver rounds down the
accessible buffer size before setting MSIZE to it.
However when running OpenGL ES 2.0 CTS, two problems are exhibited about
the setting of the size to check:
- dEQP-GLES2.functional.buffer.write.basic.array_stream_draw sets up a
VBO with 3 bytes per vertex (RGB colors and 1B per color) and 340
vertices (results in a buffer size of 1020 = 0x3fc). However as the
DMA request size, which is specified by BSIZE, is counted by dwords,
3 bytes are rounded up to 1 dword (which is 4 bytes). When the bound
check of the last vertex happens, the vertex's DMA start offset is
0x3f9, so the DDMADT check happens between 0x3fd (0x3f9 + 1 * 4) and
0x3fc, and indicates a check failure. This prevents the last vertex,
which is perfectly in-bound, from being properly fetched; this is
against the Vulkan specification, and needs to be fixed.
- dEQP-GLES2.functional.vertex_arrays.single_attribute.strides.
buffer_0_32_float2_vec4_dynamic_draw_quads_1 sets up a VBO with a size
of 168 bytes, and tries to draw 6 vertices (each vertex consumes 2
floats (thus 8 bytes) of attribute) with a stride of 32 bytes using
this VBO. Zink then translates the VBO to a Vulkan vertex buffer bound
with size = 168B, stride = 32B. Here the optional rule about rounding
down buffer size happens in the current PowerVR driver, and the
checked bound is rounded down to 160B, which prevented the last
vertex's 8B attributes to be fetched. It looks like this kind of
situation is considered in the codepath without DDMADT, but omitted
for the codepath utilizing DDMADT for bound check.
So this patch tries to mimic the behavior of DDMADT when setting the
MSIZE field of it to prevent false out-of-bounds. It first calculates
the offset of the last valid vertex DMA, then adds the DMA request size
to it to form the final MSIZE value. With the code calculating the last
valid DMA offset considering the situation of fetching the attribute
from the space after the last whole multiple of stride, both problems
mentioned above are solved by this rework.
There're 99 GLES CTS testcases fixed by this change, and Vulkan CTS
shows no regression on `dEQP-VK.robustness.robustness1_vertex_access.*`
tests.
Fixes: 4873903b56 ("pvr: Enable PDS_DDMADT")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Ella Stanforth <ella@igalia.com>
(cherry picked from commit 252904f3d1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
This memory padding is enforced by GetBufferMemoryRequirements2 and
might be then checked against to decide whether it's enough.
Move it to pvr_buffer.h for further assertions.
Backport-to: 25.3
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Ella Stanforth <ella@igalia.com>
(cherry picked from commit d992474be9)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Currently the size of single components inside one attribute is saved
and checked against when checking DMA capability. However, the vertex
attribute DMA happens for a whole attribute instead of individually for
its components, so checking against the component size is useless -- the
size of the whole attribute is what needs to be saved and checked.
Rename all component_size_in_bytes fields to attrib_size_in_bytes, and
save the size of the whole attribute inside them.
Fixes: 8991e64641 ("pvr: Add a Vulkan driver for Imagination Technologies PowerVR Rogue GPUs")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Ella Stanforth <ella@igalia.com>
(cherry picked from commit aa8dad141c)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
The ddmadt_oob_buffer_size structure to be filled is named
`obb_buffer_size`, which is obviously a typo.
Change to `oob_buffer_size` to fix the typo.
Fixes: 8991e64641 ("pvr: Add a Vulkan driver for Imagination Technologies PowerVR Rogue GPUs")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Ella Stanforth <ella@igalia.com>
(cherry picked from commit caea72cffc)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
