Allocation Constraints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux