On 3/12/19 4:22 PM, Tomasz Figa wrote:
On Thu, Feb 28, 2019 at 12:13 AM Ayaka <ayaka@xxxxxxxxxxx> wrote:
Hello all
I am writing the v4l2 decoder driver for rockchip. Although I hear the suggest from the Hans before, it is ok for decoder to use single plane buffer format, but I still decide to the multi planes format.
There is not a register for vdpau1 and vdpau2 setting the chroma starting address in both pixel image output(it has one only applied for jpeg) and reference. And the second plane should follow the first plane. It sounds pretty fix for the single plane, but the single plane can’t describe offset of the second plane, which is not the result of bytes per line multiples the height.
There are two different memory access steps in those rockchip device, 16bytes for vdpau1 and vdpau2, 64bytes for rkvdec and 128bytes for rkvdec with a high resolution. Although those access steps can be adjusted by the memory cache registers. So it is hard to describe the pixel format with the single plane formats or userspace would need to do more work.
Why not just adjust the bytes per line to a multiple of 16/64/128
bytes? Most of the platforms allocate buffers this way for performance
reasons anyway.
I can't, it depends on the device design. Also I need extra empty
line(128/256 bytes) in each lines for the rkvdec. Maybe the device for
chrome only request an alignment with 16 bytes per line and at vertical
line, it is ok for the H.264 under the 1920x1080 resolution, but above
that resolution would suffer a poor performance as well UHD.
I made a mistake in the previous mail, the current suggest alignment for
rkvdec is 256 bytes and plus an extra line.
Also it requests a different alignment way for those chroma subsample
are not 4:2:0. And it is not easy to align with a width value while its
bitdepth is large than 8 bits.
Currently, I use the dma-contig allocator in my driver, it would allocate the second plane first, which results that the second plane has a lower address than first plane, which device would request the second plane follows the first plane. I increase the sizeimage of the first plane to solve this problem now and let device can continue to run, but I need a way to solve this problem.
Is there a way to control how does dma-contig allocate a buffer? I have not figured out the internal flow of the videobuf2. I know how to allocate two planes in different memory region which the s5p-mfc does with two alloc_devs, but that is not what I want.
Last time in FOSDEM, kwiboo and I talk some problems of the request API and stateless decoder, I say the a method to describe a buffer with many offsets as the buffer meta data would solve the most of problems we talked, but I have no idea on how to implement it. And I think a buffer meta describing a buffer with many offsets would solve this problem as well.
Sent from my iPad
P.S. Please fix your email client to properly wrap the lines around
the ~75 column line.
Blame the thuderbird.
Best regards,
Tomasz
