[FFmpeg-devel] [PATCH] Vulkan hwcontext and filters

[Lynne]

Jan 21, 2020, 18:22 by anton at khirnov.net:

> Quoting Lynne (2020-01-21 18:51:22)
>
>> Jan 21, 2020, 12:08 by anton at khirnov.net:
>>
>> > Quoting Lynne (2020-01-10 22:05:21)
>> >
>> >>  /**
>> >>  * Activated physical device
>> >>  */
>> >>  VkDevice act_dev;
>> >>
>> >
>> > Where is this 'activated' terminology from? From what I can see, the
>> > spec calls this a 'logical' device. Would be nice to be consistent with
>> > it.
>> >
>>
>> Its just the current active device. Not really wanting to change it,
>> its pretty clear what it is from the type.
>>
>
> Can't really force you, but I'd prefer you did change it. At least drop
> 'physical' from the doxy, since the spec makes a distinction between
> 'physical' and 'logical' devices and this is not a physical device.
>

Done.



>> Its size too? Didn't know that.
>> I do think its a good idea to be able to append fields to it, so I've
>> added a av_vk_frame_alloc() function. I've followed what
>> av_frame_alloc is called, though I'm not sure if its too close to that
>> one's name.
>>
>
> My original intent with this API was that calles are allowed to provide
> their own pools. Not sure if that's still allowed or works though. But
> if it is, the caller needs to be able to allocate/free AVkFrame.
>

They are of course. The first wip of the cuda interop exploited that IIRC.
But I think the issue is that in order for API users to make their own pools they need to
know the size in bytes of AVVkFrame since that's what av_buffer_create() accepts.
I could make a function to return that, but I'm wondering if its somewhat too big of a mess already.
I could instead reserve some memory in the struct, a few hundred bytes would be enough since every Vulkan object has to be allocated on heap.