Jan 21, 2020, 18:22 by an...@khirnov.net: > Quoting Lynne (2020-01-21 18:51:22) > >> Jan 21, 2020, 12:08 by an...@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. _______________________________________________ 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".
