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>
Some of our asserts and other checks depend on the total set of stages,
not just the stages set in the current pCreateInfo. Recording the stage
mask lets us combine them in vk_graphics_pipeline_state_merge().
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17696>
In particular, we now call it before running dead variables so we get
the XFB info even for things which are never written. This fixes a 102
Vulkan CTS tests on ANV and probably turnip as well.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17644>
in this case, lying about having multiple images and then returning the
same image every time doesn't work, so use the busy flag
and return an available image when possible
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17590>
