| Message ID | 20231231151112.3994194-1-liujianfeng1994@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add hantro g1 video decoder support for RK3588 | expand |
Le dimanche 31 décembre 2023 à 23:11 +0800, Jianfeng Liu a écrit : > This is the v3 version of this series adding hantro g1 video decoder > support for rk3588. > > RK3588 has Hantro G1 video decoder known as VDPU121 in TRM of RK3588 which > is capable to decode MPEG2/H.264/VP8 up to 1920x1088. This vpu ip is also > found in RK3568. The only concern I have is that we rejected enabling this VPU on RK3399, since having two H.264 decoders was confusing userspace softwares at the time, causing the slow one to be picked sometimes. I know the selection is not fully implemented in GStreamer either, not sure for LibreELEC ffmpeg fork, Chromium or Cros-codec. Of course, its not a problem now, but only when someone provides an rkvdec2 driver that enables the much more capable HW decoder. Shall we hold on H.264 mainline for now ? Nicolas > > Test results from fluster can be found from thread of v2[1][2]. > > [1] https://lore.kernel.org/all/CAAXNxMT3f68-ptM7Crhrfmn7iwTyJc9pwz4Beob+5beVODaSHQ@mail.gmail.com > [2] https://lore.kernel.org/all/20231230153159.3748580-1-liujianfeng1994@gmail.com > > > Changes in v3: > - Drop code in hantro_drv.c because hantro g1 vpu in rk3588 is compatible > with the one in rk3568, only adding devicetree node should work. > - Change devicetree node name to video-codec@fdb50000 to match the reg > address. > - Add dt-bindings rockchip,rk3588-vpu compatible with rockchip,rk3568-vpu > - Link to v2: https://lore.kernel.org/all/20231228131617.3411561-1-liujianfeng1994@gmail.com > > Jianfeng Liu (2): > arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588 > dt-bindings: media: rockchip-vpu: Add rk3588 vpu compatible string > > .../bindings/media/rockchip-vpu.yaml | 3 +++ > arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 20 +++++++++++++++++++ > 2 files changed, 23 insertions(+) >
Hi Nicolas, Am Mittwoch, 17. Januar 2024, 20:16:24 CET schrieb Nicolas Dufresne: > Le dimanche 31 décembre 2023 à 23:11 +0800, Jianfeng Liu a écrit : > > This is the v3 version of this series adding hantro g1 video decoder > > support for rk3588. > > > > RK3588 has Hantro G1 video decoder known as VDPU121 in TRM of RK3588 which > > is capable to decode MPEG2/H.264/VP8 up to 1920x1088. This vpu ip is also > > found in RK3568. > > The only concern I have is that we rejected enabling this VPU on RK3399, since > having two H.264 decoders was confusing userspace softwares at the time, causing > the slow one to be picked sometimes. I know the selection is not fully > implemented in GStreamer either, not sure for LibreELEC ffmpeg fork, Chromium or > Cros-codec. > > Of course, its not a problem now, but only when someone provides an rkvdec2 > driver that enables the much more capable HW decoder. Shall we hold on H.264 > mainline for now ? hmm, reading the TRM the VDPU121 claims to support: - VP8 - VC1 - MPEG-1,2,4 - H.263 - JPEG So at least the TRM doesn't list h.264 as supported at all on VDPU121 . Not sure what is up with that or is Rockchip also just suggesting that h.264 should be in the VDPU381 [where h.264 is listed as featured] ? Heiko
Hi Nicolas, Wed, 17 Jan 2024 14:16:24 -0500, Nicolas Dufresne wrote: >The only concern I have is that we rejected enabling this VPU on RK3399, since >having two H.264 decoders was confusing userspace softwares at the time, causing >the slow one to be picked sometimes. I know the selection is not fully >implemented in GStreamer either, not sure for LibreELEC ffmpeg fork, Chromium or >Cros-codec. Only H264 decoder is disabled for RK3399 in driver code, and RK3399 does have this VPU node in devicetree to support other codecs like MPEG or VP8. >Of course, its not a problem now, but only when someone provides an rkvdec2 >driver that enables the much more capable HW decoder. Shall we hold on H.264 >mainline for now ? RK356x also has the same situation. That is why this patch shares the same compatible string with RK356X. Before rkvdec2 launching mainline, this hantro g1 vpu is the only H264 decoder to use on these socs. We can keep H.264 enabled, and disable it for RK356x and RK3588 just like what we did to RK3399 when rkvdec2 launches. Jianfeng
> Wiadomość napisana przez amazingfate <liujianfeng1994@gmail.com> w dniu 18.01.2024, o godz. 12:30: > > Before rkvdec2 launching mainline Ooooo - is there concrete plan for this? Asking as imho rk35xx can be really nice multimedia soc. Can be…. but is not due current lack of hevc/vp9 hw decode in mainline due lack of rkvdec2 support This seems to be clear blocker for many multimedia use cases :-( Having rkvdec2 support via v4l2_request in mainline imho will make rk35xx killer soc for multimedia…. ps: rkvdec support seems available since years on mainline and works well. So maybe rkvdec code base can be basis to gradually added support for rkvdec2?
Le jeudi 18 janvier 2024 à 14:53 +0100, Piotr Oniszczuk a écrit : > > Wiadomość napisana przez amazingfate <liujianfeng1994@gmail.com> w dniu 18.01.2024, o godz. 12:30: > > > > Before rkvdec2 launching mainline > > Ooooo - is there concrete plan for this? > > Asking as imho rk35xx can be really nice multimedia soc. > > Can be…. but is not due current lack of hevc/vp9 hw decode in mainline due lack of rkvdec2 support > This seems to be clear blocker for many multimedia use cases :-( > > Having rkvdec2 support via v4l2_request in mainline imho will make rk35xx killer soc for multimedia…. > > ps: rkvdec support seems available since years on mainline and works well. > So maybe rkvdec code base can be basis to gradually added support for rkvdec2? > You'd be surprised that we are still upstreaming HEVC/10bit and 4:2:2 support (well Jonas is) and are missing a proper solution to some needed HW reset logic (to fix concurrent decoding). Though all these exist in some form in LibreELEC patchset. When this is behind, Jonas reported that he might be interested in looking into rkvdec2. Consider that his is volunteer work, but it would indeed be amazing. The HW work blob free (no firmware needed) supports up to 8K (rk3588). Some early work on adding encoder interface for this type of HW is also in progress. The AV1 decoder for rk3588 (which is a chip from Verisillicon, not RK) is already upstream. regards, Nicolas