I studied video_dec_drm example.
It uses 3 planes (3 is the maximum supported value according to drm_renderer->getPlaneCount()).
Does drm utilizes VIC (VIDEO IMAGE COMPOSITOR) or some other hardware module?
If yes, then why drm is limited to just 3 planes while VIC on TX1 supposed to support 8 slots?
I need to show 4 images on 4 separate planes.
What API I should use?
( I am running TX1 24.2.1 )
VIC is NvVideoConverter which does format conversion, not rendering. You probably misunderstand this.
NVDrmRenderr utilizes LibDRM to use display controller. Max 3 is the limitation.
VIC is NvVideoConverter which does format conversion, not rendering
TX1 TRM says that VIC VIC is a compositor, that it performs “compositing for up to 8 input surfaces”.
Also “The VIC supports up to 8 different input pictures that can be composited on to a single surface.”
This is exactly what I need: composit 4 images on one screen.
Which API I should use to achieve that?
If LibDRM does not use VIC, then what other hardware it does use?
I can see that video_dec_drm places 3 planes on top of each other.
I hope that it used some hardware, not software, to perform the composition, does it?
I did some more research and see strange thing:
There is a VIC DRM driver in the main Linux source tree:
This code is there since 2015 or 2016.
but it is not in NVIDIA’s kernel for TX1:
So, it looks like I was right - VIC is meant to be accessible through DRM,
but that support somehow disappeared.
So, please, answer my original question - what API I should use to utilize VIC’s ability to compose multiple images.
DRM means Direct Rendering Manager in my comment. Hardware VIC engine does not do this.
VIC can do frame composite. We have the API NvBufferComposite() in r28.2.
* This method is used to composite multiple input DMA buffers to one output DMA buffer. * It can support composition of multiple input frames to one composited output. * @param[in] src_dmabuf_fds array of DMABUF FDs of source buffers to composite from * @param[in] dst_dmabuf_fd DMABUF FD of destination buffer for composition * @param[in] composite_params composition parameters * * @return 0 for sucess, -1 for failure. */ int NvBufferComposite (int *src_dmabuf_fds, int dst_dmabuf_fd, NvBufferCompositeParams *composite_params);
Thank you, I will study NvBufferComposite later.
However, I still want to better understand DRM.
It does provide planes and I thought that those planes should be implemented by hardware compositor, such as VIC.
If not, how are these planes implemented? I hope this is not done by software compositor - that would be too slow.
When I run video_dec_drm example, it shows 3 overlayed planes - how does it work?
Second question is about that VIC module for DRM that I found:
What is is supposed to do?
It is a DRM module and it accesses VIC.
What was its functionality?
Why it is missing from current TX1 software?
For DRM, please check https://www.systutorials.com/docs/linux/man/7-drm/
NvDrmRenderer class is implemented in public LibDRM APIs.
We now have userspace SW stacks to use VIC.
tegra_multimedia_api: NvBuffer APIs, NvVideoConverter.
The kernel code is simply to load firmware. It might not be appropriate to put it under gpu/drm/tegra/