[FFmpeg-devel] [PATCH] hwcontext_vulkan: fix exporting multi-plane DRM modifiers

[Lynne]

On 03/05/2025 17:01, Russell Greene wrote:
>> vkGetPhysicalDeviceToolPropertiesEXT(dev, nb, array)
>> If pToolProperties is NULL, then the number of tools currently active on
>> physicalDevice is returned in pToolCount. Otherwise, pToolCount must
>> point to a variable set by the application to the number of elements in
>> the pToolProperties array, and on return the variable is overwritten
>> with the number of structures actually written to pToolProperties. If
>> pToolCount is less than the number of currently active tools, at most
>> pToolCount structures will be written.
>>
>> It's in the spec. Different function, but all functions which write to
>> an array follow the same signature.
> 
> Sorry, I guess I wasn't clear about my question.
> 
> I understand that you can fetch the size by setting the data pointer
> to NULL, etc. The question is "is there way to fetch the number of
> memory planes a modifier uses without allocating memory?"

...that's exactly what I posted.
Set array to non-NULL, set nb to the array size you're giving it, and 
you'll get UP TO nb, no more, even if the driver has more.
> My understanding is:
> 1. There is no fixed number of modifiers a driver can expose (this may
> be wrong, but seems to me it would be a strange limitation, and I
> don't see anything in the vk spec or drivers that indicat that this
> could be the case)
> 2. We don't know where in the modifier list the one we want info about is
> 
> So therefore, we have to fetch the info for *all* modifiers, which as
> I understand it probably requires at least a slow path with an
> allocation for drivers that potentially have a lot of modifiers.
> 
> If we're OK with a practical "we don't support drivers with more than
> X modifiers because we doubt it'll ever exist" then that's a valid
> answer as well.
If that's your concern, just fetch all info for all modifiers in the 
init function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA2FEA5F03F034464.asc
Type: application/pgp-keys
Size: 624 bytes
Desc: OpenPGP public key
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250503/48b28a1e/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250503/48b28a1e/attachment.sig>