From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.chez-thomas.org (mail.mlbassoc.com [65.100.170.105]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id E2861E00BAB for ; Wed, 2 Apr 2014 03:28:41 -0700 (PDT) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id 343F4F81200; Wed, 2 Apr 2014 04:28:40 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hermes.chez-thomas.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.2 Received: from [192.168.1.114] (zeus [192.168.1.114]) by mail.chez-thomas.org (Postfix) with ESMTP id B73DAF811F8; Wed, 2 Apr 2014 04:28:38 -0600 (MDT) Message-ID: <533BE659.3050705@mlbassoc.com> Date: Wed, 02 Apr 2014 04:28:41 -0600 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: meta-freescale@yoctoproject.org References: <532A02E5.7060607@boundarydevices.com> <532A057E.2010805@pseudoterminal.org> <532A1CC6.1020609@boundarydevices.com> <532A5782.4050809@boundarydevices.com> <532AA723.1010901@pseudoterminal.org> <532B7776.5090700@pseudoterminal.org> <533B11E6.5040103@boundarydevices.com> <533BE494.8000809@pseudoterminal.org> In-Reply-To: <533BE494.8000809@pseudoterminal.org> X-Enigmail-Version: 1.5.2 Subject: Re: Chromium acceleration X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 10:28:42 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: >> > >> > >>> >>> 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 ------------------------------------------------------------