Allocation Constraints

[Randy Li]

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