New vulkan formats don't match the number of planes with the number of memories
attached to the buffer. This patch changes the pattern of using planes for
traverse the memories with the number of attached memories.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
It's a generalization of the original gst_vulkan_get_or_create_image_view().
The reason for passing the whole VkImageViewCreateInfo structure rather than
just the missing fields, is because VkImageSubresourceRange and
VkComponentMapping can be different and those are most of VkImageViewCreateInfo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
This is going to be used when the pool is used by a video decoder for
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR, since the frame allocation needs the
VkVideoProfileInfoKHR, and for that here GstCaps is used to wire it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
The specification says:
VUID-vkAllocateMemory-pAllocateInfo-01713
must pAllocateInfo->allocationSize be less than or equal to
VkPhysicalDeviceMemoryProperties::memoryHeaps[memindex].size where memindex =
VkPhysicalDeviceMemoryProperties::memoryTypes[pAllocateInfo->memoryTypeIndex].heapIndex
as returned by vkGetPhysicalDeviceMemoryProperties for the VkPhysicalDevice that
device was created from.
Though this can be catch by the validation layer, the requested frame size
depends on the use case so it's better to check this restriction by our code.
This patch also makes use of this new function to find memory type index,
and removes the unused function to find memory type index, which, as GstVulkan is
considered unstable, we can do it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
The purpose of this function is to get more info about the mapped Vulkan format
from the GStreamer format, since they can be multiple Vulkan formats for one
GStreamer format.
Also a Vulkan format may have certain usage and aspects that must be verified.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
Originally the opened device only created one queue of one family queue, to say
graphics one. This approach felt short when other queue family is required not
shared with the graphics queue family, for example video decoding.
This new approach proposes to create those queues with supported families. For
now, only video decoding and encoder are created, if they are available.
In order to hold multiple queues opened, an array of VkDeviceQueueCreateInfo is
held along the live the device object, because it's used to traverse or get the
opened queues.
The algorithm to choose which queues create (or open) is to look for the queue
with more family bits, which also supports the one we are requesting, thus
minimizing the number of global queues of a certain family to create.
Nonetheless, the number of queues to open per family is set to be all of them,
widening the possibility of parallelism.
Also, this commit do a cosmetic refactor the assigning the physical device
nearer where it's used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
Also adds a meson option to enable them.
The symbol GST_VULKAN_HAVE_VIDEO_EXTENSIONS is an alias of
defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 238
if the option is allowed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
This is no longer needed since the introduction of `gst_macos_main()` in 1.22.
Before that existed, we had a patch for GLib in Cerbero, which did work but made it
impossible to update GLib at all. The code being removed was a fail-safe in case of
running without said patch being applied. It's no longer needed, since for macOS
we just wrap our GStreamer with an NSApplication using `gst_macos_main()`.
Warnings will be displayed if no NSApp/NSRunLoop is found wherever needed,
pointing the user towards using the new API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4366>
Running element_vkcolorconver test with Vulkan validation layer this error is
raised:
Code 0 : Validation Error: [ VUID-VkMappedMemoryRange-size-01390 ] Object 0:
handle = 0x100000000010, type = VK_OBJECT_TYPE_DEVICE_MEMORY;
| MessageID = 0xdd4e6d8b
| vkFlushMappedMemoryRanges: Size in pMemRanges[0] is 0x4, which is not a
multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize (0x40) and offset +
size (0x0 + 0x4 = 0x4) not equal to the memory size (0xb). The Vulkan spec
states: If size is not equal to VK_WHOLE_SIZE, size must either be a multiple of
VkPhysicalDeviceLimits::nonCoherentAtomSize, or offset plus size must equal the
size of memory
The reason of is that the image size used in the test doesn't comply hardware
restrictions. In order to avoid juggling with image size and hardware
restrictions, this patch proposes to use VK_WHOLE_SIZE macro.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4296>
While using the validation layer with this pipeline:
gst-launch-1.0 videotestsrc num-buffers=10 ! vulkanupload ! vulkancolorconvert ! vulkansink
The validation layer throws this message:
Code 0 : Validation Error: [ VUID-VkAttachmentDescription-format-06699 ]
Object 0: handle = 0x5555562e9610, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x52b3229e |
vkCreateRenderPass: pCreateInfo->pAttachments[0] format is
VK_FORMAT_B8G8R8A8_UNORM and loadOp is VK_ATTACHMENT_LOAD_OP_LOAD, but
initialLayout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: If format includes a color or depth aspect and loadOp is
VK_ATTACHMENT_LOAD_OP_LOAD, then initialLayout must not be VK_IMAGE_LAYOUT_UNDEFINED
When creating the render pass the loadOp can be either
`VK_ATTACHMENT_LOAD_OP_CLEAR` or `VK_ATTACHMENT_LOAD_OP_LOAD` depending on
`enable_clear`. While `enable_clear` is FALSE by default (which means
`VK_ATTACHMENT_LOAD_OP_LOAD`). Nonetheless, its value is explicitly changed by
`vkoverlaycompositor` to FALSE too!
This behavior was introduced in merge request #2470 where
`VK_ATTACHMENT_LOAD_OP_CLEAR` was a fixed value for loadOp. Thus, the bug
consists in a missing initialization of `enable_clear` to TRUE from that merge
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4296>
Specification says:
"""
engineVersion is an unsigned integer variable containing the developer-supplied
version number of the engine used to create the application.
"""
Assuming the engine is GStreamer, it would be expected to set its version as
engine version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4243>
Spec 7.1.3:
If a memory object does not have the VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
property, then vkFlushMappedMemoryRanges must be called in order to guarantee
that writes to the memory object from the host are made available to the host
domain, where they can be further made available to the device domain via a
domain operation. Similarly, vkInvalidateMappedMemoryRanges must be called to
guarantee that writes which are available to the host domain are made visible to
host operations.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3723>
These null checkes are slightly misleading when double-checking
mutability for external language interop. None of the functions in
these files allow the variable at hand to become `NULL` under normal
operation, because they are checked at initialization and never (allowed
to be) reassigned to `NULL`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1615>
