In order to link videomaintenance1, and others to come, without knowing if
Vulkan 1.4 features are chained in the device properties structure, a static and
inlined function was added in gstvkphysicaldevice-private.h. It was added in a
header file to avoid compiler warnings if it's not used because of old Vulkan
headers.
Also the value dump videomaintenance1 was moved to another function to pack
there all the future features to query which aren't part of a Vulkan release
yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
This patch is the payment to my technical debt.
The symbol GST_VULKAN_HAVE_VIDEO_EXTENSIONS is defined at compilation-time if
the user requests for the usage of the Vulkan Video extensions. And we used this
symbol for anything related with Vulkan Video. But this is not the smartest
approach.
The rule should be:
- If the code allocates Vulkan Video resources, use
GST_VULKAN_HAVE_VIDEO_EXTENSIONS
- Otherwise, use the Vulkan's guard for the used API
In this way, API version bumps will be easier.
Also, this commit marks the end of GST_VULKAN_HAVE_VIDEO_EXTENSIONS guarded code
for readability.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
Both gst_vulkan_image_buffer_pool_set_config() and
gst_vulkan_image_buffer_pool_alloc() functions share the same code to create
Vulkan images for different purposes.
This patch refactor them in a new helper function that creates the images and
stores them in a buffer if it's passed as output parameters, such as the
offsets.
This patch also adds specifics guards for Vulkan's symbols for better grained
API usage, but also for prepare_buffer() the guard is set where the symbol is
used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
The Vulkan Video extensions can be available, according to the specification,
since Vulkan 1.1, but with other extensions dependencies. That's why this patch
adds a field in the extension structure, which represents the extension
dependency that the specified extension requires. And they are specified by
Vulkan Video extensions.
This allow to have a single function to check if the extension can be enabled
both by optional extensions and video extensions.
Regardless that video extension can be loaded since Vulkan 1.1, they are rather
loaded since Vulkan 1.3, when synchronization2 was promoted, so it isn't
checked as video_queue dependency.
Finally, this patch checks for each guard symbol.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
This is a continuation of !9483, but without back-porting.
Instead of checking the driver's API version to figure out if a physical device
feature is available and enabled, or even more, instead of checking for enabled
extensions in the driver, this patch adds private functions in the physical
driver to get the availability and enabling of features such as sampler ycbrc
conversion, synchronization2, timeline semaphore and video maintenance1.
And these new functions are used internally in the GstVulkanOperation object,
and the private object GstVulkanDecoder.
This approach is computationally cheaper, simpler and precise.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
For the features VkPhysicalDeviceSamplerYcbcrConversionFeaturesKHR,
VkPhysicalDeviceSynchronization2Features and
VkPhisicalDeviceTimelineSemaphoreFeatures
The Vulkan specification states:
If the `VkPhysicalDeviceXXXFeatures` structure is included in the `pNext`
chain of the `VkPhysicalDeviceFeatures2` structure passed to
`vkGetPhysicalDeviceFeatures2`, it is filled in to indicate whether each
corresponding feature is supported. If the application wishes to use a
`VkDevice` with any features described by `VkPhysicalDeviceXXXFeatures`,
it **must** add an instance of the structure, with the desired feature members
set to `VK_TRUE`, to the `pNext` chain of `VkDeviceCreateInfo` when creating
the `VkDevice`.
And that was missing in the code.
Strangely, that functionality doesn't have a Valid-Usage ID assigned, so it
isn't caught by the validation layer.
This patch adds the structures in the physical devices to get them and later set
them in the device creation.
In order to link these features, videomaintenance1, and others to come, without
knowing if Vulkan 1.3 features are chained in the device properties structure, a
static and inlined function was added in gstvkphysicaldevice-private.h. It was
added in a header file to avoid compiler warnings if it's not used because of
old Vulkan headers.
Also the value dump videomaintenance1 was moved to another function to pack
there all these queried features.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9483>
Add d3d12fisheyedewarp element that performs fisheye image dewarping
using D3D12. A UV remap LUT texture is generated via a compute shader,
and the actual remapping is performed in a pixel shader using this LUT
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9441>
Modify the API to retrieve the tensor meta to check for the dimensions
as well.
Also fix an API mistake, the buffer whose dimensions should be checheck
is the one inside the GstTensor, not another buffer some outside.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9411>
Similar to h264parse and h265parse, this patch improves the element to parse
the SEI registered user data from NAL units. The core structure of H266 SEI for
ITU-T T.35 is the same as the other parsers, so we can re-use the same logic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9365>
Similar to and inspired by glimagesink, xvimagesink and others.
The waylandsink never transform the buffer in any way but delegates this to the
Wayland compositor with the Wayland buffer transform API.
Rotation and window size are already supported, so this just changes the video
surface geometry that is communicated to the Wayland compositor.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9210>
This patch adds the possibility to attach video metas to allocated buffers if
API users request that option.
The main reason to add this meta is for the future usage of
gst_buffer_find_memory(), where the requested offset determines the memory
index.
In the case of multi-memory Vulkan images the offset of every component is
larger than the default offset determined by the format and frame size, because
of the buffer minimum size and memory alignment determined by the used driver.
Then, the offset is set in the buffer video meta.
In the case of single memory Vulkan images, the default offset is set in the
video meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9219>
