Prepare Crocus code for addition of virtio native context support by
open-coding drm prime ioctls instead of using libdrm helpers and using the
intel_ioctl() helper. This is needed by virtio to be able to override the
ioctls implementation.
Suggested-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870>
Add virtio-gpu native context support to ANV driver.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870>
Prepare Iris code for addition of virtio native context support by
open-coding drm prime ioctls instead of using libdrm helpers. This
is needed by virtio to be able to override the ioctls implementation.
Suggested-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870>
Add virtio-intel native DRM context base preparatory code. Virtio-intel
works by passing ioctl's from guest to host for execution, utilizing
available VirtIO-GPU infrastructure.
This patch adds initial experimental native context support using i915
KMD UAPI.
Compile Mesa with -Dintel-virtio-experimental=true to enable virtio-intel
native context support.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870>
Check whether userptr UAPI presents and disable userptr features if not.
Kernel i915 driver has config option that disables userptr ioctl. The
ioctl also may not present in a case of virtio native context driver.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870>
Here we speedup nir_find_inlinable_uniforms() by making sure we only
check a src is inlinable once.
If we have a bunch of nested if-statements where the conditions keep
building on the alu chains of previous conditions we can end up
with exponential processing times due to repeatedly processing the
same srcs over and over.
A big cause of the exponential grow seems to be instructions like
`ffma %594, %594, %599` or `fmul %600, %600` where each essentially
causes us to process the entire previous part of the chain
twice.
Shaders such as that in issue #14663 took multiple minutes to
compile previously, calling collect_src_uniforms billions of times
and now compile within a second with this change.
Closes: mesa/mesa#14663
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39664>
Since glibc-2.43:
For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type.
https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html
Resolves the following warnings:
src/mesa/glapi/glapi/gen/enums.c: In function '_mesa_enum_to_string':
src/mesa/glapi/glapi/gen/enums.c:7799:8: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
7799 | elt = bsearch(& nr, enum_string_table_offsets,
| ^
../src/egl/main/egldispatchstubs.c: In function 'FindProcIndex':
../src/egl/main/egldispatchstubs.c:52:7: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
52 | bsearch(name, __EGL_DISPATCH_FUNC_NAMES, __EGL_DISPATCH_COUNT,
| ^~~~~~~
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39707>
Commit cf4bd2e412 added a fast path for handling no-command submits to
accommodate a kernel behavior quirk. Sparse support was complete before
that change but landed afterwards, leaving sparse submits that don't have
command buffers but do have sparse bind commands to take that fast path,
leaving the bind commands unhandled. The condition for the fast path is
fixed to address that.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 71ef46717c ("tu/kgsl: Add support for sparse binding")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39695>
After successful initialization of images, `result` is `VK_SUCCESS`. But
there are still a few failure paths, in which cases
x11_surface_create_swapchain will return `VK_SUCCESS` but not actually
allocate a swapchain.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37800>
Fixes a race condition where a BVH will be dumped before its command buffer is
actually submitted if a different command buffer completes between the time the
BVH dump is recorded and the time the command buffer is actually submitted.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Fixes: 1b55f101 ("anv/bvh: Dump BVH synchronously upon command buffer completion")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39599>
We are having problem establishing connections to
gitlab.freedesktop.org, even though performance once the link is
established is perfectly fine (10+ MB/s)... so let's disable the
farm until we can figure it out.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39719>
This change only addresses the clear of one channel via the TQ for DS
formats. This is exercised by VK_KHR_depth_stencil_resolve in two ways:
resolve depth and clear stencil, or resolve stencil and clear depth.
When resolving, we need to propagate source and destination format if the
DS format is combined because we need either combination of both for cases
where the DSMERGE and PICKD flags are set.
- Resolve op
+ For combined DS formats
1. resolve the stencil from the source merging it with the depth of the
destination. Leave source depth unchanged.
2. resolve the depth from the source merging it with the stencil of the
destination. Leave the source stencil untouched.
+ For non-combined formats
1. we can use the source for all aspects / channels, this ensures the
size to blit the source to is compatible with the destination. Note
that the TQ doesn't require src/dst to be single channel formats.
- Non resolve op
+ Not part of this change.
Fix for deqp:
dEQP-VK.renderpass2.depth_stencil_resolve.*.*.d24_unorm_s8_uint.compatibility*
dEQP-VK.renderpass2.depth_stencil_resolve.*.*.d32_sfloat_s8_uint.compatibility*
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Co-authored-by: Leon Perianu <leon.perianu@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39654>
In order to set DSMERGE, and eventually PICKD-epth, both the source and
the destination have to be combined D/S formats.
Removed tests that now currently pass
Fix for deqp:
dEQP-VK.renderpass2.depth_stencil_resolve.*.*.d32_sfloat_s8_uint.*
dEQP-VK.renderpass2.depth_stencil_resolve.*.*.d24_unorm_s8_uint.*
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39654>
Fix loop condition in pvr_isp_ctrl_stream to reset fill_blit
when processing fill blits with sources.
Fix for deqp:
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_17_1.*.d24_unorm_s8_uint.*
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_49_13.*.d24_unorm_s8_uint.*
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_5_1.*.d24_unorm_s8_uint.*
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_8_32.*.d24_unorm_s8_uint.*
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_8_32.*.d24_unorm_s8_uint.*
Signed-off-by: Leon Perianu <leon.perianu@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39654>
Since d95423686f ("pan/format: Add PAN_BIND_STORAGE_IMAGE flag"), we
have a separate flag for PAN_BIND_STORAGE_IMAGE, and can now also
properly check for this.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39686>
There's no good reason we need to keep these separated, they're the same
feature from a HW point-of-view.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39686>
This is to make sure early culling related Wa_16020518922 is enabled
properly.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39712>
Interleaved 64k should be better than U-interleaved for most
workloads so use it if we can and memory waste isn't too bad.
This also improves perf in cases when we can't use U-interleaved,
but can use interleaved 64k, such as BLOCK_TEXEL_VIEW_COMPATIBLE
images. Currently we'll end up picking linear, which is strictly
worse than interleaved 64k when it comes to perf.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39657>
Currently it's not easy to know which modifier will be picked for
an image and thus end up causing a layout difference. The next
commit causes us, for certain images, to choose interleaved 64k if
HOST_TRANSFER is not specified, but choose U-interleaved when it
is, causing a layout difference.
See https://gitlab.freedesktop.org/panfrost/mesa/-/issues/281 for
details.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39657>
Advertise the extension and enable the zeroInitializeDeviceMemory
feature. The panfrost and panthor kernel drivers uses drm_gem_shmem which
gets zeroed pages from the shmem subsystem, so memory is already
zero-initialized by default.
VK_IMAGE_LAYOUT_ZERO_INITIALIZED_EXT is treated the same as
VK_IMAGE_LAYOUT_UNDEFINED. Since panvk doesn't use image layouts
(layout transitions are no-ops), no special barrier handling is
needed for either layout.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39658>
Compressed formats cannot support storage operations on any Mali
generation:
- On Bifrost (v6-v7), the texture descriptor contains the compressed
format directly, and the hardware doesn't support storage operations
on compressed formats.
- On Valhall (v9+), storage operations would require
InternalConversionDescriptors, which cannot describe compressed
formats.
Storage operations on compressed formats don't make practical sense
anyway - each pixel write would require full block recompression.
Remove PAN_BIND_STORAGE_IMAGE from the FMTC macro used by all
compressed format definitions.
Fixes crashes in dEQP-VK.memory.zero_initialize_device_memory tests
that attempt to use compressed formats as storage images.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39658>
Some ALU instructions will likely end up being copy propagated in the
backend, which means they would not have any cost. This helps the
scheduler make better decisions for the new open-coded patterns
produced in NIR for extracts (i.e. unpack_2x16) with MR#39511.
With this (together with previous patches) we manage to produce similar
shader-db results as with the unpack_2x16 NIR extract opcodes that
MR#39511 will drop.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39687>
We need this to produce optimal code in the backend for sequences
like this:
32 %10 = ushr %5.x, %9 (0x10)
16 %14 = u2u16 %10
32 %17 = f2f32 %14
With such code, our copy propagation pass will drop the u216 and
with this patch we will be able to drop the ushr too.
This pattern can show up for VK_KHR_16bit_storage when we successfully
vectorize 16-bit loads into 32-bit loads, but will become a lot more
common after MR#39511 lands, since that would also affect things like
16-bit TMU loads, which are more common.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39687>
We only really use sub-32bit integers in conversions, so we can skip
clearing the MSB bits when we produce them by converting from larger types
(leaving these bits undefined) and only clear them when we convert from them
to larger types, since we don't have native opcodes to do these conversions
that would only access relevant bits, at least on Pi4. Also, document the
cases where we could do better for Pi5.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39687>
There's a lot that has been fixed, but nobody has been paying attentions
to t720. Let's update the results.
In addition, we used to do skips here instead of flakes. Not sure why,
flakes works just fine.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39711>
This was an oversight of VK_KHR_dynamic_rendering_local_read which has
been addressed by VK_KHR_maintenance10 which introduced new flags to
give more information to implementations.
The Vulkan spec says:
"VK_RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHR is
intended to give implementations similar information as a subpass
where an attachment could be used as both a color attachment and
input attachment. Some implementations require extra work to make
this scenario work beyond just considering the image layouts.
Implementations which have no such considerations may treat this
flag as a noop. The primary use case for this flag is to enable
feedback loops inside a single shader."
"Applications are encouraged to use
VK_RENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHR if
maintenance10 is available and they use feedback loops with
VK_KHR_dynamic_rendering_local_read. Feedback loops are still
allowed when not using the rendering flag, but the performance
implication was an oversight in the original definition of
VK_KHR_dynamic_rendering_local_read."
Because it's clearly defined by the Vulkan spec, let's just pessimize
always to avoid relying on some shaders state which require to do very
late decompression passes. This will allow us to do more cleanups and
optimizations related to the framebuffer. Also note that DRLR is still
a niche feature.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39538>
Its no longer an error for depth and stencil formats to have invalid
accumulator format.
Fixes the following tests:
* dEQP-VK.api.info.image_format_properties.2d.optimal.d16_unorm
* dEQP-VK.api.info.image_format_properties.2d.optimal.d24_unorm_s8_uint
* dEQP-VK.api.info.image_format_properties.2d.optimal.d32_sfloat
* dEQP-VK.api.info.image_format_properties.2d.optimal.d32_sfloat_s8_uint
* dEQP-VK.api.info.image_format_properties.2d.optimal.s8_uint
* dEQP-VK.api.info.image_format_properties.2d.optimal.x8_d24_unorm_pack32
Backport-to: 26.0
Signed-off-by: Arjob Mukherjee <arjob.mukherjee@imgtec.com>
Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39626>
