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
--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
