vi_bindings_valid doesn't necessarily match the # of VBOs emitted,
resulting an invalid size in the CP_SET_DRAW_STATE packet. Somehow
this didn't seem to cause problems prior to Dxx (although may
potentially have been a source of flakes, depending on what random
cmds followed in memory). But caused hangs on Dxx.
See, for example, dEQP-VK.pipeline.fast_linked_library.vertex_input.misc.unused_binding
Fixes: 97da0a7734 ("tu: Rewrite to use common Vulkan dynamic state")
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39254>
The Android 16 Cuttlefish build comes with a new Xe minigbm backend that
we can use on the host in the android-angle-venus-anv-adl nightly job.
Also update two outdated comments.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39297>
As part of coopmat, I want to make reductions faster as I need
them to implement coopmat.
The intrinsics can't be used directly as we have to take into
account the exec_mask, but it can be done by picking the
a value to insert into the disabled lanes, then calling
the LLVM intrinsic.
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39225>
This fixes a llvm validation error seen in dEQP-VK.robustness.robustness2.push.notemplate.rgba32f.dontunroll.nonvolatile.sampled_image.no_fmt_qual.img.samples_1.1d_array.rgen
Cc: mesa-stable
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39225>
As mentioned in earlier commit, for sem fd export on async present
thread, it occurs after internal queue submissions for all swapchains.
So we can allow queue commands while sync wait w/o violating ordering.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
For sem fd export on async present thread, it occurs after internal
queue submissions for all swapchains and before presenting to WSI
backend. We can safely unlock the chain acquire lock though we still
have to lock against chain destroy as well as chain async present on
other queues.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
Brief:
1. present info is deep-copied and passed to async present thread
2. normal queue present always waits for async present to take over
3. queue access is protected by async present queue lock
4. chain access is protected by chain locks
5. no perf gain in practice since we haven't allowed parallel queue
submit or acquire image yet
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
During async presentation, swapchain is accessed by the async present
thread. With proper queue and chain access locks within venus driver,
we still have to rely on mesa common wsi implementation specifics for
optimal async present performance:
Below need to be protected:
- vkAcquireNextImage2KHR
- vkDestroySwapchainKHR
Below are safe:
- vkGetSwapchainImagesKHR
- vkWaitForPresentKHR
- vkWaitForPresent2KHR
- vkReleaseSwapchainImagesKHR
- VkSwapchainPresentFenceInfoKHR::pFences
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
When suboptimal is returned, the fence payload is missed to be installed
unexpectedly. Instead, we can directly return errors from sync import.
With this change, dEQP-VK.wsi.xcb.maintenance1.release_images.* can pass
robustly now.
Fixes: a312bb4285 ("venus: refactor wsi acquire to use semaphore and fence SYNC_FD import")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39283>
The official name for the architecture after Valhall is 'Arm 5th
Gen'. In code we can use 'FIFTHGEN' or 'fifthgen', while in
documentation and printed output we should use 'Arm 5th Gen' or '5th
Gen'.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39267>
Report the -rXpY info in the deviceID.
Reviewed-by: John Anthony <john.anthony@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39267>
Texel buffers are currently described by a TextureDescriptor, which
leads to restrictive limits on size and alignment. These limits can be
avoided by using AttributeDescriptors + AttributeBufferDescriptors
instead.
This requires us to access texel buffers using attributes rather than
textures, which involves setting up AttributeDescriptors and
AttributeBufferDescriptors in their respective allocations, rather than
the previous TextureDescriptors in the texture allocation.
This is already done for images, so we simply place the texel buffer
attributes after the images and ensure the indexing if offset correctly.
Accessing a texel buffer thus becomes:
1. Get the buffer address and ConversionDescriptor with LEA_ATTR[_IMM]
2. Use LD_CVT to get the value
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
Once we move texel buffers to use Attribute Buffers, we'll encode them
as MALI_ATTRIBUTE_TYPE_1D. This means we can store the actual Attribute
Descriptor in what is usually the space for an
ATTRIBUTE_BUFFER_CONTINUATION_3D.
This is good, as we'll need to use the offset functionality of the
Attribute Descriptor to allow lowering
uniformTexelBufferOffsetAlignmentBytes.
This commit therefore creates a path for setting up the Attribute
Descriptor and Attribute Buffer Descriptor for texel buffers in
meta_desc_copy.
Note that this path will not be taken yet, as no images use
MALI_ATTRIBUTE_TYPE_1D.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
As we'll need to pack texel buffer attributes after image attributes in
panfrost and after vertex attributes in panvk, this adds a lowering pass
to achieve that.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
Rather than loading a single 64bit channel with
load_texel_buf_index_address_pan, load three channels of 32bit each. The
last channel is required by the next commit.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
panfrost_emit_image_attribs is only called when the context's image
state is dirtied and uses the context's image_mask to write attributes
and attribute buffers.
However, it uses the shader's attribute_count (which in this context is
the last bit of the shader's images_used) to calculate the size of the
buffers.
In case more images are bound than the currently bound shader uses, this
would lead to out-of-bounds writes.
This change updates the allocation to use the last bit in the context's
image_mask for size calculations.
It also removes an unused parameter from emit_image_bufs and updates a
parameter name in emit_image_attribs to be more descriptive and match
the documentation.
Fixes: dc85f65e05 ("panfrost: emit shader image attribute descriptors")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
nir_u2u32 is presumably a leftover from when the texture size was loaded
from a 16 bit field, but should no longer be necessary now that we're
loading 32 bits
Also renames the "bytes" variable to "size" to align with the descriptor
we're reading.
Fixes: 4573110e4e ("pan/v9+: Make texel buffers use BufferDescriptor")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
VGPRs can be linear too, and RT function calls will add VMEM
instructions acting on linear VGPRs. Using the linear VGPR in a block
with only linear preds will cause the pass to incorrectly skip inserting
s_waitcnt.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39157>
`_mesa_delete_program` and `_mesa_reference_program_` both use fields
in `sh` without determining whether `sh` or `arb` is valid. Herein
lies the problem. I cannot see any reliable way to determine which is
valid without knowing what call path you are in.
There are two possible methods, but neither seems particularly
reliable. We could check whether `shader_program` is `NULL`, or we
could check whether `Parameters` (only used for ARB assembly shaders)
is `NULL`.
Instead of doing that, I chose to add a new field that captures the
`is_arb_asm` parameter already passed to `_mesa_init_gl_program`. This
seemed the most reliable. It is possible that more
`assert(!prog->is_arb_asm)` and `assert(prog->is_arb_asm)` should be
sprinkled throughout the code base.
I don't know how this has not already been a problem. Starting with
492a176cbb ("util: increase SHA1_DIGEST_LENGTH to 32
(BLAKE3_KEY_LEN)"), I observed segfaults in
`_mesa_uniform_detach_all_driver_storage` while freeing ARB assembly
shaders. Those shaders should never hit this path.
Not all assembly shaders hit this path. In fact, **nothing** in the
open shader-db encounters this problem. This is presumably why
pre-merge CI didn't catch this problem. In my closed shader-db,
shaders from the following applications hit this:
- rocketbirds-hardboiled-chicken
- shadowrun-returns
- windward
- ziggurat
I believe it was just blind luck that most of the time the fields of
`sh::data` that were access through this path, `sh::BindlessSamplers`,
and `sh::BindlessImages` happened to line up with fields of `arb` that
contained `NULL`. Changing the size of the hash key changed that luck.
Fixes: ca16c271fa ("mesa: make struct in gl_program a union and remove FIXME")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39243>
