[FFmpeg-devel] [PATCH 1/2] hwcontext_vulkan: expose the amount of queues for each queue family

[Lynne]

May 20, 2020, 22:43 by sw at jkqxz.net:

> On 19/05/2020 22:29, Lynne wrote:
>
>> May 19, 2020, 20:50 by sw at jkqxz.net:
>>
>>> On 13/05/2020 16:53, Lynne wrote:
>>>
>>>> This, along with the next patch, are the last missing pieces to being 
>>>> interoperable with libplacebo.
>>>> There is no danger of users running into this API break because there are none,
>>>> and API was completely backwards-incompatibly changed just 2 days ago.
>>>> This is needed so we won't have to break the API anymore in the future.
>>>>
>>>
>>> ?  The previous change wasn't an ABI break after the fields were rearranged properly.
>>>
>>
>> The number of fences per image was what I was referring to.
>>
>
> Huh, right - I hadn't seen those two breaks at all and they weren't mentioned in APIchanges.  If you are going to apply multiple changes which break API and ABI like this then perhaps it would be better to note in the relevant headers that the Vulkan API is experimental and compatibility may be broken unexpectedly?  That would avoid this discussion being repeated.
>

We've ironed out all the issues regarding using the API externally, and I've spend a week now thinking
about if there are any other hitches that would require us to break the API, and I couldn't really think of any.
So with those changes, I'll  freeze it ABI/API wise.

The decoding (and encoding?) extensions may require additions to the frame structure, but with it
not being part of the ABI (I think it was a really good decision) we can extend it without breaking anything.



> I was imagining it could somehow help when using Vulkan in the ffmpeg.c case.  Still, that makes sense, so fair enough.
>

Reducing the total amount of queues ffmpeg.c uses would just slow things, but would leave more
resources for other programs, so that's why I hinted we may want to add that as an option in the future,
but as-is, I don't see much point adding that now.