linux-kernel - Re: [PATCH v7 6/6] arm64: dts: rockchip: Add VPU121 support for RK3588

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f04e25bf3c09c55049775e8f012cb653cb4682ba.camel@collabora.com>
Date: Wed, 26 Jun 2024 13:46:03 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Jianfeng Liu <liujianfeng1994@...il.com>, sebastian.reichel@...labora.com
Cc: conor+dt@...nel.org, devicetree@...r.kernel.org, 
 ezequiel@...guardiasur.com.ar, frattaroli.nicolas@...il.com,
 heiko@...ech.de,  kernel@...labora.com, krzk+dt@...nel.org,
 linkmauve@...kmauve.fr,  linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org,  linux-rockchip@...ts.infradead.org,
 p.zabel@...gutronix.de, robh@...nel.org,  sigmaris@...il.com,
 detlev.casanova@...labora.com
Subject: Re: [PATCH v7 6/6] arm64: dts: rockchip: Add VPU121 support for
 RK3588

Hi Jianfeng,

Le vendredi 21 juin 2024 à 17:22 +0800, Jianfeng Liu a écrit :
> Hi Sebastian,
> 
> Detlev is working on rkvdec2 and gstreamer can't deal with two h264

Just to clarify, since you are right that it won't work well with GStreamer. It
does work with multiple decoders (it exposes them all), it is simply that it
will randomly pick one when decoding, and it may not pick the best one.

> stateless decoders. So it's better to disable h264 decoding feature of
> this vpu121, just like what we have done for rk3399. If your multicore
> patch can handle the jpeg enc node at fdb50000 with other VEPU121 nodes
> properly, we can just use compatible string "rockchip,rk3399-vpu" instead
> of "rockchip,rk3568-vpu".

In the long term, I'd like to stop having to do "like downstream" and expose
them all. I believe the fix is fairly straightforward in GStreamer. We need to
expose in the generated element the width/height ranges, and for H.264 the
supported profiles and level. With that, we at least won't randomly fail at
decoding 4K, and it should be good enough.

For RK3588, which is a new SoC, its not a problem to upstream something that
does not work with existing userspace. It would only be a regression if we where
to enable VDPU121 on RK3399, as now updating linux would cause bugs with
existing userspace.

For users, it would be best if we get this sorted out in GStreamer by the time
we have a second decoder. Note that I have some vacation coming up this month,
so there might be extra delays. Yet, its logical to merge this (the "worst"
decoder) first, since then randomly picking a better one won't be a regression.

Nicolas