Sync fd fence export implies a payload reset operation, and application
can immediately do another submission with the same fence after export.
Concurrent use of the same feedback slot is incorrect. Keeping a list of
feedback slots for sync_fd external fence is a bit over designed given
those fences are usually not checked or waited by the app, but will hand
off the ownership via sync fd to an external client.
Fixes: d7f2e6c8d0 ("venus: add fence feedback")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
The ignore rules for VkGraphicsPipelineCreateInfo::pViewportState,
pMultisampleState, pDepthStencilState, and pColorBlendState, they were
all lumped together under a single ignore rule. Split them out because
the rules for pDepthStencilState and pColorBlendState should be
different.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16681>
For each pipeline state category, we define a bool.
The Vulkan spec (1.3.223) says:
The state required for a graphics pipeline is divided into vertex
input state, pre-rasterization shader state, fragment shader state,
and fragment output state.
This patch merely defines the bools and does a minor refactor. It does
not add new ignore rules.
Without VK_EXT_graphics_pipeline_library, most states are
unconditionally included in the pipeline. Despite that, we still
reference the state bools in the ignore rules because (a) it makes the
ignore condition easier to validate against the text of the relevant
VUs; and (b) it makes it easier to enable
VK_EXT_graphics_pipeline_library because we won't need to carefully
revisit the text of each VU to add the missing pipeline state bools.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16681>
- Instead of deferring all fixes until we inspect all pCreateInfos, fix
each pCreateInfo immediately after we inspect it.
- Do not allocate vn_graphics_pipeline_create_info_fix.
- Add a struct to hold the temporary allocation of fixed pCreateInfos.
Later commits will place more vk structs here.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16681>
Each time some code wanted to access in vn_render_pass the present
acquire attachments or the present release attachments, it needed to
know the memory layout of vn_render_pass and do pointer arithmetic.
It's fragile to handroll this layout knowledge and pointer arithmetic
throughout the code, so add a pointer in vn_render_pass for each
attachment type.
The new pointers are:
- present_attachments: all present attachments
- present_acquire_attachments: a subslice of present_attachments
- present_release_attachments: a subslice of present_attachments
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16681>
This is mainly to workaround a platform issue that has huge sleep
penalty, which could lead to a timeout if the small synchronous queries
are going to sleep.
This change adjusts the warn and abort order correspondingly so that to
match prior timing.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17898>
We should not scrub raster dedicated states when dynamic state includes
VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE.
Test:
- dEQP-VK.pipeline.extended_dynamic_state.*_raster
- dEQP-VK.api.pipeline.pipeline_invalid_pointers_unused_structs.graphics
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17582>
Previously we suballocate only for host visible memory type to reduce
the kvm mem slot usage. That is no longer an issue given the limit has
been raised. However, we should still suballocate to make layering
clients performant. So we just suballocate regardless of mem type.
This change also increases the allowed suballocation size request from
64K to 128K, which makes layering clients happier.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17497>
We can't unconditionally support separable shader objects on the host,
so submit the property only if the shader is actually separable, the
host knows about the property, and supports SSO.
Without support for SSOs, the host can still compile and link the shaders,
it needs to do more work on interface matching though.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17344>
Yiwei Zhang