Code movement: Move the object list + destroy_object
function to separate files.
This allows vk_command_buffer.{h, c} to not depend on all
of vk_meta, which depends on vk_pipeline, which depends on
NIR.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30355>
These implementations are built on top of vk_shader. For the most part,
the driver shouldn't notice a difference between draws consuming
pipelines vs. draws consuming shaders. The only real difference is
that, when vk_driver_shader_ops::compile() is called for pipelines, a
struct vk_graphics_pipeline_state is provided. For shader objects, the
state object will be NULL indicating that all state is unknown. Besides
that, all the rest of the differences between Vulkan 1.0 pipelines,
VK_EXT_graphics_pipeline_library, and VK_EXT_shader_object are handled
by the Vulkan runtime code.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
The runtime is turning GENERAL layouts into FEEDBACK_LOOP ones when it
detects feedback loops in a render pass. This is breaking drivers that
would like to use a different HW layout for those 2 layouts because if
the application inserts barrier in the render pass, the barriers the
driver sees are inconsistent.
This could lead to barrier of this type :
- GENERAL -> FEEDBACK_LOOP (runtime)
- GENERAL -> GENERAL (app)
- FEEDBACK_LOOP -> GENERAL (runtime)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23523>
Use the hawkmoth c:auto* directives to incorporate vulkan documentation.
Convert @param style parameter descriptions to rst info field lists.
Add static stubs for generated headers. Fix a lot of references, in
particular the symbols are now in the Sphinx C domain, not C++
domain. Tweak syntax here and there.
Based on the earlier work by Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24507>
For drivers already using vk_common_ResetCommandBuffer(), it now only
calls the driver's reset hook if the command buffer is not in the
INITIAL state. Pulled this trick from the PowerVR driver.
v2 (Jason Ekstrand):
- Rename from "status" to "state" since that's what's in the spec
- Add vk_command_buffer_begin/end instead of drivers setting it all
manually
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16922>
This is similar to what RADV and several other drivers have been doing
for quite some time. It's good to have it common.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18324>
This is little more than a wrapper around a function pointer at present
so it doesn't really gain the driver much to use it. The new callback
will, however, be put to good use in the next commit.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18324>
This is the standard pattern in the kernel for providing vfunc tables
for C objects. We're using it in the pipeline cache code but we're
about to start adding more stuff and so it really helps if we have it
for command buffers as well.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18324>
Most other init functions follow the Vulkan API convention of putting
the parent object first.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18324>
This pulls the record state out of the cmd queue into the command
buffer. It can be used here by other drivers.
v2: add some get/set api: not set only sets the first error.
v3 (Jason Ekstrand):
- Rename set_record_result to set_error
- Automatically log the set error
- Add a new vk_command_bufer_has_error() helper
- Split out vk_cmd_queue changes into their own commit
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16918>
This implements vkCmdBeginRenderPass, vkCmdEndRenderPass, and
vkCmdNextSubpass in terms of the new vkCmdBegin/EndRendering included in
VK_KHR_dynamic_rendering and Vulkan 1.3. All subpass dependencies and
implicit layout transitions are turned into actual barriers. It does
require VK_KHR_synchronization2 because it always uses the 64-bit
version of the pipeline stage and access bitfields.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14961>
This is paving the road for generic secondary command buffer support,
where commands are simply recorded in a software queue and replayed
on the primary command buffer when vkCmdExecuteCommands() is called.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>
Looks like 3 implementations already have that field in their private
command_buffer struct, and having it at the vk_command_buffer opens the
door for generic (but suboptimal) secondary command buffer support.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14917>
