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 is not necessarily a full re-initialization of the object but is
whatever is necessary/expedient for the client to see it as a new object
and not the one it has seen before. For vk_base_object, this removes
any private data and resets the object name to NULL.
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>
Instead, we return errors from each of the enqueue functions and record
those errors (if any) in vk_command_buffer::record_result. This also
involves some awkward changes to each of the three drivers that uses
vk_cmd_queue but those are resolved in later commits as we convert those
drivers to the common error tracking.
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 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>
Add common entrypoints for enumerating physical devices, based on the RADV implementation.
Signed-off-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17750>
We need to move some earlier (so they are <= 255 like the comment says)
and add a few 64-bit ones.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17894>
For AMD we kinda have some modifiers with a max size ... (Which is
really a compositor/kms issue, but getting them to try kinda falls
into the unsolved "how to allocate/what pitch to use" bucket, so
we solve it on the allocating side)
Cc: mesa-stable
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18139>
This has basically identical semantics to the pseudo-ext enum we were
using before. Also, now that it's in the actual Vulkan enum, we can get
rid of all the #pragma garbage to avoid compiler warnings.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18084>
The PSO still contain the topology class and some Vulkan drivers like
RADV need to know this.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18015>
Compiled from the extension lists on android11-tests-release and
android12-tests-release branches.
v2: remove VK_EXT_color_write_enable that slipped in
Reviewed-by: Emma Anholt <emma@anholt.net> (v1)
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17526>
Compiled from the extension lists on oreo-mr1-cts-release,
pie-cts-release, and android10-tests-release branches.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17526>
I mainly wanted to document that the list is compiled from
dEQP-VK.info.device_extensions and
dEQP-VK.api.info.android.no_unknown_extensions on various Android CTS
release branches. But then I noticed that some extensions should have
api level 26.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17526>
This way drivers can at least see whether dynamic rendering is being
used or not even if they use vk_render_pass. Dynamic rendering only
drivers are expected to ignore those fields anyway.
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17858>
If we don't append subpass->self_dep_info last, other __vk_append_struct()
calls will update its pNext chain which lives in the subpass which
should be treated as immutable. This is easily fixable by just making
it the last thing we append to the chain.
Fixes: 7e11cdc77a ("vulkan/render_pass: Pass sample locations to barriers")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17748>
Yes this is a round trip, but X_PresentPixmap is not itself a blocking
operation, it just instructs the server to do the next presentation at
some time. More importantly, if _we_ don't catch the presentation error,
xlib's error queue will, and the calling code is certainly not prepared
to handle errors from Present.
Forcing the round trip here is also a bit more correct semantically.
This is the end of the Vulkan client part of the present queue, and the
X_PresentPixmap request transfers the queue operation to the server, so
we should not return until we are sure the handoff has happened.
Fixes some flakiness with piglit@glx-visuals-* with zink+radv.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17685>
When we initialize the graphics pipeline state, we skip VI and FSR state
if they're 100% dynamic. We need to do this if the current set of
dynamic things contains VI/FSR or if the set of dynamic state already in
the vk_graphics_pipeline_state has them dynamic. Look state->dynamic
after we've merged instead of just looking at the dynamic set from the
VkGraphicsPipelineCreateInfo we were passed.
Also, when we validate, we need to assume that VI and FSR exist or else
we'll assert if dynamic VI or FSR are set.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17696>
