[meta-freescale] Chromium acceleration

[Eric Nelson]

Thanks again Carlos,

On 03/20/2014 04:19 PM, Carlos Rafael Giani wrote:
 >
 > <snip>
>
> Back then we needed some hw decoding quickly, so we did not look further
> into this, since we had spent a lot of time getting the 2D acceleration
> stable already. I could only briefly look at the exynos accelerator
> code, but it does look like the right direction, although the VPU uses
> physical addresses directly instead of dmabuf FDs. I am currently
> writing a frontend for the libfslvpuwrap, which takes care of certain
> complexities (like being able to pass userdata pointers to frames, to
> make it possible to associate input and output frames, which is
> essential for correct timestamping, especially when things like h264
> frame reordering are active). This frontend will hide these things in a
> future gstreamer-imx release to make the decoder code clearer and easier
> to maintain, and is intended to be reusable, for example for Chromium
> integration, or XBMC. Beyond that, my patches are probably not that
> helpful anymore, since they were based on the vpx decoder way of
> decoding, and I agree that the exynos code is a better starting point.
> Nevertheless, I attached the patch. Keep in mind that it is very basic,
> old, and wasn't further developed on because it was "good enough" for
> the project.
>
> But here are some additional notes from our efforts to accelerate
> Chromium on imx6 (keep in mind these apply to version 32.0.1664.3 ) :
>
> 1. We started the google-chrome binary with these switches:
> --ignore-gpu-blacklist --enable-gpu --use-gl=egl
> --enable-accelerated-2d-canvas
>
> 2. To make building Chromium easier, we switched to component build (by
> default, it is all linked into one enormous binary). I attached a patch
> that was necessary to fix some minor issues. Perhaps it is not necessary
> anymore.
>
> 3. Chromium tried to load libEGL with dlopen() , which caused problems,
> because with the Vivante libraries, libEGL also needs libGAL. Usually,
> build scripts just add -lEGL -lGAL to the linker line. With dlopen()
> this wasn't possible of course. We patched the gyp scripts to link
> against this libraries during building instead. I attached this patch.
> It is really a hack, because it circumvents the sandboxing process (this
> is why Chromium loads EGL and GLESv2 with dlopen() ).
>

Mahyar updated these patches to apply against the chromium-35.0.1883.0
build currently in meta-browser.

Additional notes to follow, but this appears to achieve HTML5 video
against Webm/Ogg videos when chromium is started with these command
line arguments:
	 --ignore-gpu-blacklist --enable-gpu --usegl-egl

Regards,


Eric

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Modified-gl.gyp-to-link-libEGL-and-libGAL-at-build-t.patch
Type: text/x-diff
Size: 996 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140401/6024a274/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Added-hardware-accelerated-decoding-with-the-i.MX-VP.patch
Type: text/x-diff
Size: 28818 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140401/6024a274/attachment-0004.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Update-vpu_video_decoder.cc-to-match-chromium-35.0.1883.patch
Type: text/x-diff
Size: 1770 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140401/6024a274/attachment-0005.patch>