[meta-freescale] Chromium acceleration

[Carlos Rafael Giani]

Keep in mind what I wrote. This version of VPU acceleration is very 
basic (it will copy frames with the CPU), and fulfilled the customer's 
immediate needs back then, but can be done much better. I am currently 
looking into a better approach.

On 2014-04-01 21:22, Eric Nelson wrote:
> 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
>