Don't multiply by 4 twice. While we're here, fix the in-bounds check on
a6xx, since we need to account for the multiplying by 4. This was done
correctly on a7xx but the commit below didn't correctly port it to a6xx
when adding the multiply on a6xx.
Fixes: 01bac643f6 ("freedreno/ir3: Fix ldg/stg offset")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30046>
si_set_patch_vertices was only called if tcs.current was non-NULL but
this condition is not enough for GFX9+ since vs is used as ls.
Add a check in si_update_tess_io_layout_state instead, and set
sctx->do_update_shaders for case where the ls_current is not yet
available.
This fix crashes on GFX6.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29876>
buffer_size is not the full buffer size, but the part of the
buffer that is accessed by the compute shader.
This fixes the assert hit in si_set_shader_buffer.
Fixes: 1a99f50c7f ("radeonsi: use a compute shader to convert unsupported indices format")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29876>
We use the method used by the blob, which sets the USE_CPU_MAP flag,
originally intended for SVM, to allocate from a separate address range
and to control the address by passing a preferred address to mmap().
With this we can capture and replay gfxreconstruct traces on kgsl for
apps that use BDA, and we can replay them on msm with a small hack to
increase the address space size:
echo 274877906944 > /sys/module/msm/parameters/address_space_size
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29251>
We select the feedback tranche according to the image format but not the
actual format that we will use for presentation. This breaks direct
scanout in cases where the application selected a visual with an alpha
channel but using EGL_EXT_present_opaque which previously worked as
expected.
Fix this by selecting the feedback tranche according to the actual
presentation format.
Fixes: 9ea9a963aa ("egl/wayland: Fix EGL_EXT_present_opaque")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153>
When using the EGL_EXT_present_opaque extension we create wayland
buffers with the opaque variant of the surface format, while the
underlying image is created with the normal surface format. However,
there is no guarantee that the compositor supports that opaque format,
or that we can use that format with all the modifiers of the surface
format.
Since this is completely out of the control of the application, and the
compositor will disconnect the client with an error if the format is not
supported, this commit:
1. Fails EGL surface creation if it determines that the opaque format
cannot be used, either because it's not present at all, or because
it shares no modifier with the non-opaque format.
2. When creating the DRI image ensures that we use a modifier that's
also supported by the opaque format.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153>
This introduces a new helper that will be used to generate a graphics
pipeline hash from a pCreateInfo struct only. Similar to RT.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30049>
The VA alignment now has two pieces: The bind alignment and the base
address alignment. The caller gets to request the later but not the
former. The bind alignment is based entirely on whether or not we know
a priori that the given VA will only ever be used for GART.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
It's a positive flag in the kernel interface because it enables an
optimization and adds restrictions to the BO. But from a userspace PoV,
NO_SHARE shoudd be the default with import/export being something we
expressly have to ask for. This also reduces the number of flags we're
setting everywhere.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
We may want to move this even higher, into NVK at some point. However
the wrappers in the winsys layer really aren't doing us much. If
anything, now that nvkdm_mem::va is an nvkmd_va *, this actually makes
everything simpler because it's allocated through exactly the same paths
as sparse VA.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
