Introduce vaLockBuffer & vaUnlockBuffer APIs in libva.

[shaochangbin]

Reason that add this change:
1080p video playback on Tizen is quite unsmooth on VTC-1010, with only 15 render
fps and ~70% CPU usage. Ozone-wl landed a workaround solution that enables a
zero buffer copy method that uses libva vaLockBuffer APIs which gains much better
performance than previous method.
intel/ozone-wayland#260

In order to make the change also benifit Crosswalk/Tizen, we should add the
vaLockBuffer API declarations inside Chromium Crosswalk to compile
the code successfully.

The long term goal of our work would be landing those API declarations inside
Chromium upstream, after the API implementations are landed in libva and
libva-driver upstream.

Therefore, this CL is a temporary solution. It would be reverted after the long
term goal is achived.

[crosswalk-trybot]

Testing patch series with shaochangbin/chromium-crosswalk@dec0dea as its head.

Bot	Status
Content Shell Linux	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Linux/builds/106)
Content Shell Android-x86	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Android-x86/builds/105)

[shaochangbin]

Please have a look, thanks!
@darktears @kenchris @tiagovignatti

[crosswalk-trybot]

Testing patch series with shaochangbin/chromium-crosswalk@2317739 as its head.

Bot	Status
Content Shell Linux	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Linux/builds/107)
Content Shell Android-x86	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Android-x86/builds/106)

[rakuco]

I've just cloned libva from freedesktop.org and master doesn't contain these changes either. I'm rather uncomfortable with having to carry these changes forever on our side.

[shaochangbin]

There are APIs named vaAcquireBufferHandle and vaReleaseBufferHandle in libva 'staging' branch in freedesktop.org, which are newer version of the vaLockBuffer & vaUnlockBuffer. vaAcquireBufferHandle APIs will be merged in master branch after some time if there is no report issues over them.
For Tizen IVI, the libva is picked from libva upstream 'staging' branch, but is a bit old and at the moment it hasn't been updated for some time. we can find the vaLockBuffer patches from IVI libva rpm.
As for Chromium libva upstream, I am not clear how often they update the repo, but i guess they will only update it when there is need to do this.

To sum up, IMHO it requires time to make vaAcquireBufferHandle APIs landed in Chromium libva upstream, we can use vaLockBuffer as temporary option atm. wdyt?

[rakuco]

I think Chromium updates its libva checkout as needed, and they probably wouldn't object if you helped with that -- for example, libva 1.2.1 was released in the end of June last year and made it to Chromium in November; on the other hand, 1.3.1 was released this May and Chromium updated its copy in June.

In any case, I've got a few additional questions based on your explanation:

• Do you know when the libva team intends to release a new version that includes this new API?
• What if you add vaAcquireBufferHandle and vaReleaseBufferHandle instead? Does that mean it won't work with IVI? If that's the case, isn't that bound to cause problems in a way or another once a newer libva is released with the new symbols?
• Does this approach cause any problems if one has a normal libva installed, like undefined symbol errors when the stubs are resolved?

[shaochangbin]

@rakuco thanks for your suggestion!
My concern is it may requires quite a long time to make the new APIs merged in Chromium upstream. We firstly need to push to land it in libva upstream, then help to make it ready in chromium upsream.

For Q1, actually I've know idea when they will include new APIs in master branch. Think libva owners can give us more information.
Q2, as my knowledge, IVI libva is out of maintenance at the moment and it doesn't support the new APIs. So the old APIs works fine for IVI. If we want to add the new APIs, then should find someone to maintain/update the libva rpms.
Q3, it has no problem for IVI platform, due to libva isn't maintained. If there are case that uses the vaLockBuffer or vaAcquireBufferHandle APIs but only has a normal libva installed, then there is problem.

[tiagovignatti]

hi @gbeauchesne, hi @halleyzhao. Any idea about when can we get these new API in libva?

[gbeauchesne]

Hi,

The API is available in libva "staging" branch. The associated VA driver support patch is still available in the libva mailing list. I will push it to the "staging" branch by the end of this week.

Now, the next steps are to get the changes merged back to "master" and get a release of it. For that to happen, I would appreciate compelling examples of usages. Chromium could be one. Likewise for the pending Mesa changes. It should not be hard to get in, but I first want to be sure that the APIs and implementations are going to work and match user expectations. Chromium is one.

Are you satisified with those APIs? Does this match your expectations?

Thanks,
Gwenole.

[shaochangbin]

