[meta-freescale] Chromium acceleration
christian.betz at gmail.com
Wed Mar 19 18:29:10 PDT 2014
> 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
moving beyond semantics... let me tell you what i know about this
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:
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:
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...
More information about the meta-freescale