May 20, 2020, 22:43 by s...@jkqxz.net: > On 19/05/2020 22:29, Lynne wrote: > >> May 19, 2020, 20:50 by s...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".