Hi, @gbeauchesne thanks a lot for your reply.
From my perspective, i would say it's a very impressive change and willing to see this in master branch ASAP.
Btw, as for Mesa change, do you mean the VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_DRM_BO support? I'm using the VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_DRM memory type atm.

[gbeauchesne]

Hi,

2014-08-13 7:22 GMT+02:00 shaochangbin notifications@github.com:

Hi, @gbeauchesne https://github.com/gbeauchesne thanks a lot for your
reply.
From my perspective, i would say it's a very impressive change and willing
to see this in master branch ASAP.
Btw, as for Mesa change, do you mean the
VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_DRM_BO support? I'm using the
VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_DRM memory type atm.

On the Mesa side, that's support for EXT_image_dma_buf_import. Since we
don't support sampling from NV12 images yet, we still need to import each
surface plane into separate EGLImage and use a shader for color conversion
for instance. That's what my Mesa patches do. I am currently uploading my
Mesa repo to github for simpler reference from here. :)

Meanwhile, the older patches are still available here:
http://cgit.freedesktop.org/~gb/mesa/log/?h=20.EXT_image_dma_buf_import
(20.EXT_image_dma_buf_import branch)

I will also push a simple test program to show off how this is supposed to
work altogether.

[tiagovignatti]

@gbeauchesne, what happens with those new API calls when EXT_image_dma_buf_import is lacking? Thanks.

[gbeauchesne]

Hi,

2014-08-13 9:41 GMT+02:00 Tiago Vignatti notifications@github.com:

@gbeauchesne https://github.com/gbeauchesne, what happens with those
new API calls when EXT_image_dma_buf_import is lacking? Thanks.

You only need the proposed Mesa patches if you want to import planar YUV
surfaces and that the Intel 3D driver does not support
GL_OES_EGL_image_external. Meanwhile, without those Mesa patches, you would
have to convert that VA surface (internally in NV12 format) to something
that is readily supported, e.g. RGBA. You can use a VA/VPP pipeline for it.

[shaochangbin]

That's the option that we use inside Ozone-WL implementation, firstly convert the VA surface to BGRX format.

[gbeauchesne]

2014-08-13 15:21 GMT+02:00 shaochangbin notifications@github.com:

That's the option that we use inside Ozone-WL implementation, firstly
convert the VA surface to BGRX format.

OK, that's not really zero-copy then but that's fine for a general fallback
without a particular support in Mesa, and starting to exercise the APIs. :)

BTW, if you have means to get display-rect hints from the render process,
that would also be nice to lower memory bandwidth. i.e. imagine you decode
1080p30 videos but only intend to display on 720p30 screens, there are
additional savings to get here, by firstly converting to a lower size.

[crosswalk-trybot]

Testing patch series with shaochangbin/chromium-crosswalk@e06df34 as its head.

Bot	Status
Content Shell Linux	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Linux/builds/110)
Content Shell Android-x86	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Android-x86/builds/109)

[shaochangbin]

Hi, all, any review comments?
@rakuco @kalyankondapally @tiagovignatti @darktears @kenchris

[kalyankondapally]

@shaochangbin This should go into oz-wl side.

[halton]

@shaochangbin I think this is value to upstream, isn't it?

[shaochangbin]

@halton, thanks for your suggestion. It's our long term goal to upstream it in Chromium, due to the libva side change is not ready atm.

[shaochangbin]

@kalyan, my understanding is the patches/ folder under oz-wl takes effect when building oz-wl standalone. We can't remove this CL in Chromium-crosswalk, otherwise it compiles error in Crosswalk if includes intel/ozone-wayland#260.

So my conclusion is we need two copies of the CL, one in Chromium-Crosswalk for Crosswalk building;
the other one under oz-wl /patches, for oz-wl standalone building.
Please correct me if my understanding is wrong.

[kalyankondapally]

@shaochangbin That's true. For now you need this in both places.

[crosswalk-trybot]

Testing patch series with shaochangbin/chromium-crosswalk@bec472e as its head.

Bot	Status
Content Shell Linux	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Linux/builds/111)
Content Shell Android-x86	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Android-x86/builds/110)

[rakuco]

There's a long story behind this commit, so please expand your one-line commit message.

[crosswalk-trybot]

Testing patch series with shaochangbin/chromium-crosswalk@d85e4ed as its head.

Bot	Status
Content Shell Linux	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Linux/builds/112)
Content Shell Android-x86	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Content Shell Android-x86/builds/111)

[shaochangbin]

Update commit message, please review, thanks!
@rakuco

[rakuco]

Landed at last :-)

[shaochangbin]

thanks for your review:)