Extensions and layers can be enabled before calling
gst_vulkan_instance_open() but after calling
gst_vulkan_instance_fill_info().
Use the list of available extensions to better choose a default display
implementation to use based on the available Vulkan extensions for surface
output.
Defaults are still the same.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1341>
The unit tests only checked for vulkan_dep.found(), which can
be true if the libs are there but glslc was not found, in which
case the plugin wouldn't be built and the unit tests would fail
because of missing vulkan plugins.
Doesn't really make much sense to build the vulkan integration lib
either if we're not going to build the vulkan plugin, so just disable
both for now if glslc is not available.
Fixes#1301
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1307>
This was removed in Vulkan 1.2.140.
> Shortly after 2020-04-24, we will be removing the automatically
> generated `VK_*_BEGIN_RANGE`, `VK_*_END_RANGE`, and `VK_*_RANGE_SIZE`
> tokens from the Vulkan headers. These tokens are currently defined for
> some enumerated types, but are explicitly not part of the Vulkan API.
> They existed only to support some Vulkan implementation internals,
> which no longer require them. We will be accepting comments on this
> topic in [#1230], but we strongly suggest any external projects using
> these tokens immediately migrate away from them.
[#1230]: https://github.com/KhronosGroup/Vulkan-Docs/issues/1230
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1255>
Posting any message to parent seems to be pointless. That might break
parent window.
Regardless of the posting, parent window can catch mouse event
and also any keyboard events will be handled by parent window by default.
It's currently the only sane way we can use MoltenVK functions to
integrate with Metal API.
It also removes the need to specify the VK_ICD_FILENAMES environment
variable pointing to MoltenVK_icd.json.
Includes a new GstVulkanHandlePool base class for pooling different
resources togther. The descriptor cache object is ported to
GstVulkanHandlePool with the exact same functionality.
A new GstVulkanFenceCache is also implemented for caching fences
which is used internally by GstVulkanDevice for creating or reusing
fences.
The existing GstVulkanTrashFenceList object now caches trash objects.
Part 1 is a base class (vkvideofilter) that handles instance, device,
queue retrieval and holding that has been moved to the library
Part 2 is a fullscreenrenderquad that is still in the plugin that
performs all of the previous vulkan-specific functionality.
Weak refs don't quite work here correctly as there is always a race with
taking the lock between find_view() and remove_view(). If find_view()
returns a view that is going to removed by remove_view() then we have an
interesting situation.
In theory, the number and type of views for an image are relatively
constant and should not change one they've been set up which means that
it is actually practical to perform pool-like reference counting here
where the image holds a pool of different views that it can give out
as necessary.
The major functionality gain this provides is proper reference counting
for a descriptor set. Overall this allows us to create descriptor sets
when they are needed (or reused from a cache) without violating any of
vulkan's object synchronisation requirements.
As there are a fixed number of sets available in a pool, the number of
descriptors in elements is currently hardcoded to 32. This can be extended
in a future change to create pools on the fly if that limit is ever overrun.
Allows a cleaner control flow when there is no fence available for use
with the trash list. An always signalled fence type will always return
TRUE for gst_vulkan_fence_is_signalled.
Serve two purposes:
1. refcounting of vulkan handles with associated destruction. When
combined with the trash list, the user can ensure destruction at
the correct time according to the vulkan rules.
2. avoids polluting our API with 32-bit vs 64-bit integer/pointers
differences as exposed through the vulkan API. on 32-bit, vulkan
non-dispatchable handles are 64-bit integers and on 64-bit, they
are pointers.
