Hello emersion
Since you told me the presentation in XDC 2020, I was thinking what we
need for the video codec hardware, I don't have much experience with
the situation that presentation addressed, sharing between GPU.
I think we must cover the case with and without IOMMU attached to the
device, besides some page layout information. I would talk it later.
About the pitch(in v4l2, it is bytesperline, or stride in some
hardware), I think it would indicate three types, one is the menu(a menu
of N choices), one is integer(ranging from minimum to maximum inclusive).
The menu type could cover the most of cases with a fixed cache
line(likes 16, 64, 256 bytes alignment). While the integer type covers
those do no care about cache line, the restriction is about hardware
desired size, codec hardware could hardly meet this, usually they need
to meet the requirement of CU or MB from a codec. This also enables the
padding for vertical direction which could be regarded as the padding
bytes behinds a plane.
Still it can ___not _ describe the case happening in Rockchip vdpu34x
for HEVC and VP9, which requests an odd cache line. For example, if the
width is 256 (8bit depth) and cache line is 256 bytes as well, the pitch
would be 256 bytes, when width becomes 512, the pitch should be 768
bytes. You could learn this from Rockchip MPP rkv_hor_align*();
In study 2, Local memory, codec has the similar requirement but
difference. Is it GPU internal having different regions for 2d texture,
3d texture and shader? The non-cache or cached memory (coherence) is
also cared by codec sometimes, while the most cases the user could
decide that by whether CPU need to access that buffer.
While, the constraint need to tell its capability about whether it
supports accessing an secure buffer.
Let's back the IOMMU topic, this feature is not mandatory for the codec.
And we would like to get rid of M variant pixel formats from V4L2. For
the hardware doesn't support scatter list, it may have delegated
registers for each plane.
address type: scatter list or one address
relationship with the previous plane: compact(right after the last byte
of the previous plane), new page(plane would start in the beginning of a
page), or None(it has a delegated register)
page size: this only applied for sgl address type, hardware may need a
larger contiguous page.
To make a summary what I think we need here:
1. Alignment requirement for vertical direction
2. whether the device supports scatter list
3. what is the page size if the device would support iommu
4. plane layout in memory
Sincerely
Randy Li
