From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ptmx.org (ptmx.org [178.63.28.110]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 13F45E00BAB for ; Wed, 2 Apr 2014 03:21:10 -0700 (PDT) Received: from [10.1.14.248] (unknown [91.114.0.140]) by ptmx.org (Postfix) with ESMTPSA id E8B66297C3; Wed, 2 Apr 2014 12:21:08 +0200 (CEST) Message-ID: <533BE494.8000809@pseudoterminal.org> Date: Wed, 02 Apr 2014 12:21:08 +0200 From: Carlos Rafael Giani User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Nelson , Christian Betz , "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> In-Reply-To: <533B11E6.5040103@boundarydevices.com> 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:21:13 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. > > 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 >