Lavapipe was hitting asserts in this area due to incorrect bits being
specified.
Set the handle type depending on the sw flag, and set a correct handle
type for the memory host ptrs.
v2: add image export struct to image creation (Jason)
Fixes: 895d3399f7 ("lavapipe: add support for KHR_external_memory_fd")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13615>
Instead of having a bunch of stuff depend on vk_dispatch_table_gen to
get the list of entrypoints, pull that into its own vk_entrypoints file.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13156>
Depending on whether an application creates a swapchain with
VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR or not, we might use 2
different formats with the compositor.
This change makes sure that we support all the underlying formats
before exposing the corresponding VkFormat to the application.
v2: Don't forget get_formats2() (Ivan)
v3: Replace formats with availability boolean (Simon)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 151b65b211 ("vulkan/wsi/wayland: generalize modifier handling")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5522
Reviewed-by: Ivan Briano <ivan.briano@intel.com> (v2)
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13453>
When compiling for x86 with MSVC, Vulkan API entry points follow the
__stdcall convention (VKAPI_CALL maps to __stdcall), which uses the
following name mangling:
_<function_name>@<arguments_size>
Fix the vk_entrypoint_stub()/alternatename definitions accordingly.
Fixes: 6d44b21d4f ("vulkan: Fix weak symbol emulation when compiling with MSVC")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13516>
We already have code to deal with non-client-visible objects but we were
asserting if it didn't fall into one of the clearly mappable error
cases. However, we didn't have a mapping for VK_ERROR_NOT_PERMITTED
which can happen during object creation. Let's just be sloppy and drop
the assert. Worst case, the client gets an error with no object.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13341>
VK_ERROR_INITIALIZATION_FAILED can happen as part of device creation and
isn't really an instance error in that case.
VK_ERROR_EXTENSION_NOT_PRESENT, on the other hand, is always an instance
thing and we should handle it as such.
Fixes: 0cad3beb2a ("vulkan/log: Add common vk_error and vk_errorf helpers")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13341>
If we don't do that we hit the assert(entry[i] != NULL) added by commit
6d44b21d4f ("vulkan: Fix weak symbol emulation when compiling with MSVC").
Fixes: 6d44b21d4f ("vulkan: Fix weak symbol emulation when compiling with MSVC")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13355>
Mapping unimplemented entrypoints to a global function pointer variable
initialized to NULL is a bit cumbersome, and actually led to a bug
in the vk_xxx_dispatch_table_from_entrypoints() template: the !override
case didn't have the right check on the source table entries. Instead of
fixing that case, let's simplify the logic by creating a stub function
and making the alternatename pragma point to this stub. This way we get
rid of all those uneeded xxx_Null symbols/variables and simplify the
tests in vk_xxxx_dispatch_table_from_entrypoints().
Cc: mesa-stable
Fixes: 98c622a96e ("vulkan: Update dispatch table gen for Windows")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13348>
Since we're not checking for this, xcb has to do it for us the first
time we call xcb_sync_destroy_fence, which puts a blocking round-trip in
the swapchain destroy path for no reason. Check for the extension so we
have the extension's opcode cached when we need it.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13339>
For a long time, our Vulkan WSI code has acted as something of a layer.
The WSI code calls into various Vulkan entrypoints inside the driver to
create images, allocate memory, etc. It then implements the API-facing
interface almost entirely. The only thing the driver has to provide is
little wrappers that wrap around the WSI calls to expose them through
the API.
However, now that we have a common dispatch framework, we can implement
entrypoints directly in the WSI code. As long as the driver uses
vk_instance, vk_physical_device, and vk_device, we can provide common
wrappers for the vast majority of entrypoints. The only exceptions are
vkAcquireNextImage, vkQueuePresent, vkRegisterDeviceEventEXT, and
vkRegisterDisplayEventEXT because those may have to manually poke at
synchronization primitives. We provide wrappers for vkAcquireNextImage
and vkQueuePresent because some drivers can use the default versions.
For now, we're intentionally avoiding any link-time dependencies between
WSI and the common code. We only use VK_FROM_HANDLE and associated
inline helpers and vk_physical_device has a pointer to a wsi_device.
Eventually, we may tie the two together closer, but this lets us get 95%
of the way there without reworking the universe.
Acked-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13234>
Instead of basing it on a fixed list, just generate #defines for every
bitfield that's 64-bit. As part of this refactor, we rework things a
bit to record all bitfields and just not do anything with them if
they're not 64-bit.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13198>
In function fill_drm_device_info(), struct ext_pci_properties is filled only
if has_vulkan11 is true. But the data received from ext_pci_properties is used
without checking for has_vulkan11. Fixing this by setting
drm_device->has_bus_info also if has_vulkan11 is true.
This fix will help in case of nonidentical gpu being used and xcb_surface
extension enabled.
Signed-off-by: Yogesh Mohanmarimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12816>
Make u_vector_init a wrapper to u_vector_init_pot. Let both take
(element_count, element_size) as parameters.
Motivated by eed0fc4caf ("vulkan/wsi/wayland: fix an invalid
u_vector_init call")
v2: rename u_vector_init_pot to u_vector_init_pow2
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13201>
With a tiny bit more code-gen, we can now not only throw the error but
also log back to the client exactly which feature was missing.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
We have to be a bit careful here. Calling log functions during instance
initialization can be a bit sketchy. However, we know that __vk_log_impl
only ever touches the callbacks lists if instance->base.client_visible
so it's safe to call vk_error as soon as we've set up instance_callbacks.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
Now that we no longer have every driver in the tree defining their own
__vk_errorf and __vk_errorv, we don't need to worry about the symbol
collision anymore and can use the "real" names for the common ones.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
These helpers have quite a bit of smarts in them to log errors to chase
the object chain as needed and log errors to roughly the appropriate
object. For instance, VK_ERROR_OUT_OF_DEVICE_MEMORY always goes to a
device while VK_ERROR_OUT_OF_HOST_MEMORY always goes to the instance.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
Instance-level objects won't have a device pointer so we can't rely on
that. Instead, we should look at the object type and try to chase it
back to an instance. Sadly, we can't do that for certain display and
WSI objects. However, we never use the vk_log* helpers for those.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
If the instance isn't client-visible yet (i.e. foo_instance_to_handle
hasn't been called), then the instance is still under construction and
we should log using vk_debug_message_instance. This makes the vk_log*
macros work regardless of whether the instance is fully constructed or
not.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
When dealing with debug logging, it's useful to track when an object's
construction is finished and it's now visible to the client. We can
detect this pretty easily by setting a flag the first time foo_to_handle
is called. As long as drivers only ever call that function at the end
of object construction (they all do to my knowledge), this should be a
reliable mechanism for detecting when a client knows about a handle.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
It's no longer used and just makes the init/finish path more
complicated.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
One of the unfortunate effect of Vulkan starting to use 64bit bitmasks
is that they can no longer be defined using enums because C doesn't
guarantees that enum values will be 64bits.
Vulkan therefore started using those patterns :
static const VkAccessFlags2KHR VK_ACCESS_2_INDIRECT_COMMAND_READ_BIT_KHR = 0x00000001;
This has the effect that we can not longer use those values in
switch/case statements.
This change introduces defines so that we can keep doing this. For now
only VkAccessFlags2KHR/VkPipelineStageFlags2KHR are allowed to be
redefined this way, this list could be changed later (or all bitmask
could be processed this way).
v2: Generate hexadecimal numbers (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9045>
these were duplicated all over the place, and it's annoying to have to keep
duplicating them any time a new component includes the vulkan header
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13141>
