These provide a way for apps that initialize Vulkan themselves to know
which extensions we may be able to use without having to hardcode it.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Possible since 222127418b.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reading the spec for what this flag means, it copies the data verbatim, including any swizzling/tiling, this has two issues
1. the format may not be what ffmpeg expects elsewhere, as it is expecing normal pitch linear host memeory in `swf`
2. the size of the copied data may not match the size of buffer provided, causing heap buffer overflow
It seems like addition of this flag is an oversight as it seems to be for caching/backups of image data, just to be used with copying back to the GPU with the MEMCPY flag, which is *not* how its used in ffmpeg.
Additionally, set memoryRowLength as if it isn't set, it assumes pitch = width_in_bytes, which I don't think is necessarily the case
Vulkan headers define *FlagBits enum with individual bit values, and
coresponding *Flags typedef to be used to store the bitmask of
coresponding bits.
In practice those two types map to the same type, but for consistency
*Flags should be used.
Fixes MSVC warnings about type mismatch.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
We have no use for 14-bit pixel formats for now, so remove support for gray14,
which was broken due to the LSB padding issue.
Similarly YUVA at 10/12 bit was broken for the same reason.
The documentation states that this field is for enabling "extra" usage
flags. This conflicts with the implementation, and the rest of the comment,
though.
In resolving this ambiguity, I think it's better to lean towards the first
sentence and treat this field purely as specifying *extra* usage flags to
enable. Otherwise, this may break vulkan encoding or subsequent hwdownload
if the upstream filter did not specifically advertise this.
Change the default behavior and update the documentation slightly to more
clearly document the semantics.
Previously, it was assumed that `drmFormatModifierPlaneCount` was one
for all modifiers when exporting, which is not always the case, in
particular for AMD GPUs and maybe others.
Fetch the number of memory planes and fill the structs appropriately in this situation.
The encoded stream is still bad in the case whre modifers are involved,
but I think this patch still stands on its own and I suspect that may be a driver bug.
A potential improvement that could be make is to cache the format
information, so we can avoid the two GetPhysicalDeviceFormatProperties2
calls for each export, as well as the allocation. I doubt this is very
expensive, but seemed worth noting.
v2 changes: query the format properties with the test image created in
`vulkan_frames_init` to avoid allocating space for the query during
export
Signed-off-by: Russell Greene <russellgreene8@gmail.com>
The issue is that vulkan_device_create_internal() is only called for
devices that lavu creates by itself.
For external devices, this was never done.
This also solves some mid-function declaration warnings.
This feature fundamentally relies on host-visible VRAM, which restricts the
set of available memory types to (typically) host-visible device-local ones.
When resizable BAR is disabled, this memory type is usually limited to
e.g. 256 MiB in size, which is just plain insufficient for allocation of
general purpose GPU images, causing OOM errors on even the simplest of
commands.
The easiest solution is to disable host transfers entirely on machines
without host-addressable VRAM. In theory, we could try and recover the use
of host transfers for images which are *not* restricted to device-local
memory types, but this is rarely the case in practice, and the effort
required would exceed the benefit, especially since ReBAR is a standard
feature on all platforms recent enough to have Vulkan drivers, and only
occasionally disabled in the UEFI for by default for some hare-brained
notion of "backwards compatibiility" with ancient software.
