Hello Ezequiel Sent from my iPad > On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote: > >> On Sun, 6 Jan 2019 at 13:16, Ayaka <ayaka@xxxxxxxxxxx> wrote: >> >> >> >> Sent from my iPad >> >>> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> wrote: >>> >>> On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote: >>>>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> 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? > For rk3328, yes, you see I didn’t draw them in the same box. > 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". No, you can’t assume which one is in the combo group, it can be various. you see, in the rk3328, the vdpu is paired with an avs+ decoder. That is why I use a virtual device standing for scheduler. > > Thanks for the input! > -- > Ezequiel García, VanguardiaSur > www.vanguardiasur.com.ar
