From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id C0306E00B3B for ; Wed, 19 Mar 2014 19:50:45 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id uo5so255407pbc.10 for ; Wed, 19 Mar 2014 19:50:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VImnBOJcPdYhqD9nz38ZWZig9vQPqnTRL5qK1hQEdB8=; b=lNt/H+KCJAPewGzQngRgV0xzolThkD0TBWNFtX2BMFuxLPyaizZstOxR8ggZlheOi1 CxvHGkVOK7R1dRdumispINbYVVq04cP9NnVj2/+i2IhBUGKX2acZjutA/y9c6zmui1I+ 6kX+dvxQ9aclIi/OapHZUvBDvcJr5SiycN8U8Pe9tTWqhIvDaodyWDK9BC4Jem56cSDa Ewv2XolitRyDOusUZa9n+CUzCzfrDY1DKceR7gpoZkyivUrgICbeRZoBpkOu7hCvN0wn P/nJX2Qb6upfIYlki9RNhy2tw4dxAtlkqed8e778sA8tBePLqoTuK0bRrPlEzwJvNfYQ zaMw== X-Gm-Message-State: ALoCoQlstTx2DvHdnSwKXoY/4TGbZQjqaKwryydGTuGVbR4bKvqx6AqIv0dX4/aZP+J/I+oMZlNW X-Received: by 10.66.147.130 with SMTP id tk2mr25967441pab.125.1395283845530; Wed, 19 Mar 2014 19:50:45 -0700 (PDT) Received: from [192.168.1.8] (ip98-167-230-131.ph.ph.cox.net. [98.167.230.131]) by mx.google.com with ESMTPSA id qx11sm2168574pab.35.2014.03.19.19.50.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 19:50:44 -0700 (PDT) Message-ID: <532A5782.4050809@boundarydevices.com> Date: Wed, 19 Mar 2014 19:50:42 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christian Betz References: <532A02E5.7060607@boundarydevices.com> <532A057E.2010805@pseudoterminal.org> <532A1CC6.1020609@boundarydevices.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" 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: Thu, 20 Mar 2014 02:50:48 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Christian, On 03/19/2014 06:29 PM, Christian Betz wrote: > The Vivante libraries can map the physical buffers produced by > the VPU directly, so they could do format conversion on their > way to the graphics stack if the Chromium bindings have access > to that (the "single copy" I referred to above). > > > in my experience "zero-copy" really means zero memcpy() (or similar > system call, or really anything that involves the cpu to move around > image data. /metadata /such as buffer pointers is generally allowed). in > other words having the GPU do format conversion isn't considered a copy. > > here's a great article on this general technique implemented in > webkit/gtk+: > http://blogs.igalia.com/vjaquez/2013/07/26/composited-video-support-in-webkitgtk/ > That's a nice article, and if Webkit (Blink) retains the same mapping, video buffers from the VPU would end up hitting a RenderObject and the only "copy" would be in rendering that to the Framebuffer. Since we're on the fat end of the pipe here, that copy can be expensive and might limit things to 1x1080P decode, but I'd be happy with that. In the mfw_v4lsink case at least, this can be bypassed by having the V4L2 buffer filled by the VPU and also displayed by the IPU (such that copy), but aiming there would keep the video out of the rest of the RenderLayer tree (I think). This is what I was so awkwardly trying to suggest. > moving beyond semantics... let me tell you what i know about this > particular issue: > > there is source code in chromium to accomplish a similar goal. > specifically there is a "generic" android driver, which works out of the > box with i.mx6 because freescale implements the standard android video > decode interface that allows VPU -> GPU texture uploading (don't quote > me on this, i'm just reading the source code: > https://chromium.googlesource.com/chromium/src/+/a361fce28da709ea872062f30fb4b65fcc37b695/content/common/gpu/media/android_video_decode_accelerator.cc) > > sadly there is no such standard interface on GNU/Linux. outside of > android (i.e. chromeos), there are drivers for particular chipsets, like > samsung exynos. here is the source for that: > https://chromium.googlesource.com/chromium/src/+/a361fce28da709ea872062f30fb4b65fcc37b695/content/common/gpu/media/exynos_video_decode_accelerator.cc > > the group should also be aware of the current situation regarding these > modules /only/ working when certain flags to enable "chromeos" are used > (explained here: > https://code.google.com/p/chromium/wiki/LinuxHWVideoDecode). in other > words: this stuff doesn't work on your x86 with the chrome you download > from google. > Again, thanks for the info. Regards, Eric