On 08/24/2016 11:35 PM, Xiang, Haihao wrote:
-----Original Message-----
From: Randy Li [mailto:randy.li@xxxxxxxxxxxxxx]
Sent: Wednesday, August 24, 2016 6:30 PM
To: Xiang, Haihao <haihao.xiang@xxxxxxxxx>; libva@xxxxxxxxxxxxxxxxxxxxx
Cc: nicolas.dufresne@xxxxxxxxxxxxxxx; Balachandran, Sreerenj
<sreerenj.balachandran@xxxxxxxxx>
Subject: Re: I want to use VA-API to support new platform, I want know
something about Intel implementation
On 08/18/2016 10:31 AM, Xiang, Haihao wrote:
Hi Randy,
You can get lots of information / docs via internet. You may search for
dri, libdrm, drm, gem, i915 etc.
dri wiki
https://dri.freedesktop.org/wiki/
drm:
https://en.wikipedia.org/wiki/Direct_Rendering_Manager
libdrm:
https://01.org/linuxgraphics/community/libdrm
intel graphics kernel
https://01.org/linuxgraphics/community/kernel
I have read the documents you offered to me, I have a basic view of them
and the relationship of them.
But I want to know more about the detail of Intel implementation.I have
read the Intel driver of VA-API before, I think the Intel video process
video in this way.
1. Allocate the DRI buffer from the kernel driver using the libdrm.
It is a GEM buffer object in intel driver.
2. Intel DRM driver in kernel would allocate buffer throught the GEM.
3. Intel VA-API driver push the codec data and parameters to those buffers
And setup the corresponding pipeline in a batch buffer which is also a gem buffer object and submit this batch buffer
to i915 driver via libdrm. The batch buffer will be chained into a ring buffer via MI_BATCH_BUFFER_START command
for execution.
It seems that it is only used by MFC(video encoder)?
I saw the MFD use MFX_IND_OBJ_BASE_ADDR_STATE followed with the
OUT_BCS_RELOC which would render the slice data into MFD?
You can refer to
https://01.org/linuxgraphics/documentation/hardware-specification-prms
(Programmer's
Reference Manuals) for how do ring buffer and batch buffer work.
Intel implementation is really really complex to me.
But After a quick read and read volume 8 deeply, I know that the MFX
doesn't based on register at all. So you need to push and MFC codec
commands and those decoding information to VCS, the VCS would decide and
parse how to execute those data. Is that right?
Our rockchip would still use the registers on a video IP to store the
decoder settings for the picture to be process, we may not choose the
same implementation, but I could still map the register
range to the memory, using a buffer to set them at the same time.
Anyway, that explains why I didn't see any register about video codec
in Linux kernel DRM driver, becuase Intel MFX is not based on it. The
Intel driver at kernel just need the allocate and manage the buffer for
the VCS, then most of work could be move to libdrm and VA-API driver.
That is really great for stateless video processor.
4. Got result from DRI buffer.
Is it correct ?
If it is correct, does it mean that the registers(used for configure
decoding parameters) at Intel video processing unit would be mapped as
PRIME buffers to be used in DRI?
And where is the kernel driver do that ? I know it is easy to find the
DRM driver in linux kernel in drivers/gpu/drm/i915/ , but which file is
doing the job for video processing part? They looks like the graphics
to me. I think different Intel platform generation would have a
different registers.
Hope it can help you.
Thanks
Haihao
Hi all
I am using VA-API to support the Video Process Unit in a ARM
platform, but it didn't use the standard kernel interface. Without
the
help of DRI, I can't implement something like vaDeriveImage() leading
a lose in performance.
I read the Intel driver, it looks the Intel driver could access
the
the Memory of Video Unit of Intel Graphics card through the libdrm.
If that is right, could somebody told me how does it implemented in
linux kernel(which files?).
And I am really newbies to this area(DRI), could somebody give me
guide and documents about this?
Thank you all very much.
Thank you so much.
--
Randy Li
The third produce department
Thank you for help, it is really a great work what Intel have done.
--
Randy Li
The third produce department
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
