Disable the modem simulator in cuttlefish, it is not needed for testing
the graphics subsystem and avoids opening a few vsock ports which
reduces the chance of collisions in case of multiple instances of
cuttlefish running concurrently.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33499>
Cleaning up and stopping cuttlefish before launching it is not strictly
necessary when using gitlab shared runners.
This can be added back later when we have a better justification.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33499>
A significant CPU performance bottleneck in mesa GL is refcounting atomics:
even with the current pinning attempts, eliminating them can yield huge
performance gains (easily verified by running drawoverhead with return false at the top of pipe_reference_described()).
This is a proof of concept for removing refcounts from gallium objects,
namely sampler views and resources. Sampler views were smaller in scope,
so I started there. This MR alone is not expected to noticeably affect
performance, though if applied to all drivers/frontends,
it would enable a bunch of code deletion for crazy samplerview
refcounting hacks currently used to try circumventing the existing overhead.
Co-authored-by: Karol Herbst <kherbst@redhat.com
Co-authored-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33813>
When translating atomic instructions, the base type of the imageView can be
float only for image_atomic_exchange. If a float type image is used with other
atomic instructions the results are undefined.
Enforce this check in the shader translator and don't emit any instruction if
it fails.
Fixes crash in piglit test arb_shader_image_load_store@invalid.
Signed-off-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33749>
The nir to tgsi translator flattens all constants in the nir shader into uint32
immediates. In the svga driver, the vgpu10 shader translator then packs all
these immediates into a constant buffer, and also optimizes it to prevent
repetitions by only emitting a 32-bit constant once.
This can cause problems with double sized constants, since either the lower or
higher 32-bits of different 64-bit constant can be identical, and in the constant
buffer that repeating 32-bit value will be emitted only once, so a 64-bit
constant gets split into two non-contiguous 32-bit values.
When this 64-bit constant is then invoked by a double instruction live ddiv or
dmul, the source register can now have invalid swizzles like .xz or .xw since
its 32-bit components are not contiguous.
We have seen this happen in the piglit test -
spec@arb_gpu_shader_fp64@execution@glsl-fs-loop-unroll-mul-fp64
which emits invalid swizzle values for double instructions.
To fix this, introduce a new option in nir to tgsi shader translator that
preserves uint64 constants. When a 64-bit immediate is translated into svga
shader code, its 32-bit components are contiguous and aligned in the constant
buffer, so accessing them only emits valid swizzles .xy and .zw.
Other drivers using the nir to tgsi shader translater should not see any change
in the tgsi shader emitted unless they too explicitly invoke the
keep_double_immediates option like svga.
Signed-off-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33749>
During translation of tgsi shaders to vgpu10 shader code that is sent to
svga device, we may get as input a double instruction with incorrect
swizzles such as xzxz. In this case we have a workaround to move the value
in that register to a temporary register with an xyzw swizzle.
However the functions that check if the instruction has double source or
destination did not check for all instructions, such as DDIV, so if
incorrect swizzles are sent in the shader tgsi code then the same
incorrect swizzle is also emitted in the vgpu10 shader code.
Fix this by adding all the double instructions in double checking
functions.
Signed-off-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33749>
The extra `all_free` that now remains in the list will be ignored in the
loop below anyway so there is no need to have complex code to try to
remove it.
This also means it becomes possible to set things like
`-D video-codecs=all_free,vc1dec`.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33949>
- Fix the checks for emulation (based on presence of the extension
on the host)
- Add flag in gfxstream_vk_physical_device, otherwise the real device
extensions are not properly filtered when communicating with the host.
- The "function" version of the check in ResourceTracker can eventually
just check the flag once mesa and gfxstream objects are combined
- Remove the duplicate getPhysicalDeviceFormatProperties2 impl, this is
covered by the ResourceTracker impl
- Add ResourceTracker impl for getImageDrmFormatModifierPropertiesEXT
- Remove isDmaBufImage flag from VkImage_info, and clean up all the code
associated with this flag. In on_vkCreateImage, all required info is
avaialble from the extMemImageCi::handleType. In on_vkAllocateMemory,
this is all associated with the tiling of the dedicatedImage for the
allocation
Reviewed-By: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33944>
With secondary command buffers, inherited rendering can be used but
it's basically impossible to know if the depth/stencil attachment
enabled HiZ/HiS. But it's required to disable WALK_ALIGN8 to avoid
GPU hangs.
This assumes that HiZ/HiS is enabled for inherited rendering as long
as a depth/stencil attachment is used. It's not the most optimal
approach but it's not supposed to hurt either.
This fixes a GPU hang with
dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.contents_secondary_cmdbuffers
and friends.
GFX1200 isn't affected because it doesn't support HiZ/HiS.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33986>
We currently report a deviceName as e.g. "Mali-G610 (Panfrost)", but
panfrost has nothing to di with the physical device, and the suffix
doesn't belong there at all.
So let's remove that suffix from PanVK. This results in output like this
from vulkaninfo:
---8<---
VkPhysicalDeviceProperties:
---------------------------
apiVersion = 1.1.305 (4198705)
driverVersion = 25.0.99 (104857699)
vendorID = 0x13b5
deviceID = 0xa8670000
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = Mali-G610
pipelineCacheUUID = <snip>
---8<---
We already sort of namedrop Panfrost in the driver properties:
---8<---
VkPhysicalDeviceDriverPropertiesKHR:
------------------------------------
driverID = DRIVER_ID_MESA_PANVK
driverName = panvk
driverInfo = Mesa 25.1.0-devel (git-136dd9f985)
conformanceVersion:
major = 1
minor = 4
subminor = 1
patch = 2
---8<---
While this might techically speaking be a regression, PanVK has been
marked as experimental until Mesa 25.0. But to reduce the risk of people
starting to depend on this behavior, let's also backport this change to
the 25.0 release.
The patch looks a bit funny, because we add the " (Panfrost)"-suffix in
common code, and this moves it to the Gallium driver. But effectively,
this means PanVK is the only driver that sees a change of behavior.
Backport-to: 25.0
Reviewed-by: John Anthony <john.anthony@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33972>
We have a common implementation for this, let's just use that.
Similar to the previous commit, this is a bit silly. But if we ever get
in a situation where VK_EXT_display actually makes sense, this stuff
should "just work", so let's enable it for good measure.
Tested-by: Alexandre ARNOUD <aarnoud@me.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33916>
Antonio Ospite