[meta-freescale] Chromium acceleration

[Christian Betz]

>
> 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/

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.

@carlos: have you implemented a module along the lines of this exynos
accelerator or did you take another route? a team member is actually about
to attack this problem next week so it'd be great to see what you have
before we reinvent your wheel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140319/d539e227/attachment.html>