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