[vlc-devel] [PATCH] [RFC] decoder: add more decoder device types
robux4 at ycbcr.xyz
Mon Jun 24 10:37:31 CEST 2019
On 2019-06-24 10:32, Thomas Guillem wrote:
> On Mon, Jun 24, 2019, at 10:26, Steve Lhomme wrote:
>> On 2019-06-24 10:00, Thomas Guillem wrote:
>>> On Mon, Jun 24, 2019, at 07:32, Steve Lhomme wrote:
>>>> These are types needed to move the decoder pools that exist in various display
>>>> modules closer to the decoder.
>>>> That means we need to make the decision early on which flavor of OpenGL
>>>> will be
>>>> used before the OpenGL display module is created. Depending on the
>>>> used it could be VAAPI, VDPAU, DXVA2, OpenGL PBO (persistent and
>>>> And to do that we need to create the "decoder device" using the es_format_t
>>>> that will be decoded (so we can pick a hardware decoder or a software one),
>>>> which contains the codec, profile and dimensions. When any of these change we
>>>> will need to create a new decoder device (or check the one we have is
>>>> include/vlc_codec.h | 9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>> diff --git a/include/vlc_codec.h b/include/vlc_codec.h
>>>> index 71f3e8439f..ec5d7e32af 100644
>>>> --- a/include/vlc_codec.h
>>>> +++ b/include/vlc_codec.h
>>>> @@ -491,6 +491,9 @@ enum vlc_decoder_device_type
>>>> + VLC_DECODER_DEVICE_VULKAN,
>>>> + VLC_DECODER_DEVICE_PBO,
>>> For software rendering, VK and GL can be merged. Both will need memory allocated with vlc_memfd(). That way, we could pass the fd to the VK/GL API.
>> Are you sure this can work when using Vulkan on Windows ?
> I guess but I never tested it:
>>> Decoders don't need to know about PBO. Indeed, PBO buffers (in non persistent) are just used as buffer to upload a picture without locking the whole GL context with glTexSubImage2D().
>> OK, so only 1 is necessary. This mode should already be updated to use
>> the "outside" CPU pool and upload the picture during Prepare.
> I don't see why one is necessary. Just pass basic CPU pictures to OpenGL and Vulkan for now.
> Then, GL could upload it using a PBO intermediate buffer. And vulkan could pass the FD directly (and fallback to memcpy it there is no FDs).
>>> And for persistent mode, I think we can drop it. Yes, from VLC point of view, there is one less memcpy, but I guess it is still done in the GL/Driver side since persistent buffers are mapped on the CPU. Mapping buffers in GPU is worst by the way, since it is very slow to access them (for reference frames for example).
>> IMO in persistent mode the driver uses a backend copy. The visible on is
>> always the CPU one, but when it's needed in the GPU for rendering, it's
>> transfered there. At least on integrated GPUs it's the same memory so
>> it's not an issue, the driver doesn't need to do any trick and we get
>> good perf.
>> I don't feel comfortable dropping a zero copy mode unless we know it's
>> actually slower (no driver tricks).
> That is what we decided with Niklas, Rémi and Alexandre during the last vout workshop.
OK. These changes need to be done before the code is moved for push then.
More information about the vlc-devel