[Libva] How to implement a EGL or DRM display in VA-API driver

[Zhao Yakui]

On 11/11/2016 12:27 PM, Randy Li wrote:
>
>
> On 11/11/2016 12:31 PM, Zhao Yakui wrote:
>> On 11/11/2016 12:02 PM, Randy Li wrote:
>>>
>>>
>>> On 11/11/2016 11:45 AM, Xiang, Haihao wrote:
>>>> On Wed, 2016-11-02 at 19:32 +0800, Randy Li wrote:
>>>>>
>>>>> On 10/29/2016 04:09 AM, Sean V Kelley wrote:
>>>>>>
>>>>>> On Fri, 2016-10-28 at 10:05 +0800, Randy Li wrote:
>>>>>>>
>>>>>>> On 10/27/2016 11:03 PM, Xiang, Haihao wrote:
>>>>>>>>> gstreamer, and I have
>>>>>>>>> no idea about where should I implement something functions
>>>>>>>>> like
>>>>>>>>> eglExportDRMImageMESA().
>>>>>>>>
>>>>>>>> VADriverVTableEGL is deprecated in libva, we has a more
>>>>>>>> efficient
>>>>>>>> way to use vaapi and egl.
>>>>>>>> You can refer to the examples in libyami-utils (https://github.
>>>>>>>> com/
>>>>>>>> 01org/libyami-utils.git) for
>>>>>>>> how to use vaapi and egl.
>>>>>>>
>>>>>>> I see, thank you.
>>>>> I looks like the currently VA-API only need vaDeriveImage() and
>>>>> vaAcquireBufferHandle(), leaving the rendering output buffer to
>>>>> display
>>>>> to VA-API client. vaapisink from gstreamer would play no role in
>>>>> this?
>>>>>>>>
>>>>>>>>> The DRM seems more complex, the reason I want to use the
>>>>>>>>> DRM is
>>>>>>>>> that,
>>>>>>>>> GPU would not work with the 4K video rendering, so the DRM
>>>>>>>>> means
>>>>>>>>> that
>>>>> The guys from algorithm department told me that the main problem is
>>>>> VA-API can't process video parallelly and it won't process the next
>>>>> frame until vaEndPicture() and a output function(like
>>>>> vaDeriveImage(),
>>>>> vaGetImage and vaPutSurface()).
>>>>
>>>>
>>>> What do you mean when you said 'VA-API' can't process video parallelly
>>>> ? The examples/grid.cpp can processes multiple videoes parallelly.
>>> If I understand the process sequence correctly, the next frame won't be
>>> processed at vaBeginPicture() until the previous frame is end with
>>> vaEndPicture()?
>>> What I mean is about frame.
>>
>> Yes. Before calling the vaEndPicture, we can't handle next frame.
>> Only after calling vaBeginPicture, a new frame is started.
>> The decoding process can be considered as state-machine.
>>> The first step is to call vaBeginPicture
>>> Call vaRenderPicture to prepare required parameter
>>> call vaEndPicture
>>
>> If a new frame can be started before calling vaEndPicture, the decoding
>> process will be in corruption state. That is wrong.
> Yes, I know that. But our video IP is not as power as Intel's, I need to
> render the next frame into queue of v4l2. Also I need to reconstruct the
> frame to extract some codec information that VA-API don't offer to me,
> it would cost some extra time.
>
> I think the decoder in VA-API had better introduce a sync mechanism like
> encoder.

The vaEndPicture is not a blocked API call. In such case it will return 
after it tells the driver that all the required info is ready and the 
decode command can be submitted to the HW.  Then a new frame can be 
prepared.

If you need the sync, you can call the explicit sync operation to wait 
for the completion of decoding.

Thanks
   yakui

>>
>>>>
>>>>>>>>> directly output the video into video controller in our
>>>>>>>>> platform.
>>>>>>>>> But still have no
>>>>>>>>> idea what kind of thing I should implement in the VA-API
>>>>>>>>> driver.
>>>>>>>>> It seems that
>>>>>>>>> the VA-API base library would open a DRM instance for the
>>>>>>>>> driver,
>>>>>>>>> but leaving
>>>>>>>>> those configure for connector, encoder, planes to VA-API
>>>>>>>>> driver?
>>>>>>>
>>>>>>> About the DRM, I have implemented a version which pretends a X
>>>>>>> output, I
>>>>>>> would like to know a better way.
>>>>>>
>>>>>> Connector properties and their configuration are entirely display
>>>>>> port
>>>>>> oriented. "Pretending an X output" is independent of KMS
>>>>>> configuration
>>>>>> for your display port.
>>>>> No, what I do is pretended as a VA_DISPLAY_X11 display. I have read
>>>>> the
>>>>> examples/grid.cpp from libyami-utils. It seems that those job have
>>>>> been
>>>>> moved into VA-API client. The whole display system looks like
>>>>> departured.
>>>>> So the element plugin vaapisink from gstreamer would be drop in the
>>>>> future? As those job have been done by kmssink and glimagesink.
>>>>>>
>>>>>> Sean
>>>>>>
>>>>>>>>
>>>>>>>> configure for connector, encoder, planes aren't a part of va-
>>>>>>>> api
>>>>>>>> driver. You should check libdrm and drm/i915.
>>>>>>>> You can refer to the test case of modetest in libdrm
>>>>>>>> (git.freedesktop.org/git/mesa/drm)
>>>
>>
>>
>