[meta-freescale] Chromium acceleration

[Carlos Rafael Giani]

On 2014-03-20 14:46, Christian Betz wrote:
>
>     As for the decoder itself: I implemented it in the Chromium media
>     framework, in media/ . I simply took the vpx decoder code, copied
>     it, and modified it to use the VPU. I had VP8, MPEG2, MPEG4, and
>     h264 decoding working. It wasnt much code, but unfortunately, the
>     interfaces tend to change between versions, so the code would have
>     to be updated for the newest Chromium version. It is not much
>     code, I will try to clean it up a bit and post it. In addition, I
>     will ask the colleagues for the other patches for accelerating the
>     2D and WebGL rendering.
>
>
> thanks carlos!
>
> my analysis suggested that my team should reproduce these chunks of 
> code which are for samsung exynos:
>
> https://chromium.googlesource.com/chromium/src/+/a361fce28da709ea872062f30fb4b65fcc37b695/content/common/gpu/media/exynos_video_decode_accelerator.cc
>
> to oversimplify greatly: we want to port 
> 'exynos_video_decode_accelerator' to a new 
> 'imx_video_decode_accelerator'. in this module we would make use of 
> the same direct texture techniques as eglvivsink from gstreamer-imx.
>
> this is definitely not the route you have taken, from what I can tell. 
> is this something you considered and steered away from? have you 
> examined these code paths at all? there are a few other special 
> modules besides exynos too.
>
> i might be wrong, but it could be the best chance of getting something 
> upstreamed would be do it "like everyone else" (i.e. samsung). but i'm 
> probably thinking *way* too far ahead here.

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() ).


Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140321/7b479691/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Fix-issue-with-component-linking.patch
Type: text/x-patch
Size: 796 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140321/7b479691/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Modified-gl.gyp-to-link-libEGL-and-libGAL-at-build-t.patch
Type: text/x-patch
Size: 617 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140321/7b479691/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Added-hardware-accelerated-decoding-with-the-i.MX-VP.patch
Type: text/x-patch
Size: 27922 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140321/7b479691/attachment-0005.bin>