linux-kernel - Re: Stateless Encoding uAPI Discussion and Proposal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e9f01000-d2ed-8193-420c-fb80f0b96f8f@soulik.info>
Date:   Thu, 31 Aug 2023 00:51:33 +0800
From:   Randy Li <ayaka@...lik.info>
To:     Nicolas Dufresne <nicolas.dufresne@...labora.com>
Cc:     linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Hsia-Jun Li <Randy.Li@...aptics.com>,
        Hans Verkuil <hverkuil@...all.nl>,
        Sakari Ailus <sakari.ailus@....fi>,
        Andrzej Pietrasiewicz <andrzej.p@...labora.com>,
        Michael Tretter <m.tretter@...gutronix.de>,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Samuel Holland <samuel@...lland.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal


On 2023/8/30 23:10, Nicolas Dufresne wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Le mercredi 23 août 2023 à 11:04 +0800, Hsia-Jun Li a écrit :
>>> Though, if we drop the GOP structure and favour this approach, the latency could
>>> be regain later by introducing fence base streaming. The technique would be for
>>> a video source (like a capture driver) to pass dmabuf that aren't filled yet,
>>> but have a companion fence. This would allow queuing requests ahead of time, and
>>> all we need is enough pre-allocation to accommodate the desired look ahead. Only
>>> issue is that perhaps this violates the fundamental of "short term" delivery of
>>> fences. But fences can also fail I think, in case the capture was stopped.
>>>
>> I don't think it would help. Fence is a thing for DRM/GPU without a queue.
>> Even with a fence, would the video sink tell us the motion delta here?
> It helps with the latency since the encoder can start its search and analyzes as
> soon as frames are available, instead of until you have all N frames available
> (refer to the MIN_BUFFER_FOR controls used when lookahead is needed).

I think the fence in GPU is something attached to per frame 
buffer(IN_FENCE) or completing the render(OUT_FENCE).

So when we enqueue a buffer, what are expecting from the fence?

I think in KMS, you can't enqueue two buffers for the same plane, you 
have to wait the OUT_FENCE.

>
>>> We can certainly move forward with this as a future solution, or just don't
>>> implement future aware RC algorithm in term to avoid the huge task this involves
>>> (and possibly patents?)
>>>
>> I think we should not restrict how the userspace(vendor) operate the
>> hardware.
> Omitting is not restricting. Vendors have to learn to be community members and
> propose/add the tools and APIs they need to support their features. We cannot
> fix vendors in this regard, those who jumps over that fence are wining.

That is not about what vendor would do. I was thinking we are planning 
how we manage the lifetime of the reconstruction buffer, reference 
selecting based on a simple GOP model.
What was designed here would become a barrier for a vendor whose 
hardware has a little capability than this.

All I want to do here is offer my ideas about how we could achieve an 
open interfaces that could cover the future need.

Especially it is hard to expand the V4L2 uAPIs.

>
> Nicolas