video: Add support for linear 8x128 NV12 tiles and 10bit BE tiles

This adds linear 8x128 NV12 based tiles and NV12 10bit big endian tiles. These formats are used by i.MX 8QXP/8QM VPU and exposed in V4L2.

Signed-off-by: Ming Qian ming.qian@nxp.com

marked this merge request as draft

marked this merge request as ready

The format says that tiles are 8x128, why do we need the width to be multiple of 256 rather then 8 ?

Yes, I got it, actually the alignment of 256 is limitation of imx8q, not the format. I'll make the change.

changed this line in version 2 of the diff

Except for weird pattern line Samsung 64Z32, the software implementation does not need to reflect the HW requirement, cause anyway, the driver will never use any sysmem from the converter.

Yes, you are right, it's my mistake, I have fixed it.

Some more note, need to drop the Signed-of-by in the commit, as it's not use in this project. And you should add proper reference for the format, V4L2 doc if it exists yet, or IMX manual refernence, these can be publicly obtained in exchange of an name and email.

(references are needed for me to complete the code review, as I don't have anything to compare against, strict explanation of the format in the commit message would be needed otherwise)

added 1 commit

• 551fb122 - video: Add support for linear 8x128 NV12 tiles and 10bit BE tiles

Compare with previous version

added 1 commit

• e86f47e7 - video: Add support for linear 8x128 NV12 tiles and 10bit BE tiles

Compare with previous version

Can you extend on this format ? Other tiling format here are expressing in bytes, as the tiling is related to DMA transfer (so chunk size) rather then pixels. So I'm just guessing the tiles are still 1kB, what I'm missing is how the 10bit is padded.

In Microsoft style, P010, 6ytes per pixel would be used, so you'd have 4 pixels per tile rows. In RK variant, they would fully pack the data, 4 pixels per 40bit, but 8bytes would not work, it's not a multiple of 40bits/5bytes. In Xilinx variant, you'd place 3 pixels per 32bit, with 2bit padding, that would hold for 6 pixels. That's the type of info we are looking for.

Yes, you are right, for this 10 bit format, 4 pixels will take 5 bytes. and the tile width is 8 bytes. it not enough for 8 pixels. so for some pixel, the high bits and the low bits may in different tiles. For example, the high 4 bits of the 7th pixel is in the first tile, and the low 6bits of the 7th pixel is in the second tile. This is why the pack and unpack function of 10 bits tile format is not same as the 8 bit format, that I can't use PACK_NV12_TILED directly

and I will attach the references document tomorrow, maybe it explains more clearly

Thanks a lot, and the overlap between tiles is important, I'll review the stride calculation accordingly. I'll try and review the pack/unpack code now that I actually understand that 10bit variant.

VPU_memory_tiling_v0.3.06082015.pdf

the document of the tiling format is attached.

added Base Plugins labels

added 37 commits

• e86f47e7...ce937bcb - 36 commits from branch gstreamer:master
• 528d0fab - video: Add support for linear 8x128 NV12 tiles and 10bit BE tiles

Compare with previous version

mentioned in merge request gstreamer!1379 (merged)

Moved to gstreamer!1379 (merged) (mono repo).

closed