[RFC PATCH 0/3] media: rockchip: VEPU510 H.264 encoder for RK3576

[Paul Kocialkowski]

Hi Nicolas,

Le Thu 23 Jul 26, 15:39, Nicolas Dufresne a écrit :
> Hi Paul.
> 
> Le jeudi 23 juillet 2026 à 20:41 +0200, Paul Kocialkowski a écrit :
> > In my opinion it would be fine to have two drivers, but it's really up
> > to you. Since you already have a v4l2 base for it, I would encourage you
> > to move it to my proposal, which will probably be finalized in a shorter
> > time frame than the other proposal and lets you reuse the code you've
> > already written. Then you could also add RK3576 support to the drm-ish
> > Vulkan Video proposal without too much work when it is ready, reusing the
> > RK3588 work.
> 
> My main concern is that once you exposed an API, the transition path is near
> impossible unless you accept to support both APIs concurrently. So I may raise a
> slight objection on the above proposal.

Well there could be a recommended implementation using your design and a
more experimental v4l2 implementation that is discouraged to use but
still available.

But that means another driver to maintain and more long-term involvement
from Jiaxing Hu. I am not sure it is worth it, but I don't think we
should entirely close the door on the idea. I also understand that there
can be a bit of frustration with trashing code and a desire to continue
working on it (especially now that it can benefit from the technical
knowledge acquired from your work). But I'm just speculating here.

Still I would be interested to eventually be able to compare performance
between the two approaches on the same hardware :)

> Once we have the code shared (Detlev is
> working on it), you'll see that Detlev (and Daniel Almeida) implementation is
> just a step ahead, and adding RK3576 to an RK3588 is just a minor update (its
> the same chip, different minor version). On top of which, once the kernel driver
> will have settled, adding more codecs will mostly (or entirely) happen in
> userspace.
> 
> With no offense, the RFC here requires significant work before it can be
> upstreamed. A lot of the code is hex tables generated from inspecting a running
> driver. So there is a lot of work to decipher this into clean code.

Yes I'm sure there is still a lot of work to do.

All the best,

Paul

> On that aspect, if you are missing any reference code or technical
> documentation, let us know, though I believe most of this is public information
> for this chip.
> 
> regards,
> Nicolas



-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20260723/bddca9e0/attachment-0001.sig>