On Sun, 6 Jan 2019 at 13:16, Ayaka <ay...@soulik.info> wrote: > > > > Sent from my iPad > > > On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia <ezequ...@collabora.com> wrote: > > > > On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote: > >>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia <ezequ...@collabora.com> > >>> wrote: > >>> > >>> Hi Randy, > >>> > >>> Thanks a lot for this patches. They are really useful > >>> to provide more insight into the VPU hardware. > >>> > >>> This change will make the vpu encoder and vpu decoder > >>> completely independent, can they really work in parallel? > >> As I said it depends on the platform, but with this patch, the user space > >> would think they can work at the same time. > > > > > > I think there is some confusion. > > > > The devicetree is one thing: it is a hardware representation, > > a way to describe the hardware, for the kernel/bootloader to > > parse. > > > > The userspace view will depend on the driver implementation. > > > > The current devicetree and driver (without your patches), > > model the VPU as a single piece of hardware, exposing a decoder > > and an encoder. > > > > The V4L driver will then create two video devices, i.e. /dev/videoX > > and /dev/videoY. So userspace sees an independent view of the > > devices. > > > I knew that, the problem is that the driver should not always create a > decoder and encoder pair, they may not exist at some platforms, even some > platforms doesn’t have a encoder. You may have a look on the rk3328 I post on > the first email as example.
That is correct. But that still doesn't tackle my question: is the hardware able to run a decoding and an encoding job in parallel? If not, then it's wrong to describe them as independent entities. > > However, they are internally connected, and thus we can > > easily avoid two jobs running in parallel. > > > That is what the mpp service did in my patches, handing the relationship > between each devices. And it is not a easy work, maybe a 4k decoder would be > blocked by another high frame rate encoding work or another decoder session. > The vendor kernel have more worry about this, but not in this version. Right. That is one way to design it. Another way is having a single devicetree node for the VPU encoder/decoder "complex". Thanks for the input! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar
