Re: Chromium acceleration

[Gary Thomas <gary@mlbassoc.com>]

On 2014-04-02 04:21, Carlos Rafael Giani wrote:
> 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.

Are these patches available somewhere?

>> 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

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------