v3dv, radv, and turnip are using several C&P format helpers (most of
them wrappers over util_format_description based helpers). methods.
This commit moves the common helpers to the already existing common
vk_format.h. For the case of v3dv we were able to remove the vk_format
header. For turnip and radv, a local vk_format.h header remains, with
methods that are only used for those drivers.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13858>
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>
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>
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>
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>
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>
v2: move checks to vk_device_init, ignore struct types from
provisional extensions + lots of cleanups/fixes (Jason Ekstrand)
v3: squash in following patch from Jason:
"vulkan: Restructure vk_physical_device_check_device_features()"
v4 (Jason): Fix a Windows build error
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12867>
The vk_shader_module_handle_from_nir() macro was constructing a
temporary vk_shader_module and passing it through
vk_shader_module_to_handle(). Since this is a function and not a macro,
it means that the lifetime of the temporary vk_shader_module will end
once the to_handle() function is called. Technically, this is a
use-after-free. I really don't know why no one has been bitten by this
yet....
Fixes: a41e98ddca "vk/util: add a util macro for initializing stack..."
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13101>
Yonggang Luo