Mali GPUs don't support DRM_FORMAT_MOD_MTK_16L_32S_TILE natively, so
it doesn't make sense to teach the common layer about this format,
especially since it would require adding more hacks to make sense of
the tiled -> linear view of such resources.
Given the only user of this format is the gallium driver, move the
MTK_TILED definitions there and start differentiating native and
emulated modifiers.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35015>
If we can't find an appropiate builtin in the libclc library, we add our
own wrapper at runtime executing the op in fp32 space.
Libclc has variying support for fp16 opcodes and with a libclc prior
llvm-19 it does not work as good as with the newer one.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34053>
This reverts commit ca087e2027.
It's discovered that the newest Rogue proprietary Vulkan driver does not
prevent us from running Zink (aside from an assert of geometryShader,
which is already changed to an if clause), and which fails previously is
because of some bugs in old driver blobs.
As the faulty blob versions are rejected now, revert this commit to
accept Rogue drivers.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34183>
Imagination closed blobs earlier than 24.1@6554834 has some issues about
NULL pCommandBuffers in VkSubmitInfo, which is present in VkSubmitInfo's
submitted by Zink.
Reject these drivers to prevent crashes, unless zink is enforced and the
user knows what they're doing.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34183>
Some tests no longer OOM after updating the devices to the 6.12 kernel.
Therefore, remove those tests from the skip list.
Also, reduce the timeout of some full-run jobs, as the VK full-run
usually takes no longer than 25 minutes in the RPi 4 and no longer than
30 minutes in the RPi 5.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35300>
- mSize should be used rather than kHostVisibleHeapSize.
Since kHostVisibleHeapSize is bigger, OOB errors occured.
- Freeing memory did not work. Look up via the offset
rather pointer. Complain loudly if offset isn't found.
- Align to 4096 bytes (page size), like the old AEMU suballocator
flow.
TEST=set deferredMapping = 0 and test via Cuttlefish
Reviewed-by: Marcin Radomski <dextero@google.com>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35323>
The logic is implemented on the guest side as we need special handling
for swapchain and device memory handle types.
Memory handles for coherent memory allocations on the guest can map into
a single handle on the host side, which makes it infeasible to pass
through the extension functions with handle remapping. Swapchain handles
are not passed to the host driver, so we need to keep a separate table
for them as well. Instead of separating the logic based on the handle
type, we manage all the private data set/get calls on the guest side
without encoding the commands to the host.
Test: dEQP-VK.api.object_management.private_data.*
Test: dEQP-VK.wsi.android.swapchain.private_data.*
Reviewed-by: Marcin Radomski <dextero@google.com>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35323>
To include VK_KHR_dynamic_rendering for shader_object
tests on dEQP. Also enable timeline_semaphore extension
on Android since some of the known issues are already
fixed and the extension is promoted to 1.2 core.
Reviewed-by: Marcin Radomski <dextero@google.com>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35323>
vkGetDeviceImageMemoryRequirements can be used to get memory
requirements without creating an actual image and we should apply the
same image modifications based on the create info when returning the
memory requirements.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35323>
Boris Brezillon